Re: [Xen-devel] faster windows debugging design

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 20:18 +0100 on 19 Oct (1287519513), Konrad Rzeszutek Wilk wrote:
> 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?

Along these lines I have a tool that runs in dom0 and speaks the kd
protocol on a TCP port and attempts to DTRT to a running Windows domain
with hypercalls.  At the moment breakpoint and watchpoint support is
pretty much missing, but it's good enough to examine kernel
datastructures, run !analyze etc.

It's orthogonal to what you're proposing, I think, but I mention it
because it can be used to run windbg against a windows guest that
doesn't have the kernel debugger running, and so might be useful for
debugging a debugger.

Completing it has been on my todo list for a long time, but maybe it'd
be useful even in its current form.  I'll tidy it what I have and post
it in case it's useful.

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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