| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH] Calculate correct instruction length for data-fa
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home