Re: [Qemu-devel] [PATCH v2 00/18] Multiple fixes & improvements to QIOChannel & Win32

[Andrew Baumann]

Hi folks,

> From: Paolo Bonzini [mailto:address@hidden
> Sent: Thursday, 10 March 2016 9:37 AM
> 
> On 10/03/2016 18:26, Daniel P. Berrange wrote:
> > This series started out as an attempt to fix the Win32 problems
> > identified by Andrew Baumann
> >
> >    https://lists.gnu.org/archive/html/qemu-devel/2016-03/msg01343.html
> >
> > It turned into a significantly larger cleanup of some chardev
> > and osdep win32 portability code.
[...]

Sorry for chiming in a bit late here. I've tested these patches (the complete 
set, not individually), and they do appear to fix my immediate problem: socket 
char devices now work again. So thank you!

However, I'm now seeing a problem I don't believe we had before: very slow 
responses to GDB commands. From looking at a packet capture (using a localhost 
tcp socket between qemu and my gdb client), it seems that a couple of 
operations will go through just fine, and then there is a 1 second delay 
between my client's request and qemu's response. After fiddling with poll 
timeouts, it became clear that we were noticing the socket events when waking 
up from the poll, but the events themselves were still not waking us. It turns 
out that we were not calling WSAEventSelect on the accept path. At least, the 
following patch fixed the problem for me:

diff --git a/qemu-char.c b/qemu-char.c
index 3bf30b5..c1be622 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3047,6 +3047,7 @@ static gboolean tcp_chr_accept(QIOChannel *channel,
         return TRUE;
     }

+    qio_channel_set_blocking(QIO_CHANNEL(sioc), false, NULL);
     tcp_chr_new_client(chr, sioc);

     object_unref(OBJECT(sioc));

However, I'd note that both callers of tcp_chr_new_client() make the same call 
to set blocking to false immediately before calling tcp_chr_new_client(). 
Furthermore, the doc comment for qio_channel_set_blocking() appears to suggest 
that non-blocking mode is the default. If that's true, maybe you don't even 
want to rely on the caller explicitly setting blocking to false?

Cheers,
Andrew