From: Kevin Wolf <kwolf@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
Max Reitz <mreitz@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] virtio-scsi: Forbid devices with different iothreads sharing a blockdev
Date: Mon, 28 Jan 2019 17:01:09 +0100 [thread overview]
Message-ID: <20190128160109.GF5756@localhost.localdomain> (raw)
In-Reply-To: <w517eeoss2l.fsf@maestria.local.igalia.com>
Am 28.01.2019 um 16:46 hat Alberto Garcia geschrieben:
> On Mon 28 Jan 2019 03:57:43 PM CET, Kevin Wolf wrote:
>
> >> > I think the proper solution on the block layer level would be that
> >> > AioContext is managed per BdrvChild and only BdrvChild objects with
> >> > the same AioContext can be attached to the same node.
> >> > bdrv_set_aio_context() would then fail if another parent is already
> >> > using the node.
> >>
> >> How would that solve the virtio-blk problem, though? :-?
> >
> > It wouldn't, but it would make clear that bdrv_set_aio_context() can
> > fail and we'd have to handle the problem exactly there.
>
> Yes, that sound like the proper solution.
>
> > The only other option I see is downgrading to non-dataplane mode, but
> > this would have to be silent because during machine reset we have no
> > way to report errors.
>
> Yes, I actually had a patch doing that, but as you said the user has no
> way of knowing that it went wrong.
>
> If you have 2 or 3 virtio-blk devices with different iothreads using the
> same BDS then after the guest reboot only one would succeed, but you
> can't see which one, or can you?
I suppose you could add a QOM property that tells whether the assigned
iothread is actually in use, but it would still be quite obscure. And
you would have to check explicitly, so I don't think that's a good
solution.
And actually... if you move the first virtio-blk device to an iothread,
then downgrading the others isn't going to save us, because that would
still be using the backend from two threads (one successfully enabled
iothread, and the main thread).
Kevin
next prev parent reply other threads:[~2019-01-28 16:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 15:53 [Qemu-devel] [PATCH 0/3] iothread-related fixes for virtio-scsi Alberto Garcia
2019-01-22 15:53 ` [Qemu-devel] [PATCH 1/3] virtio-scsi: Move BlockBackend back to the main AioContext on unplug Alberto Garcia
2019-01-22 15:53 ` [Qemu-devel] [PATCH 2/3] scsi-disk: Acquire the AioContext in scsi_*_realize() Alberto Garcia
2019-01-22 15:53 ` [Qemu-devel] [PATCH 3/3] virtio-scsi: Forbid devices with different iothreads sharing a blockdev Alberto Garcia
2019-01-23 9:46 ` Paolo Bonzini
2019-01-23 15:09 ` Alberto Garcia
2019-01-23 15:47 ` Paolo Bonzini
2019-01-23 16:16 ` Alberto Garcia
2019-01-24 9:12 ` Kevin Wolf
2019-01-28 14:42 ` Alberto Garcia
2019-01-28 14:57 ` Kevin Wolf
2019-01-28 15:46 ` Alberto Garcia
2019-01-28 16:01 ` Kevin Wolf [this message]
2019-01-28 16:15 ` Alberto Garcia
2019-01-28 16:30 ` Kevin Wolf
2019-01-28 15:31 ` [Qemu-devel] [PATCH 0/3] iothread-related fixes for virtio-scsi Kevin Wolf
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=20190128160109.GF5756@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=berto@igalia.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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).