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

[Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx>]

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