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] [RFC] Hypercalls from HVM guests

To: "Steve Ofsthun" <sofsthun@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Hypercalls from HVM guests
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Fri, 7 Apr 2006 19:24:34 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 07 Apr 2006 10:29:48 -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: AcZaZj40QGtcMEx/SsOAxvHTrZ/5uQAATm/A
Thread-topic: [Xen-devel] [RFC] Hypercalls from HVM guests

> -----Original Message-----
> From: Steve Ofsthun [mailto:sofsthun@xxxxxxxxxxxxxxx] 
> Sent: 07 April 2006 18:06
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [RFC] Hypercalls from HVM guests
> Petersson, Mats wrote:
> > Interesting subject - I must have missed the September patchset... 
> > I've been thinking a lot about para-virtualized drivers for 
> HVM guests 
> > (because it would improve performance on some functions by a great 
> > deal to avoid intercepting half a dozen IO operations to actually 
> > perform a single transaction - like one READ of the virtual 
> hard-disk).
> This is exactly our interest as well.
> > I'd like to make sure that you're aware that the AMD 
> architecture also 
> > has a VMMCALL instruction, which is opcode (0F 01 D9). It would be 
> > great if you could implement some sort of auto-detect/switching so 
> > that your code works for AMD too. Of course, we could intercept 
> > invalid opcode and interpret the instruction, but that's far from a 
> > practical solution, I would think.
> Thanks for pointing that out.  I didn't realize the opcode 
> was different.
> I should be able to easily alter the hypercall page 
> initialization to use the proper AMD opcode.

I think it's got something to do with the two companies not talking
about new opcodes with each other - probably in turn to do with not
revealing what they are doing WITH those new opcodes. At least we have
so far avoided having THE SAME opcode for different instructions ;-)

> What is the preferred method to distinguish SVM vs. VMX from 
> within guest code running in an HVM guest?

Good question - the way I'd say is to look at CPUID to see if it's
"GeunineIntel" or "AuthenticAMD", but I'm not sure if that's the BEST.
Of course, this assumes the code is already aware that it's in a HVM
environment, which I'm not sure if you know that or not at the point you
need to know if it's AMD or Intel... Of course, if CPUID is intercepted,
it may return other things (but it's against the "rules" to lie about
the brand of the CPU!)

> Steve
> --
> Steve Ofsthun - Virtual Iron Software, Inc.

Xen-devel mailing list