|
xen-devel
Re: [Xen-devel] [RFC] Hypercalls from HVM guests
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
--
Steve Ofsthun - Virtual Iron Software, Inc.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home