Re: [Xen-devel] xen pv and cpuid

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

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