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


RE: [Xen-devel] faster windows debugging design

To: "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx>
Subject: RE: [Xen-devel] faster windows debugging design
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Wed, 20 Oct 2010 09:40:34 +1100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 19 Oct 2010 15:41:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101019191833.GA9229@xxxxxxxxxxxx>
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>
References: <AEC6C66638C05B468B556EA548C1A77D01B1FF30@trantor> <20101019191833.GA9229@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActvwovzfWI1ZwXOTAipuKqp1P3ztwAGLUvQ
Thread-topic: [Xen-devel] faster windows debugging design
> 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
> > 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
> > 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
> > 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
> > module altogether. Needs to be a fixed port though.). I/O is done
> > the backend of the serial port interface
> > ...) which means that no change is required past dom0. Additionally,
> > 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
> > a bit.
> Would it make sense to provide a "failsafe" mechanism for debugging?
> 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?

If you specify /debugport=xen then my kdxen.dll module will be loaded,
will signal to xen that high speed debug is in progress, and disable the
com port. If you leave the /debugport option as the default =comX then
kdcom.dll will be loaded and things will be the same as they always

> >
> > 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
> > to make windows sufficiently happy to use it as a debug interface.
> > is quite a bit more complex though, qemu would need to implement a
> > 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
> > windbg protocol to convert to a serial stream of data compatible
> > the serial windbg protocol. I'm not completely sure about any of
> > 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
> (Thought I am not sure how well they work past a S3 sleep/resume).

USB debugging needs a EHCI (2.0) interface that supports USB debugging
(qemu usb is 1.1), and is only supported under Vista and later, so it's
less attractive.


Xen-devel mailing list