From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Ofsthun Subject: Re: [RFC] Hypercalls from HVM guests Date: Fri, 07 Apr 2006 15:30:42 -0400 Message-ID: <4436BDE2.5090504@virtualiron.com> References: <907625E08839C4409CE5768403633E0BA7FBCF@sefsexmb1.amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <907625E08839C4409CE5768403633E0BA7FBCF@sefsexmb1.amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Petersson, Mats Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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.