Re: [Xen-devel] Want to Learn how Qemu works in Xen and dom0

[Peter Teoh <htmldeveloper@xxxxxxxxx>]

I am not an expert on Xen-QEMU either, but just want to share what I have found and know so far:

First, reading the wiki:
http://wiki.xensource.com/xenwiki/XenRoadMap

QEMU
QEMU has proved to be very helpful for providing Xen HVM guests with emulated IO devices. However, Xen's current "qemu-dm" code has diverged quite heavily from mainline qemu, which means that we can't as easily capitalise on enhancements made to mainline qemu, and also makes it harder for us to contribute enhancements back to Fabrice. Fixing this is a priority. We are developing a re-implementation of qemu-dm that is maintained as a patch queue against an unmodified snapshot of mainline qemu, and hope to have this ready for testing soon. Like the shadow pagetable code, this is going to require extensive testing even prior to inclusion in -unstable. 

Catching up with the latest version of qemu has a number of nice side effects. It gets us Anthony Liguori's improved VNC server code for the framebuffer, removing our dependency on the rather obtuse libvncserver library. Further, it gets us support for emulated USB devices, most interesting of which is a USB mouse. The USB mouse protocol supports a mode of operation whereby it provides absolute x,y co-ordinates rather relative motion events (which the OS usually turns into absolute co-ordinates using some unknown `black box' algorithm that has mouse speed and acceleration parameters). Being able to inject absolute co-ordinates means that it is easy to arrange for our the HVM guest cursor to perfectly track the local cursor in the VNC viewer, regardless of the user's mouse settings. 

Although not immediately on the horizon, there are plans to give qemu a slightly extended role in Xen. The `V2E' research work in Cambridge has shown that it is possible to move the execution state of a guest from a Xen virtual machine into qemu and back out again. In the context of the research work the aim was to enable high-performance taint tracking to be implemented, where the guest ran at full speed as a xen guest until it accessed a tainted value at which point execution was moved on to the qemu emulator which was able to monitor execution closely. At some point later execution would be moved back to Xen. As pointed out by Leendert, a similar approach can be used for transitioning into IO emulation, cleaning up the current interface and possibly providing performance optimizations when many IO operations are performed in close proximity. This technique also solves a thorny issue with Intel VT systems, which unlike AMD-V do not provide h/w assistance for virtualizing the legacy x86 `real mode'. Today, we have the `vmxassist' code containing a crude emulator to try and handle this case, but the code fails in the presence of certain complex 16b applications, such as MSDOS or the SuSE graphical boot loader. Having the ability to throw execution onto QEMU which has a complete real mode emulation would solve this problem. 



And the binaries described:   qemu-dm, is found in /usr/lib/xen/bin:

/usr/lib/xen/bin>ls -1xpt
qemu-dm    xenconsole  readnotes  xc_restore  xc_save  xenctx  qemu-dm.debug
xen-sdlfb  xen-sdlfbo  xen-vncfb  xen-vncfbo


And as for the implementation, I found it under tools/ioemu.   And under tools/ioemu/patches, I found all the diff files to be applied against the QEMU source.   From the tools/ioemu/Changelog file, I deduced that the qemu version downloaded is 0.8.2.

And as for the binary - qemu-dm, it is compiled into the subdirectory:   tools/ioemu/i386-dm, based on original files located in tools/ioemu/ and its various subdirectory (as seen from Makefile, Makefile.target, it is depending on a complex criteria involving platform environment etc).






_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel