debugging in a virtual environment (eg xen)

Does anyone debug their drivers in a virtual environment? (eg passing a
PCI device through to a Xen DomU) Obviously it’s not exactly the same as
doing it on real hardware, but it’s close enough that it could be

During development of my Xen PV drivers, I used the following for
. com1 in my Windows virtual machine maps to a /dev/pts in Linux
. inetd listens for a connection to port 4407, and then accepts the
connection and bridges it to the /dev/pts
. On my laptop (at home usually - the xen server is at work) I ran a
virtual serial port driver which connected to port 4407 on my Xen
server, and connected windbg to that port

That worked well, but was never particularly fast. If all I wanted was
the debug print statements I called my own debug print command which
logged via xen and was much faster (actually, I first reverse engineered
part of the windbg protocol and wrote something under Linux that
connected and worked well enough to dump the debug statements that way),
but if I wanted to set breakpoints or something I had to go back to the

Now that was slow even when my laptop was on the same subnet as the Xen
server, so I would have expected better performance… maybe the virtual
serial port on the machine I was debugging was actually limiting the
speed to the selected baud rate? I never tried increasing it…

Anyway, the recent talk about USB2 debugging made me wonder if there was
a better way… there is a virtual USB available for Xen windows domains
and if it didn’t support it already it probably wouldn’t be that hard to
make debugging work over it… or maybe there’s a better way still?


>Does anyone debug their drivers in a virtual environment?


PCI device through to a Xen DomU)

I do not use Xen, I use MS virtual machine software and their COM port linked to a named pipe.

I think they - especially Hyper-V - have the virtual COM port implementation specially optimized for debugger.

Maxim S. Shatskih
Windows DDK MVP

James - I use the same thing but without the inetd and network part of it. The Linux serial device just maps directly to the second physical serial port in the hardware. Maybe getting rid of one moving part will speed things up for you.