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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
> Sent: 07 April 2006 18:40
> To: Petersson, Mats
> Cc: Steve Ofsthun; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [RFC] Hypercalls from HVM guests
> 
> 
> On 7 Apr 2006, at 18:24, Petersson, Mats wrote:
> 
> > 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!)
> 
> 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). 

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). 

--
Mats
> 
>   -- Keir
> 
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel