Xen devel - Oct 2010 - high(er than serial) speed interface for windows kernel debugging

I''m investigating the possibility of doing something similar to
http://virtualkd.sysprogs.org/ for xen. Most of the hard work in terms
of defining the entry points and operation of a custom kernel debug dll,
I just need a way to make it work under xen at the DomU and Dom0 end.

The two options presented by the virtualkd project are to load a
completely custom kdvm.dll and make windows use that in boot.ini by
saying debugport=vm, or to start out with com port debugging and then
patch kdcom.dll in memory by redirecting the send/receive calls to my
own code. The former is neater but needs to load way before I have the
opportunity to set up a front/back communications ring, while the latter
can start anytime after boot. Using a frontend/backend driver is
probably the wrong way to go anyway as this needs to be really really
lightweight with as little code as possible, otherwise heisenbugs will
breed profusely.

So I''m thinking it might be best to happen entirely in qemu - still use
a communication ring but use mmio to set it up rather than xenstore.
I''m
not sure yet if the windows kernel debugger expects an interrupt when
there is data waiting or not, which would complicate things a bit...

Any comments?

Thanks

James

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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of James Harper
> Sent: 17 October 2010 04:14
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] high(er than serial) speed interface for
> windows kernel debugging
> 
> I''m investigating the possibility of doing something similar to
> http://virtualkd.sysprogs.org/ for xen. Most of the hard work in
> terms
> of defining the entry points and operation of a custom kernel debug
> dll,
> I just need a way to make it work under xen at the DomU and Dom0
> end.
> 
> The two options presented by the virtualkd project are to load a
> completely custom kdvm.dll and make windows use that in boot.ini by
> saying debugport=vm, or to start out with com port debugging and
> then
> patch kdcom.dll in memory by redirecting the send/receive calls to
> my
> own code. The former is neater but needs to load way before I have
> the
> opportunity to set up a front/back communications ring, while the
> latter
> can start anytime after boot. Using a frontend/backend driver is
> probably the wrong way to go anyway as this needs to be really
> really
> lightweight with as little code as possible, otherwise heisenbugs
> will
> breed profusely.
> 
> So I''m thinking it might be best to happen entirely in qemu -
still
> use
> a communication ring but use mmio to set it up rather than xenstore.
> I''m
> not sure yet if the windows kernel debugger expects an interrupt
> when
> there is data waiting or not, which would complicate things a bit...
> 
> Any comments?
> 
James,

  I''d thought about this too :-) Using qemu to provide the backend
sounds perfectly reasonable and handing it a page via an IO port is pretty
trivial. After that you just need to marshal the kd packets and out of the ring;
IIRC they are variable length so you''d probably need 2 rings similar to
xenstore. I don''t think you need worry about interrupts; IIRC the whole
thing is driven at IPI or HIGH so it''s totally polled.
  I''d also considered whether it was worth investigating emulated 1394
as an alternative though, since it would be more generally useful. Not sure if
qemu already has a device model but it''d need to be TI OHCI compliant
to work.

  Paul

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

> >
> > So I''m thinking it might be best to happen entirely in qemu -
still
> > use
> > a communication ring but use mmio to set it up rather than xenstore.
> > I''m
> > not sure yet if the windows kernel debugger expects an interrupt
> > when
> > there is data waiting or not, which would complicate things a bit...
> >
> > Any comments?
> >
> 
> James,
> 
>   I''d thought about this too :-) Using qemu to provide the backend
sounds
> perfectly reasonable and handing it a page via an IO port is pretty
trivial.
> After that you just need to marshal the kd packets and out of the
ring; IIRC
> they are variable length so you''d probably need 2 rings similar to
xenstore. I
> don''t think you need worry about interrupts; IIRC the whole thing
is
driven at
> IPI or HIGH so it''s totally polled.
I''ve started on that. The guys on the ntdev list seemed to think that
kd
modules need to be signed in later versions of windows, but there is
some doubt...
>   I''d also considered whether it was worth investigating emulated
1394
as an
> alternative though, since it would be more generally useful. Not sure
if qemu
> already has a device model but it''d need to be TI OHCI compliant
to
work.
> 
Someone on ntdev suggested that too and I initially dismissed the idea
but have since thought about it some more and it might have some merit.
I need to be able to debug remotely so the protocol would need to be
compatible with the serial port protocol, but maybe it already is - it
would make sense to use the same protocol...

James

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