This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] faster windows debugging design

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] faster windows debugging design
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Tue, 19 Oct 2010 23:02:26 +1100
Delivery-date: Tue, 19 Oct 2010 05:03:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActvhX9Vsm1l8ZByQYqNp99QixO3UA==
Thread-topic: faster windows debugging design
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



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>