From: Stefan Hajnoczi <stefanha@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, Daniel Berrange <berrange@redhat.com>,
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>,
Leonardo Bras <leobras@redhat.com>,
farosas@suse.de, Hanna Reitz <hreitz@redhat.com>,
Juan Quintela <quintela@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>, Peter Xu <peterx@redhat.com>,
kwolf@redhat.com, Coiby Xu <Coiby.Xu@gmail.com>,
Fam Zheng <fam@euphon.net>
Subject: Re: [PATCH v3 4/4] io: follow coroutine AioContext in qio_channel_yield()
Date: Fri, 8 Sep 2023 06:49:53 -0400 [thread overview]
Message-ID: <20230908104953.GE3552950@fedora> (raw)
In-Reply-To: <k34b7gfkxtjrhflgtqrbg23gthoa7x3o3hs2kwhqi3jdhphcio@aukpe23gjewv>
[-- Attachment #1: Type: text/plain, Size: 5590 bytes --]
On Thu, Sep 07, 2023 at 03:41:08PM -0500, Eric Blake wrote:
> On Wed, Aug 30, 2023 at 06:48:02PM -0400, Stefan Hajnoczi wrote:
> > The ongoing QEMU multi-queue block layer effort makes it possible for multiple
> > threads to process I/O in parallel. The nbd block driver is not compatible with
> > the multi-queue block layer yet because QIOChannel cannot be used easily from
> > coroutines running in multiple threads. This series changes the QIOChannel API
> > to make that possible.
> >
> ...
> >
> > This API change allows the nbd block driver to use QIOChannel from any thread.
> > It's important to keep in mind that the block driver already synchronizes
> > QIOChannel access and ensures that two coroutines never read simultaneously or
> > write simultaneously.
> >
> > This patch updates all users of qio_channel_attach_aio_context() to the
> > new API. Most conversions are simple, but vhost-user-server requires a
> > new qemu_coroutine_yield() call to quiesce the vu_client_trip()
> > coroutine when not attached to any AioContext.
> >
> > While the API is has become simpler, there is one wart: QIOChannel has a
> > special case for the iohandler AioContext (used for handlers that must not run
> > in nested event loops). I didn't find an elegant way preserve that behavior, so
> > I added a new API called qio_channel_set_follow_coroutine_ctx(ioc, true|false)
> > for opting in to the new AioContext model. By default QIOChannel uses the
> > iohandler AioHandler. Code that formerly called
> > qio_channel_attach_aio_context() now calls
> > qio_channel_set_follow_coroutine_ctx(ioc, true) once after the QIOChannel is
> > created.
> >
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > Reviewed-by: Eric Blake <eblake@redhat.com>
> > Acked-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> > include/io/channel-util.h | 23 ++++++
> > include/io/channel.h | 69 ++++++++----------
> > include/qemu/vhost-user-server.h | 1 +
> > block/nbd.c | 11 +--
> > io/channel-command.c | 10 ++-
> > io/channel-file.c | 9 ++-
> > io/channel-null.c | 3 +-
> > io/channel-socket.c | 9 ++-
> > io/channel-tls.c | 6 +-
> > io/channel-util.c | 24 +++++++
> > io/channel.c | 120 ++++++++++++++++++++++---------
> > migration/channel-block.c | 3 +-
> > nbd/server.c | 14 +---
> > scsi/qemu-pr-helper.c | 4 +-
> > util/vhost-user-server.c | 27 +++++--
> > 15 files changed, 216 insertions(+), 117 deletions(-)
>
> Looks like migration/rdma.c is also impacted:
>
> ../migration/rdma.c: In function ‘qio_channel_rdma_class_init’:
> ../migration/rdma.c:4037:38: error: assignment to ‘void (*)(QIOChannel *, AioContext *, void (*)(void *), AioContext *, void (*)(void *), void *)’ from incompatible pointer type ‘void (*)(QIOChannel *, AioContext *, void (*)(void *), void (*)(void *), void *)’ [-Werror=incompatible-pointer-types]
> 4037 | ioc_klass->io_set_aio_fd_handler = qio_channel_rdma_set_aio_fd_handler;
> | ^
>
> I'm squashing this in:
>
> diff --git i/migration/rdma.c w/migration/rdma.c
> index ca430d319d9..a2a3db35b1d 100644
> --- i/migration/rdma.c
> +++ w/migration/rdma.c
> @@ -3103,22 +3103,23 @@ static GSource *qio_channel_rdma_create_watch(QIOChannel *ioc,
> }
>
> static void qio_channel_rdma_set_aio_fd_handler(QIOChannel *ioc,
> - AioContext *ctx,
> - IOHandler *io_read,
> - IOHandler *io_write,
> - void *opaque)
> + AioContext *read_ctx,
> + IOHandler *io_read,
> + AioContext *write_ctx,
> + IOHandler *io_write,
> + void *opaque)
> {
> QIOChannelRDMA *rioc = QIO_CHANNEL_RDMA(ioc);
> if (io_read) {
> - aio_set_fd_handler(ctx, rioc->rdmain->recv_comp_channel->fd, io_read,
> - io_write, NULL, NULL, opaque);
> - aio_set_fd_handler(ctx, rioc->rdmain->send_comp_channel->fd, io_read,
> - io_write, NULL, NULL, opaque);
> + aio_set_fd_handler(read_ctx, rioc->rdmain->recv_comp_channel->fd,
> + io_read, io_write, NULL, NULL, opaque);
> + aio_set_fd_handler(read_ctx, rioc->rdmain->send_comp_channel->fd,
> + io_read, io_write, NULL, NULL, opaque);
> } else {
> - aio_set_fd_handler(ctx, rioc->rdmaout->recv_comp_channel->fd, io_read,
> - io_write, NULL, NULL, opaque);
> - aio_set_fd_handler(ctx, rioc->rdmaout->send_comp_channel->fd, io_read,
> - io_write, NULL, NULL, opaque);
> + aio_set_fd_handler(write_ctx, rioc->rdmaout->recv_comp_channel->fd,
> + io_read, io_write, NULL, NULL, opaque);
> + aio_set_fd_handler(write_ctx, rioc->rdmaout->send_comp_channel->fd,
> + io_read, io_write, NULL, NULL, opaque);
> }
> }
Thank you!
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-09-08 10:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-30 22:47 [PATCH v3 0/4] io: follow coroutine AioContext in qio_channel_yield() Stefan Hajnoczi
2023-08-30 22:47 ` [PATCH v3 1/4] nbd: drop unused nbd_receive_negotiate() aio_context argument Stefan Hajnoczi
2023-08-30 22:48 ` [PATCH v3 2/4] nbd: drop unused nbd_start_negotiate() " Stefan Hajnoczi
2023-08-30 22:48 ` [PATCH v3 3/4] io: check there are no qio_channel_yield() coroutines during ->finalize() Stefan Hajnoczi
2023-08-30 22:48 ` [PATCH v3 4/4] io: follow coroutine AioContext in qio_channel_yield() Stefan Hajnoczi
2023-09-07 20:41 ` Eric Blake
2023-09-08 10:49 ` Stefan Hajnoczi [this message]
2023-08-31 13:31 ` [PATCH v3 0/4] " Eric Blake
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=20230908104953.GE3552950@fedora \
--to=stefanha@redhat.com \
--cc=Coiby.Xu@gmail.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=fam@euphon.net \
--cc=farosas@suse.de \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=leobras@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=vsementsov@yandex-team.ru \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.