From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: qemu-devel@nongnu.org, "Daniel P. Berrangé" <berrange@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Julia Suvorova" <jusual@redhat.com>,
xen-devel@lists.xenproject.org, eesposit@redhat.com,
"Richard Henderson" <richard.henderson@linaro.org>,
"Fam Zheng" <fam@euphon.net>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Coiby Xu" <Coiby.Xu@gmail.com>,
"David Woodhouse" <dwmw2@infradead.org>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Peter Lieven" <pl@kamp.de>, "Paul Durrant" <paul@xen.org>,
"Richard W.M. Jones" <rjones@redhat.com>,
qemu-block@nongnu.org, "Stefano Garzarella" <sgarzare@redhat.com>,
"Anthony Perard" <anthony.perard@citrix.com>,
"Stefan Weil" <sw@weilnetz.de>,
"Xie Yongji" <xieyongji@bytedance.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Aarushi Mehta" <mehta.aaru20@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Hanna Reitz" <hreitz@redhat.com>,
"Ronnie Sahlberg" <ronniesahlberg@gmail.com>
Subject: Re: [PATCH v4 07/20] block/export: stop using is_external in vhost-user-blk server
Date: Wed, 3 May 2023 10:08:46 +0200 [thread overview]
Message-ID: <ZFIWjuST/9tHVNMG@redhat.com> (raw)
In-Reply-To: <20230502200645.GE535070@fedora>
[-- Attachment #1: Type: text/plain, Size: 3744 bytes --]
Am 02.05.2023 um 22:06 hat Stefan Hajnoczi geschrieben:
> On Tue, May 02, 2023 at 06:04:24PM +0200, Kevin Wolf wrote:
> > Am 25.04.2023 um 19:27 hat Stefan Hajnoczi geschrieben:
> > > vhost-user activity must be suspended during bdrv_drained_begin/end().
> > > This prevents new requests from interfering with whatever is happening
> > > in the drained section.
> > >
> > > Previously this was done using aio_set_fd_handler()'s is_external
> > > argument. In a multi-queue block layer world the aio_disable_external()
> > > API cannot be used since multiple AioContext may be processing I/O, not
> > > just one.
> > >
> > > Switch to BlockDevOps->drained_begin/end() callbacks.
> > >
> > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > ---
> > > block/export/vhost-user-blk-server.c | 43 ++++++++++++++--------------
> > > util/vhost-user-server.c | 10 +++----
> > > 2 files changed, 26 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/block/export/vhost-user-blk-server.c b/block/export/vhost-user-blk-server.c
> > > index 092b86aae4..d20f69cd74 100644
> > > --- a/block/export/vhost-user-blk-server.c
> > > +++ b/block/export/vhost-user-blk-server.c
> > > @@ -208,22 +208,6 @@ static const VuDevIface vu_blk_iface = {
> > > .process_msg = vu_blk_process_msg,
> > > };
> > >
> > > -static void blk_aio_attached(AioContext *ctx, void *opaque)
> > > -{
> > > - VuBlkExport *vexp = opaque;
> > > -
> > > - vexp->export.ctx = ctx;
> > > - vhost_user_server_attach_aio_context(&vexp->vu_server, ctx);
> > > -}
> > > -
> > > -static void blk_aio_detach(void *opaque)
> > > -{
> > > - VuBlkExport *vexp = opaque;
> > > -
> > > - vhost_user_server_detach_aio_context(&vexp->vu_server);
> > > - vexp->export.ctx = NULL;
> > > -}
> >
> > So for changing the AioContext, we now rely on the fact that the node to
> > be changed is always drained, so the drain callbacks implicitly cover
> > this case, too?
>
> Yes.
Ok. This surprised me a bit at first, but I think it's fine.
We just need to remember it if we ever decide that once we have
multiqueue, we can actually change the default AioContext without
draining the node. But maybe at that point, we have to do more
fundamental changes anyway.
> > > static void
> > > vu_blk_initialize_config(BlockDriverState *bs,
> > > struct virtio_blk_config *config,
> > > @@ -272,6 +256,25 @@ static void vu_blk_exp_resize(void *opaque)
> > > vu_config_change_msg(&vexp->vu_server.vu_dev);
> > > }
> > >
> > > +/* Called with vexp->export.ctx acquired */
> > > +static void vu_blk_drained_begin(void *opaque)
> > > +{
> > > + VuBlkExport *vexp = opaque;
> > > +
> > > + vhost_user_server_detach_aio_context(&vexp->vu_server);
> > > +}
> >
> > Compared to the old code, we're losing the vexp->export.ctx = NULL. This
> > is correct at this point because after drained_begin we still keep
> > processing requests until we arrive at a quiescent state.
> >
> > However, if we detach the AioContext because we're deleting the
> > iothread, won't we end up with a dangling pointer in vexp->export.ctx?
> > Or can we be certain that nothing interesting happens before drained_end
> > updates it with a new valid pointer again?
>
> If you want I can add the detach() callback back again and set ctx to
> NULL there?
I haven't thought enough about it to say if it's a problem. If you have
and are confident that it's correct the way it is, I'm happy with it.
But bringing the callback back is the minimal change compared to the old
state. It's just unnecessary code if we don't actually need it.
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-05-03 8:09 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-25 17:26 [PATCH v4 00/20] block: remove aio_disable_external() API Stefan Hajnoczi
2023-04-25 17:26 ` [PATCH v4 01/20] block-backend: split blk_do_set_aio_context() Stefan Hajnoczi
2023-04-25 17:26 ` [PATCH v4 02/20] hw/qdev: introduce qdev_is_realized() helper Stefan Hajnoczi
2023-04-25 17:26 ` [PATCH v4 03/20] virtio-scsi: avoid race between unplug and transport event Stefan Hajnoczi
2023-05-02 15:19 ` Kevin Wolf
2023-05-02 18:56 ` Stefan Hajnoczi
2023-05-03 8:00 ` Kevin Wolf
2023-05-03 13:12 ` Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 04/20] virtio-scsi: stop using aio_disable_external() during unplug Stefan Hajnoczi
2023-04-28 14:22 ` Kevin Wolf
2023-05-01 15:09 ` Stefan Hajnoczi
2023-05-02 13:19 ` Kevin Wolf
2023-05-02 20:02 ` Stefan Hajnoczi
2023-05-03 11:40 ` Kevin Wolf
2023-05-03 13:05 ` Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 05/20] util/vhost-user-server: rename refcount to in_flight counter Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 06/20] block/export: wait for vhost-user-blk requests when draining Stefan Hajnoczi
2023-05-02 15:42 ` Kevin Wolf
2023-05-02 19:40 ` Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 07/20] block/export: stop using is_external in vhost-user-blk server Stefan Hajnoczi
2023-05-02 16:04 ` Kevin Wolf
2023-05-02 20:06 ` Stefan Hajnoczi
2023-05-03 8:08 ` Kevin Wolf [this message]
2023-05-03 13:11 ` Stefan Hajnoczi
2023-05-03 13:43 ` Kevin Wolf
2023-04-25 17:27 ` [PATCH v4 08/20] hw/xen: do not use aio_set_fd_handler(is_external=true) in xen_xenstore Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 09/20] block: add blk_in_drain() API Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 10/20] block: drain from main loop thread in bdrv_co_yield_to_drain() Stefan Hajnoczi
2023-05-02 16:21 ` Kevin Wolf
2023-05-02 20:10 ` Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 11/20] xen-block: implement BlockDevOps->drained_begin() Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 12/20] hw/xen: do not set is_external=true on evtchn fds Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 13/20] block/export: rewrite vduse-blk drain code Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 14/20] block/export: don't require AioContext lock around blk_exp_ref/unref() Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 15/20] block/fuse: do not set is_external=true on FUSE fd Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 16/20] virtio: make it possible to detach host notifier from any thread Stefan Hajnoczi
2023-05-04 21:00 ` Kevin Wolf
2023-05-10 21:40 ` Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 17/20] virtio-blk: implement BlockDevOps->drained_begin() Stefan Hajnoczi
2023-05-04 21:13 ` Kevin Wolf
2023-05-11 20:54 ` Stefan Hajnoczi
2023-05-11 21:22 ` Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 18/20] virtio-scsi: " Stefan Hajnoczi
2023-05-04 21:25 ` Kevin Wolf
2023-04-25 17:27 ` [PATCH v4 19/20] virtio: do not set is_external=true on host notifiers Stefan Hajnoczi
2023-04-25 17:27 ` [PATCH v4 20/20] aio: remove aio_disable_external() API Stefan Hajnoczi
2023-05-04 21:34 ` Kevin Wolf
2023-05-11 21:24 ` Stefan Hajnoczi
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=ZFIWjuST/9tHVNMG@redhat.com \
--to=kwolf@redhat.com \
--cc=Coiby.Xu@gmail.com \
--cc=anthony.perard@citrix.com \
--cc=berrange@redhat.com \
--cc=dwmw2@infradead.org \
--cc=eduardo@habkost.net \
--cc=eesposit@redhat.com \
--cc=fam@euphon.net \
--cc=hreitz@redhat.com \
--cc=jusual@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mehta.aaru20@gmail.com \
--cc=mst@redhat.com \
--cc=paul@xen.org \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=rjones@redhat.com \
--cc=ronniesahlberg@gmail.com \
--cc=sgarzare@redhat.com \
--cc=sstabellini@kernel.org \
--cc=stefanha@redhat.com \
--cc=sw@weilnetz.de \
--cc=xen-devel@lists.xenproject.org \
--cc=xieyongji@bytedance.com \
/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).