Re: [PATCH 0/7] kvmtool: Cleanup kernel loading
On Wed, Nov 18, 2015 at 10:29:30AM +, Andre Przywara wrote: > On 02/11/15 14:58, Will Deacon wrote: > > On Fri, Oct 30, 2015 at 06:26:53PM +, Andre Przywara wrote: > >> this series cleans up kvmtool's kernel loading functionality a bit. > >> It has been broken out of a previous series I sent [1] and contains > >> just the cleanup and bug fix parts, which should be less controversial > >> and thus easier to merge ;-) > >> I will resend the pipe loading part later on as a separate series. > >> > >> The first patch properly abstracts kernel loading to move > >> responsibility into each architecture's code. It removes quite some > >> ugly code from the generic kvm.c file. > >> The later patches address the naive usage of read(2) to, well, read > >> data from files. Doing this without coping with the subtleties of > >> the UNIX read semantics (returning with less or none data read is not > >> an error) can provoke hard to debug failures. > >> So these patches make use of the existing and one new wrapper function > >> to make sure we read everything we actually wanted to. > >> The last patch moves the ARM kernel loading code into the proper > >> location to be in line with the other architectures. > >> > >> Please have a look and give some comments! > > > > Looks good to me, but I'd like to see some comments from some mips/ppc/x86 > > people on the changes you're making over there. > > Sounds reasonable, but no answers yet. > > Can you take at least patch 1 and 2 meanwhile, preferably 6 and 7 (the > ARM parts) also if you are OK with it? > I have other patches that depend on 1/7 and 2/7, so having them upstream > would help me and reduce further dependency churn. > I am happy to resend the remaining patches for further discussion later. We let them sit on the list for a while with no comments, so I just pushed out your series. If a bug report shows up, then we can always revert the offending patch if there's no quick fix. Will -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: powerpc: kvmppc_visible_gpa can be boolean
On 16/11/2015 04:10, Yaowei Bai wrote: > In another patch kvm_is_visible_gfn is maken return bool due to this > function only returns zero or one as its return value, let's also make > kvmppc_visible_gpa return bool to keep consistent. > > No functional change. > > Signed-off-by: Yaowei Bai> --- > arch/powerpc/kvm/book3s_pr.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c > index 64891b0..70fb08d 100644 > --- a/arch/powerpc/kvm/book3s_pr.c > +++ b/arch/powerpc/kvm/book3s_pr.c > @@ -512,7 +512,7 @@ static void kvmppc_patch_dcbz(struct kvm_vcpu *vcpu, > struct kvmppc_pte *pte) > put_page(hpage); > } > > -static int kvmppc_visible_gpa(struct kvm_vcpu *vcpu, gpa_t gpa) > +static bool kvmppc_visible_gpa(struct kvm_vcpu *vcpu, gpa_t gpa) > { > ulong mp_pa = vcpu->arch.magic_page_pa; > > @@ -521,7 +521,7 @@ static int kvmppc_visible_gpa(struct kvm_vcpu *vcpu, > gpa_t gpa) > > gpa &= ~0xFFFULL; > if (unlikely(mp_pa) && unlikely((mp_pa & KVM_PAM) == (gpa & KVM_PAM))) { > - return 1; > + return true; > } > > return kvm_is_visible_gfn(vcpu->kvm, gpa >> PAGE_SHIFT); > Applied all three patches to kvm/queue, thanks. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] kvmtool: Cleanup kernel loading
Hi Will, On 02/11/15 14:58, Will Deacon wrote: > On Fri, Oct 30, 2015 at 06:26:53PM +, Andre Przywara wrote: >> Hi, > > Hello Andre, > >> this series cleans up kvmtool's kernel loading functionality a bit. >> It has been broken out of a previous series I sent [1] and contains >> just the cleanup and bug fix parts, which should be less controversial >> and thus easier to merge ;-) >> I will resend the pipe loading part later on as a separate series. >> >> The first patch properly abstracts kernel loading to move >> responsibility into each architecture's code. It removes quite some >> ugly code from the generic kvm.c file. >> The later patches address the naive usage of read(2) to, well, read >> data from files. Doing this without coping with the subtleties of >> the UNIX read semantics (returning with less or none data read is not >> an error) can provoke hard to debug failures. >> So these patches make use of the existing and one new wrapper function >> to make sure we read everything we actually wanted to. >> The last patch moves the ARM kernel loading code into the proper >> location to be in line with the other architectures. >> >> Please have a look and give some comments! > > Looks good to me, but I'd like to see some comments from some mips/ppc/x86 > people on the changes you're making over there. Sounds reasonable, but no answers yet. Can you take at least patch 1 and 2 meanwhile, preferably 6 and 7 (the ARM parts) also if you are OK with it? I have other patches that depend on 1/7 and 2/7, so having them upstream would help me and reduce further dependency churn. I am happy to resend the remaining patches for further discussion later. Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html