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

[Ladi Prosek]

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.

I've also run the original command lines using a pipe on a physical
Windows machine, just in case being in a VM somehow screws it up.
Again, same issue.

At this point I think it would make sense for Mihai to take a look at
the trace in my previous email and maybe compare it with what works
for him.

For completeness, in the unlikely case that it makes a difference, I'm
on Win10 (tried 1511 and 1703) and use windbg that comes with one of
the latest WDK.

Thanks!
Ladi

> My workaround at the time was to kludge up a proxy between sockets and named 
> pipes, so the connection was:
> qemu <-socket-> proxy <-named pipe-> windbg
>
> (The proxy was a fairly flaky python script, but it was good enough to tide 
> me over until I could get kdnet working. I can probably dig it out if you're 
> interested.)
>
> Cheers,
> Andrew