WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [RFC] Hypercalls from HVM guests


On 8 Apr 2006, at 15:12, Andi Kleen wrote:

This sounds encouraging, but is CPUID always trapped by the HVM code?

It can be, and in practise yes it is so this could work.

CPUID doesn't have any advantage over MSRs for this purpose because
for custom CPUIDs like 0xb... you can't use the normal "max count" mechanism
of determining if a CPUID is supported.  All that would work is to try
it and handle the GPF if it didn't work. That would give the same ugly
implementation as with MSRs.

CPUID never faults. Well, unless the processor doesn't support the instruction, but you find that out from EFLAGS.

Using the MSR would have the advantage of it being trappable in a para virtual
kernel too.

I would definitely prefer to use MSRs for gathering hypervisor signature and other information, but because of the possible hassle of catching faults I'd also support a signature return (and maybe identifying some hypervisor features) via a special CPUID index. The index could be greater than the normal "max count" and you'd determine if the index(es) were supported by checking for a well-known signature in EAX,EBX,ECX,EDX for the first of the hypervisor indexes. Running on native hardware would not fault and you'd expect it to be vastly unlikely that the final values of EAX thru EDX would coincidentally match a 128-bit signature.

(Cue attempts to think up a 16-character signature string. :-)

 -- Keir


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