qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Claudio Fontana <cfontana@suse.de>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PATCH] build-sys: fix win32 compilation with --target-list=''
Date: Fri, 18 Dec 2020 17:33:56 +0400	[thread overview]
Message-ID: <CAJ+F1CLh2pbdTrGG5+aMxjdMAZRfbip4L1gjowCfNiY-F2AcyQ@mail.gmail.com> (raw)
In-Reply-To: <4287c327-0e3e-5f35-b078-0360796e6103@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

Hi

On Fri, Dec 18, 2020 at 5:24 PM Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 18/12/20 14:01, Marc-André Lureau wrote:
> >> 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?
>
> slirp already calls qemu_fd_register, see net_slirp_register_poll_fd
>
> > 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.
>
> No, it's more complicated.  On Win32, gpollfds is only used for sockets
> (despite the name!), while poll_fds is used for prepare/query/g_poll/check.
>
> What we do is basically the same that QIOChannel and aio-win32.c already
> do, just with more indirection to fit the SLIRP callback API:
>
> - main_loop_wait calls net_slirp_poll_notify, which asks SLIRP to send
> back the list of file descriptors through the net_slirp_add_poll callback.
>
> - the file descriptors are stored in the gpollfds global.
>
> - os_host_main_loop_wait does a select on the sockets with 0 timeout
>
> - if no socket is ready, g_poll is done with the original timeout
> (otherwise the timeout is zeroed)
>
>
- the sockets were registered with WSAEventSelect in
> net_slirp_register_poll_fd, so they interrupt the subsequent g_poll if
> data comes in.
>
>
Ah thanks, I mixed the unix and the win32 versions.


> I don't see any other use of MainLoopPoll, so all non-SLIRP sockets
> should be going through {qemu,aio}_set_fd_handler.  In particular this
> is the case for all of chardev/ (which uses QIOChannel), io/ and net/.
> These are all the other users of qemu_set_nonblock and
> qemu_try_set_nonblock.
>
>
Ok, I guess we can simply register fd to be a win32-specific call for slirp
then.


> Paolo
>
> > 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?
>
>
>

-- 
Marc-André Lureau

[-- Attachment #2: Type: text/html, Size: 3830 bytes --]

  reply	other threads:[~2020-12-18 13:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17 10:44 [PATCH] build-sys: fix win32 compilation with --target-list='' marcandre.lureau
2020-12-17 11:32 ` Claudio Fontana
2020-12-17 11:41   ` Marc-André Lureau
2020-12-17 11:46   ` Paolo Bonzini
2020-12-18 13:01     ` Marc-André Lureau
2020-12-18 13:21       ` Paolo Bonzini
2020-12-18 13:33         ` Marc-André Lureau [this message]
2020-12-18 13:23       ` Marc-André Lureau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ+F1CLh2pbdTrGG5+aMxjdMAZRfbip4L1gjowCfNiY-F2AcyQ@mail.gmail.com \
    --to=marcandre.lureau@gmail.com \
    --cc=cfontana@suse.de \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).