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: "Petersson, Mats"
Subject: Re: [Xen-devel] [RFC] Hypercalls from HVM guests
From: Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx>
Date: Fri, 07 Apr 2006 15:30:42 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 07 Apr 2006 12:31:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <907625E08839C4409CE5768403633E0BA7FBCF@xxxxxxxxxxxxxxxxx>
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>
References: <907625E08839C4409CE5768403633E0BA7FBCF@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050715)
Petersson, Mats wrote:

From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] I like the idea of stealing some MSR space for this, and doing some initial interaction with the underlying hypervisor platform via RDMSR/WRMSR to known MSRs. We could 'read' an 'MSR' that would tell us the correct instruction sequence to do a hypercall (either directly, or maybe tell us a 'physical address' to read the hypercall transport information from -- then we could have a hypercall transfer page just as we already do for paravirtualised guests).

We just need to pick some MSRs that won't get used by Intel or AMD in the future. There's quite a lot of addressing space to carve up though. :-)

I like this idea, it's quirky and neat at the same time...

But isn't this going to be a catch-22 situation? We don't know if we're
virtualized or not, so we can't make hypercalls, and to find out, we
read an unimplemented MSR, which on REAL hardware causes a GP fault (and
probably also in SVM, since the map for SVM capturing MSR read/write
operations is very specific - at least if we use a MSR like 0xb0000000
or such).

This sounds like a simple to use method for communicating with the HVM code,
but I would like to gracefully detect native execution and print a useful
error message at module load time.  Recovering from a native mode exception
will be very O/S specific (if allowed at all).

Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) would
be better? As that's defined to return all zero's, and not cause any
traps whatever value you use (unless the CPU is so old that it doesn't
support CPUID, of course).

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

Steve Ofsthun - Virtual Iron Software, Inc.

Xen-devel mailing list