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/
Home Products Support Community News


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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Subject: RE: [Xen-devel] Re: [RFC] Hypercalls from HVM guests
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Thu, 13 Apr 2006 14:53:44 +0200
Cc: sofsthun@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Andi Kleen <ak@xxxxxxx>
Delivery-date: Thu, 13 Apr 2006 05:59:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcZeVX9Y6pIsFDYJTECQwTUzNN5dlwAosVaA
Thread-topic: [Xen-devel] Re: [RFC] Hypercalls from HVM guests
> -----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. 

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

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • RE: [Xen-devel] Re: [RFC] Hypercalls from HVM guests, Petersson, Mats <=