Re: [PATCH] build-sys: fix win32 compilation with --target-list=''

[Marc-André Lureau]

Hi

On Fri, Dec 18, 2020 at 5:03 PM Marc-André Lureau <marcandre.lureau@redhat.com> wrote:

Hi

On Thu, Dec 17, 2020 at 3:47 PM Paolo Bonzini <pbonzini@redhat.com> wrote:

On 17/12/20 12:32, Claudio Fontana wrote:
> Is the root cause elsewhere though?
>
> I don't like stubs very much, because often they are introduced as the easy way out of a problem instead of doing the necessary refactoring,
> and they end up confusing the hell out of someone trying to understand what is actually used where, never mind trying to debug the linker errors.
>
> There is already an bunch of #ifndef _WIN32, #else , ... in util/main-loop.c (quite a bunch of them really),
> is that what actually needs reworking, and putting the pieces together in the build system in a way that makes sense?

qemu_fd_register is almost not needed at all, since we have

         WSAEventSelect(node->pfd.fd, event, bitmask);

in aio_set_fd_handler.  I think we can remove the call to
qemu_fd_register from qemu_try_set_nonblock, and that should fix the
issue as well.

That's tricky to say whether this won't introduce regression. For most fds from qemu, if they use aio_set_fd_handler, that should be ok.

But what about other fds? For examples, the ones from slirp? In fact, I don't understand how it could work today. We are passing socket() fd directly to g_poll(). But according to the documentation:

 * On Win32, the fd in a GPollFD should be Win32 HANDLE (*not* a file
 * descriptor as provided by the C runtime) that can be used by
 * MsgWaitForMultipleObjects. This does *not* include file handles
 * from CreateFile, SOCKETs, nor pipe handles. (But you can use
 * WSAEventSelect to signal events when a SOCKET is readable).

And MsgWaitForMultipleObjects doesn't mention SOCKET as being valid handles to wait for.

But when I run qemu with slirp, with or without qemu_fd_register, I don't see any error or regression.

Am I missing something?

I wrote a simple program to check the behaviour of WaitForMultipleObjects:

 

#include <winsock2.h>
#include <glib.h>

int main(int argc, char *argv[])
{
WSADATA Data;
WSAStartup(MAKEWORD(2, 0), &Data);
int fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
g_print("sock fd %d\n", fd);

HANDLE handles[1] = { (HANDLE)fd };
DWORD res = WaitForMultipleObjects(1, handles, FALSE, 1000);
g_print("wait res %x\n", res);
return 0;
}

Indeed, it doesn not complain about SOCKET as HANDLE here. But it will return immediately indicating that the socket has events.

We probably want to fix this. slirp should only fill pollfd with handles that are acceptable for WaitFor API I suppose.

Correct?

--

Marc-André Lureau