[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting
From: |
Andrew Baumann |
Subject: |
Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting |
Date: |
Mon, 6 Nov 2017 18:41:29 +0000 |
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.
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