Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting

[Andrew Baumann]

> From: Ladi Prosek [mailto:address@hidden
> Sent: Tuesday, 7 November 2017 00:11
> 
> On Mon, Nov 6, 2017 at 7:41 PM, Andrew Baumann
> <address@hidden> wrote:
> > Hi,
> >
> > I just noticed this thread, and the problem sounded very familiar...
> >
> >> From: Ladi Prosek
> >> Sent: Monday, 6 November 2017 07:16
> > [...]
> >> FS base passes all the checks in windbg_on_load() as the guest kernel
> >> loads and it returns true. QEMU then sends some data over the pipe.
> >> Windbg doesn't print anything, it's still showing:
> >>
> >>   Opened \\.\pipe\win7_dbg
> >>   Waiting to reconnect...
> >>
> >> Is this expected? In regular remote kernel debugging, windbg produces
> >> a bunch of output about the target state when it attaches.
> >
> > Just a guess, but I suspect the problem you're seeing may be due to the
> combination of windbg's tight timing requirements for the serial debug
> protocol and qemu's polling-based implementation of named pipe IO. I ran
> into this a year or two ago when bringing up raspberry pi... I could never
> reliably connect windbg to the emulated serial port using a named pipe. I
> believe the problem is that the named pipe driver relies on receiving input
> through win_chr_pipe_poll(), which is called too infrequently to satisfy
> windbg's needs (it has a rather short timeout before it gives up and
> retransmits). The correct fix is to use blocking IO for the named pipes inside
> qemu, but I know from experience that win32 is awful in this respect -- qemu
> wants a single unified blocking call to wait for IO on any combination of
> named pipes, sockets, events, etc. and Windows appears to lack this, at least
> at the level of poll/select.
> 
> Thanks, I don't usually set up windbg remote debugging over named
> pipes so this indeed sounded plausible.
> 
> My Windows runs in a QEMU/KVM VM so to eliminate the pipe I have set
> up a virtual COM port like so:
> 
> -serial tcp:127.0.0.1:8889,server,nowait
> 
> and the nested QEMU ran with:
> 
> -windbg tcp:10.0.2.2:8889
> 
> where 10.0.2.2 is the address assigned to the host with user
> networking. Windbg then used the default COM1 to connect to the
> target. I routinely use COMx for remote debugging between VMs with a
> TCP connection on the host side acting as a null-modem cable and never
> had any timing related issues.
> 
> However, the symptoms were exactly the same with this set up.

Ok, then I agree this is probably not the same issue.

Andrew