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@lists.xensource.com http://lists.xensource.com/xen-devel
On 26/10/2009 17:44, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:> Is it true in a PV domain that there is no way (short of binary translation) > to trap a userland cpuid instruction into Xen?A pure CPUID instruction cannot be trapped, that is correct.> 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)?Correct, PV guest kernels are expected to use the ''special'' paravirtualised CPUDI instruction that is a specially-interpreted/emulated invalid instruction. PV guest applications are also allowed to use this paravirtualised instruction, if they like.> (If this is all correct, then I am sadly back to needing userland hypercalls > :-(Presumably you can just use the paravirtualised CPUID instruction. See tools/misc/xen-detect.c for an example usage which deals with the case that the invalid instruction visibly faults (i.e., because you aren''t running on Xen after all). An alternative to fork-and-test-the-child would be to ask the kernel if it is running on Xen (e.g., on XenLinux perhaps by querying for Xen-specific nodes in /proc). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@oracle.com> 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@lists.xensource.com
http://lists.xensource.com/xen-devel
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@novell.com] > 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@oracle.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel