From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] Calculate correct instruction length for data-fault VM exits on VT-x systems Date: Fri, 28 Apr 2006 15:02:17 -0500 Message-ID: <445274C9.7070708@us.ibm.com> References: <907625E08839C4409CE5768403633E0BA7FC0B@sefsexmb1.amd.com> <1146273618.4268.32.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1146273618.4268.32.camel@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: leendert@watson.ibm.com Cc: "Petersson, Mats" , xen-devel , Khoa Huynh List-Id: xen-devel@lists.xenproject.org Leendert van Doorn wrote: > On Fri, 2006-04-28 at 10:24 +0100, Keir Fraser wrote: > > >> Yes, I expect HVM users will want some kind of helpful wrapper around >> the core emulator. I'm trying to keep the emulator itself very generic, >> so it makes sense that some tailoring will be required in some usages. >> >> >>> We will of course also need to get the communication with QEMU done in >>> some way. >>> >> Yes, I don't imagine that is hard as long as you're prepared to copy >> the guest's register state to and from qemu-dm. Even on x8664 it's only >> a couple hundred bytes so unlikely to be a significant overhead. Then >> you can simply have a copy of the emulator inside qemu-dm. >> >> -- Keir >> >> >>> I haven't spent any time looking at it so far... >>> > > Here is something I've been toying with lately, inspired by the work > Steve's students presented at Eurosys. > > The way we are currently doing real-mode emulation for VT-x is a royal > pain and getting the semantics right for all big real mode uses (Solaris > 9, SLES's gfxboot) is next to impossible in the current framework. What > I was thinking about was to switch back and forth between a VT-x > partition and a full emulator. The obvious choice for this would be to > put back the qemu instruction emulator into qemu-dm and handle all > real-mode instructions there. As soon as CR0.PE is set to 0, we do an > upcall to the emulator. Once CR0.PE=1 and we have emulated some > threshold number of instructions (1000?) we switch back to the VMX > partition. This would allow us to amortize the cost of doing a full > context save and restore. Obviously, this is only a concern for VT-x, > but SVM could benefit in the following scenario: > This could be extended to support systems without VT/SVM. Instead of dropping back when CR0.PE=1 (after 1000 instructions), if VT/SVM isn't available, you wait until a switch to ring 3. This would essentially do what QEmu + qvm86 does today. I'd be really happy to see this in Xen since it would let you use unmodified guests (even when VT/SVM is not present). Regards, Anthony Liguori > We could do a similar thing for I/O operations. Basically, generate an > upcall into qemu-dm on an MMIO or PIO exit and let qemu-dm deal with it. > It can do the same trick and emulate a number of instructions (1000?) > before returning to the HVM partition. This will eliminate expensive > VMCS/VMCB exits on subsequent I/O operations (just consider doing a > block write on an IDE device in PIO mode, this is common behavior). It > will also eliminate the need for the MMIO instruction emulator in the > hypervisor. > > The only difficulty is that the hypervisor keeps some of the device > state vpit and *pics and shotcuts operations to them. This state needs > to be exposed to qemu-dm so that it is saved and restored on every > qemu-dm invocation. I need to verify this, but as far as I'm aware, all > the accesses to the devices emulated in the hypervisor are PIO > operations. These are easy to decode with the exit information that is > provided by VT-x and SVM, so they don't need a a full instruction > decoder. > > Comments? > > Leendert > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >