WARNING: Some of this info is out of date. Last revision was on 2006-12-15.
Rationale
Full virtualization support in Xen requires emulation to support unmodified guests. Up until now, Xen has only used device emulation. The V2E effort will allow QEMU to be used not only for device emulation but also for CPU emulation. CPU emulation is required for VT-capable processors in order to properly support BigRealMode. In addition, CPU emulation support can also improve overall performance by minimizing the number of round trips required to do device emulation. Round trips are reduced by running the emulator for a small number of instructions following all IO traps. Since IO events are likely to have temporal locality, we increase the probability of handling multiple IO events in a single transition. Handling a typical VMEXIT can cost upwards of 60-90 thousand cycles so quite a bit of work can be done in the emulator provided that we can eliminate a few exits in the process.
Current Status
The integration of QEMU-based CPU emulation is complete although some regressions exist. Since the guest may not be executing in userspace, a new dependency has been introduced on having access to the emulated devices in userspace. For the bulk of devices, this is not a problem since the emulation occurs in dom0 userspace anyway. However, for the local APIC and PIT (which both reside in the hypervisor), a new mechanism must exist to synchronize device state between userspace and Xen. Our current experiments seem to indicate that this isn't currently a problem since we only use V2E for 16 bit code at the moment. However, this definitely needs to be addressed in order to use V2E to acceleration MMIO/PIO operations.
N.B.: With the reintroduction of QEMU's dynamic translator, a version of GCC 3.x is required to build ioemu. Also, the 64bit build is hosed ATM.
Device Synchronization
The current plan is to implement device synchronization by adding a hypercall that let's qemu-dm submit an MMIO or PIO request on behalf of the guest. Any MMIO/PIO requests for the lapic or pit will be trapped and redirected to Xen. This interface allows quite a bit of flexibility. We don't expect that this interface will be performance critical. With the lapic and pit in Xen, an interface is needed to allow Xen to signal an interrupt to qemu-dm. The current plan is to have Xen generate a SIGIO to qemu-dm (via an event channel). QEMU already supports signal handling for dealing with the timer so this should be a natural thing to do.
SMP Support
SMP support isn't an issue at the moment since we're only using V2E for 16 bit code. When 16 bit code is executing, only the BP is executing so there are no race conditions. When we support MMIO/PIO acceleration, we'll have to consider how to ensure that atomic instructions remain atomic (even if one VCPU is running in the emulator while another VCPU is running on bare metal).
Tuning
A fair bit of work will be needed to tune how long to remain in emulation after an MMIO/PIO exit. Over time, it may be useful to implement this as a learning algorithm since the exit costs (and hence, the time spent in emulation) will vary dramatically on different processors.
Linux guests
The current V2E code is capable of booting a Linux HVM guest (including guests that require BigRealMode). The current code cannot handle Win2k guests or WinXP guests.
Win2k guests
There appears to be a bug in the emulation code that causes the dynamic translator to get stuck in a tight loop in cpu_exec(). This bug is a regression of the V2E work (QEMU works quite happily with Win2k guests).
Since Win2k guests are not officially supported by Xen (the performance is terrible during startup to do the use of VGA planar mode) we are not currently investigating this problem.
WinXP guests
WinXP is currently dying early in the boot loader. If forced to remain in qemu-dm, it will boot quite happily. The best guess at this point in time is that this is due to Xen's problems with non-linear segments (which WinXP makes use of in the boot loader). We are currently merging with mainline to pick up Jan Beulich's HVM fixes with hopes that this will make more progress.
Win2k3 guests
The WinXP and Win2k3 bootloaders are quite similar so there shouldn't be that many problems once WinXP is working.
Getting the latest bits
The latest stable bits are located in Leendert's HVM tree on xenbits. You can fetch them with:
$ hg clone http://xenbits.xensource.com/ext/xen-unstable-hvm.hg
AnthonyLiguori has a tree that contains a few fixes plus an initial attempt to merge against the latest (as of ~12/01/06) xen-unstable. This tree has regressed as some merge conflicts are being worked through (the HVM code has changed quite a bit recently). The latest bits can be fetched with:
$ hg clone http://xenbits.xensource.com/ext/xen-unstable-hvm.hg $ cd xen-unstable-hvm.hg $ hg unbundle http://www.cs.utexas.edu/~aliguori/v2e-20061206.bundle $ hg update
Contacts
The vast majority of the V2E was done by Leendert Van Doorn < leendert@us.ibm.com > and Khoa Huynh < khoa@us.ibm.com >. The most current V2E work is being done by AnthonyLiguori < aliguori@us.ibm.com >.
