WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] high(er than serial) speed interface for windows kernel debugging
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Sun, 17 Oct 2010 14:13:59 +1100
Delivery-date: Sat, 16 Oct 2010 20:14:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActtqVfF8/NkOop5Qqqqf9GaOeo/5g==
Thread-topic: 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>