qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc/kvm: use kvm_vm_check_extension(


From: Greg Kurz
Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] ppc/kvm: use kvm_vm_check_extension() in kvmppc_is_pr()
Date: Thu, 14 Sep 2017 16:39:06 +0200

On Thu, 14 Sep 2017 13:27:49 +0200
Greg Kurz <address@hidden> wrote:

> On Thu, 14 Sep 2017 13:17:48 +0200
> Thomas Huth <address@hidden> wrote:
> 
> > On 14.09.2017 12:48, Greg Kurz wrote:  
> > > If the host has both KVM PR and KVM HV loaded and we pass:
> > > 
> > >   -machine pseries,accel=kvm,kvm-type=PR
> > > 
> > > the kvmppc_is_pr() returns false instead of true. Since the helper
> > > is mostly used as fallback, it doesn't have any real impact with
> > > recent kernels. A notable exception is the workaround to allow
> > > migration between compatible hosts with different PVRs (eg, POWER8
> > > and POWER8E), since KVM still doesn't provide a way to check if a
> > > specific PVR is supported (see commit c363a37a450f for details).
> > > 
> > > According to the official KVM API documentation [1], KVM_PPC_GET_PVINFO
> > > is "vm ioctl", but we check it as a global ioctl. The following function
> > > in KVM is hence called with kvm == NULL and considers we're in HV mode.
> > > 
> > > int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > > {
> > >   int r;
> > >   /* Assume we're using HV mode when the HV module is loaded */
> > >   int hv_enabled = kvmppc_hv_ops ? 1 : 0;
> > > 
> > >   if (kvm) {
> > >           /*
> > >            * Hooray - we know which VM type we're running on. Depend on
> > >            * that rather than the guess above.
> > >            */
> > >           hv_enabled = is_kvmppc_hv_enabled(kvm);
> > >   }
> > > 
> > > Let's use kvm_vm_check_extension() to fix the issue.    
> > 
> > By the way, what about the other CAPs that rely on hv_enabled? grepping
> > through the QEMU sources, I can see:
> > 
> >  cap_ppc_smt = kvm_check_extension(s, KVM_CAP_PPC_SMT);
> > 

So this one was already fixed in David's ppc-for-2.11 branch thanks to
commit fa98fbfcdfcb9... which introduced a new KVM_CAP_PPC_SMT_POSSIBLE
cap, which is also a VM ioctl and needs to be fixed :)

    cap_ppc_smt_possible = kvm_check_extension(s, KVM_CAP_PPC_SMT_POSSIBLE);

> >  cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
> > 

Needs fixing.

> >  int ret = kvm_check_extension(s, KVM_CAP_NR_VCPUS);
> > 

Needs fixing.

> >  return kvm_check_extension(kvm_state, KVM_CAP_SYNC_MMU);
> > 

Needs fixing.

> >  !kvm_check_extension(cs->kvm_state, KVM_CAP_SW_TLB)) {
> > 

This seems to be e500 specific, and thus isn't affected.

> > ... do we need to fix them, too?
> >   
> 
> I'm currently going through the KVM code to see which ones need to be
> fixed. I'll send more patches shortly :)
> 
> Cheers,
> 
> --
> Greg
> 
> >  Thomas  
> 

Attachment: pgppTM_Xgs0qC.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]