RE: [Xen-devel] high(er than serial) speed interface for windows kernel debugging

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
> Sent: 17 October 2010 04:14
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel