[Xen-devel] faster windows debugging design

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

Here's my plan so far...

Windows debugging is done via the serial port (or 1394 or USB). The
current way of debugging a windows DomU is to connect 'xm console' to a
tcp port in domU, and then on a separate machine (virtual or physical)
connect that tcp port to a virtual serial port or a named pipe. This
tends to suffer from fairly poor performance though as anyone who's used
it will confirm.

My approach is to write a new kd module - kdxen.dll - under windows
which is loaded by specifying /debugport=xen in boot.ini. This sets up
an alternate communication channel with Xen that doesn't involve a
vmexit every time a byte is read or written via the serial port.
xen_platform.c is modified to control the other end of that
communication channel (I'm using the same 0x10-1F ioport range to set up
the channel at the moment, otherwise it could possibly go in a separate
module altogether. Needs to be a fixed port though.). I/O is done via
the backend of the serial port interface (qemu_chr_write(serial_hds[0],
...) which means that no change is required past dom0. Additionally, the
debugger does a lot of busywaiting for I/O (no interrupts are used)
which can be deferred to usleeps in qemu which should reduce system load
a bit.

So the changes to qemu that I can see so far are:
. additional code to control the setup and teardown of communication
rings (tx and rx ring)
. a way to divert received I/O from the serial port to my faster
interface so that the serial port doesn't eat data

Any comments?

The other possible approach is to emulate a 1394 interface just enough
to make windows sufficiently happy to use it as a debug interface. This
is quite a bit more complex though, qemu would need to implement a new
PCI device, and also deal with the fact that RDMA is not actually
available end-to-end (eg over tcp) so qemu would need knowledge of the
windbg protocol to convert to a serial stream of data compatible with
the serial windbg protocol. I'm not completely sure about any of that
though.

Thanks

James

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