| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] xen pv and cpuid
On 26/10/2009 17:44, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home