This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fa

To: leendert@xxxxxxxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fault VM exits on VT-x systems
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Fri, 28 Apr 2006 15:02:17 -0500
Cc: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Khoa Huynh <khoa@xxxxxxxxxx>
Delivery-date: Fri, 28 Apr 2006 13:02:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1146273618.4268.32.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <907625E08839C4409CE5768403633E0BA7FC0B@xxxxxxxxxxxxxxxxx> <c231609ff1a74b7bbeebd70a7ec94936@xxxxxxxxxxxx> <1146273618.4268.32.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mail/News 1.5 (X11/20060309)
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).


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

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



Xen-devel mailing list

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>