Re: [Xen-devel] [PATCH 11/18] Nested Virtualization: cpuid

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 14:13 +0100 on 16 Apr (1271427195), Christoph Egger wrote:
> On Friday 16 April 2010 15:00:47 Tim Deegan wrote:
> > Content-Description: xen_nh11_cpuid.diff
> >
> > > # HG changeset patch
> > > # User cegger
> > > # Date 1271330304 -7200
> > > Pass cpuid feature bits to guest
> > >
> > > diff -r e905f1d81e63 -r 01758c6195f4 xen/arch/x86/hvm/hvm.c
> > > --- a/xen/arch/x86/hvm/hvm.c
> > > +++ b/xen/arch/x86/hvm/hvm.c
> > > @@ -1970,12 +1970,38 @@ void hvm_cpuid(unsigned int input, unsig
> > >              }
> > >          }
> > >          break;
> > > +    case 0x80000000:
> > > +        if ( !nestedhvm_enabled(v->domain) )
> > > +            break;
> > > +        if (*eax < 0x8000000a)
> > > +            *eax = 0x8000000a;
> >
> > I don't understand this.  Surely you can't have set nestedhvm_enabled on
> > a CPU that doesn't supoprt SVM (and therefore has at least that level of
> > CPUID available).  If that's been overwritten by the tools then it
> > should be fixed in the tools, not the hypervisor.
> 
> Xen reads SVM feature bits only if cpuid level 0x8000000a is available.
> When you run Xen as HVM guest then Xen reads 0x80000001 if I remember 
> correctly and the L2 guest can't use hap then.

Okay, but you're fixing this in the wrong place.  Find out what's
causing the cpuid to be capped at 0x80000001 (I think it'll be libxc)
and fix it there.

> > > +        break;
> > >      case 0x80000001:
> > >          /* We expose RDTSCP feature to guest only when
> > >             tsc_mode == TSC_MODE_DEFAULT and host_tsc_is_safe() returns 1
> > > */ if ( v->domain->arch.tsc_mode != TSC_MODE_DEFAULT ||
> > >               !host_tsc_is_safe() )
> > >              *edx &= ~bitmaskof(X86_FEATURE_RDTSCP);
> > > +
> > > +        /* Don't expose SVM feature bit when host does not run with
> > > +         * nested paging enabled. This check is needed as long as
> > > +         * we don't support shadow-on-shadow.
> > > +         */
> > > +        if ( !paging_mode_hap(v->domain) )
> > > +            *ecx &= ~bitmaskof(X86_FEATURE_SVME);
> >
> > Surely !paging_mode_hap(d) -> !nestedhvm_enabled(d), and you don't need
> > to check it here.  Otherwise you're in for worse surprises than getting
> > CPUID wrong.
> 
> This check is supposed to go away when shadow-on-shadow is implemented.
> This check makes sure that SVM feature bit is not propagated to the guest
> if you have hap=0 and nestedhvm=1 in the guest config file.

If you haven't implemented shadow-on-shadow then it's not safe to let 
nestedhvm_enabled(d) == 1 when paging_mode_hap(d) == 0.  

If you've enforced that, then this check isn't needed.  If you haven't
than masking the CPUID bits won't make it safe, just safe from
well-behaved guests.

Cheers,

Tim.

> >
> > Cheers,
> >
> > Tim.
> >
> > > +        /* Don't expose SVM feature bit when nestedhvm is disabled. */
> > > +        if ( !nestedhvm_enabled(v->domain) )
> > > +            *ecx &= ~bitmaskof(X86_FEATURE_SVME);
> > > +        break;
> > > +    case 0x8000000a:
> > > +        /* Don't expose SVM feature bits when nestedhvm is disabled. */
> > > +        if ( !nestedhvm_enabled(v->domain) ) {
> > > +            *eax = *ebx = *ecx = *edx = 0;
> > > +            break;
> > > +        }
> > > +
> > > +        hvm_nestedhvm_vcpu_features(v, eax, ebx, ecx, edx);
> > >          break;
> > >      }
> > >  }
> >
> > Content-Description: ATT00001.txt
> >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel
> 
> 
> 
> -- 
> ---to satisfy European Law for business letters:
> Advanced Micro Devices GmbH
> Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
> Geschaeftsfuehrer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni
> Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
> Registergericht Muenchen, HRB Nr. 43632
> 

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel