Re: [PATCH] Calculate correct instruction length for data-fault VM exits on VT-x systems

[Leendert van Doorn <leendert@watson.ibm.com>]

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:

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