From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: faster windows debugging design Date: Tue, 19 Oct 2010 15:18:33 -0400 Message-ID: <20101019191833.GA9229@dumpdata.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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? > > So the changes to qemu that I can see so far are: > . additional code to control the setup and teardown of communication > rings (tx and rx ring) > . a way to divert received I/O from the serial port to my faster > interface so that the serial port doesn't eat data > > Any comments? > > The other possible approach is to emulate a 1394 interface just enough > to make windows sufficiently happy to use it as a debug interface. This > is quite a bit more complex though, qemu would need to implement a new > PCI device, and also deal with the fact that RDMA is not actually > available end-to-end (eg over tcp) so qemu would need knowledge of the > windbg protocol to convert to a serial stream of data compatible with > the serial windbg protocol. I'm not completely sure about any of that > though. USB debugging? There is a USB device already there (in QEMU), and both Linux and Windows have the USB debug port stack implemented quite robustly. (Thought I am not sure how well they work past a S3 sleep/resume).