Re: [RFC] Hypercalls from HVM guests

[Steve Ofsthun <sofsthun@virtualiron.com>]

Petersson, Mats wrote:

>> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] 
>>
>> 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.