RE: [Xen-devel] xen pv and cpuid

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Hi Jan --

For my case, if the set of CPU models that support
this cpuid masking feature is a superset of the set
of CPU models that support TSC Invariant, it would be
helpful.

Any idea if this is true?  If so, an argument can
be made that the TSC Invariant bit should never be
exposed to guests through cpuid (though it may
be made visible through pvcpuid or another
mechanism).

Thanks,
Dan

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
> Sent: Tuesday, October 27, 2009 3:37 AM
> To: Dan Magenheimer
> Cc: Xen-Devel (E-mail)
> Subject: Re: [Xen-devel] xen pv and cpuid
> 
> 
> There's one other mechanism in use here - masking CPUID feature bits
> through special vendor MSRs. See the handling of the command line
> options cpuid_mask_{edx,ecx} in xen/arch/x86/cpu/. But this 
> is a global
> mask (i.e. also affecting what Xen itself sees), and isn't 
> available on all
> CPU models...
> 
> Jan
> 
> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 26.10.09 18:44 >>>
> Silly x86 question of the day:
> 
> Is it true in a PV domain that there is no way (short of 
> binary translation) to trap a userland cpuid instruction into Xen?
> 
> I found the routine pv_cpuid() in arch/x86/traps.c and 
> assumed that userland cpuid's would find their way into that 
> code, but it appears to not be the case.  After adding some 
> printks and reading the code more closely, I gather that PV 
> OS's somehow get their cpuid instructions replaced with an 
> invalid op so that kernel-land cpuid's do indeed get trapped? 
> Then looking at the Intel SDM I don't see any way to force 
> cpuid at any privilege level to trap (except in an HVM)?
> 
> (If this is all correct, then I am sadly back to needing 
> userland hypercalls :-(
> 
> Thanks,
> Dan
> 
>

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