Re: faster windows debugging design

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Oct 19, 2010 at 11:02:26PM +1100, James Harper wrote:
> 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.

Would it make sense to provide a "failsafe" mechanism for debugging? Say
you need to debug this driver, and want to use the old mechanism. Or 
is that not a problem since the old mechanism is rock solid and won't
be impared?

> 
> 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.

USB debugging? There is a USB device already there (in QEMU), and both
Linux and Windows have the USB debug port stack implemented quite robustly.
(Thought I am not sure how well they work past a S3 sleep/resume).