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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Keir Fraser
> Sent: 12 April 2006 18:06
> To: Stephen C. Tweedie
> Cc: sofsthun@xxxxxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxx; 
> Andi Kleen
> Subject: Re: [Xen-devel] Re: [RFC] Hypercalls from HVM guests
> 
> 
> On 12 Apr 2006, at 16:39, Stephen C. Tweedie wrote:
> 
> >
> >> CPUID never faults. Well, unless the processor doesn't support the 
> >> instruction, but you find that out from EFLAGS.
> >
> > What does vmx_vmexit_do_cpuid() do then?  I doubt there are many 
> > VMX-capable CPUs without cpuid().  :-)
> 
> Yes, you can make cpuid trap to the hypervisor if running an 
> hvm guest. 
> But that's quite different from a guest-visible trap or fault.

Not only is is POSSIBLE to intercept (note that INTERCEPT and FAULT are
two different things, as Keir explained), but it's necessary to
correctly emulate certain environmental things... For example, if we
have a 32-bit Hypervisor running on a Athlon64 processor, we don't want
the CPUID instruction return support for 64-bit mode - although it's
correct that the PROCESSOR supports 64-bit mode, the Hypervisor wouldn't
really be able to cope with this mode - so having a Linux install say
"Are you sure you want to install a 32-bit OS on this 64-bit processor"
(or worse, automatically select the "better" 64-bit option on it's own),
wouldn't really be what we want... 

Similarly, PAE-support in the hypervisor should be present, or we
shouldn't allow the guest to see that the processor supports PAE. 

Multiprocessor identification in CPUID would be another case where we
want to lie about what's really there and what the guest sees. 

But as for the SVM implementation (I haven't looked at the VMX version
lately), there's no injection of exceptions in the
svm_vmexit_do_cpuid(), and the CPUID instruction itself is not one that
CAN FAULT, unless we're talking about ancient CPU's. 

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


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