[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/3] virtio-scsi: Forbid devices with different

From: Kevin Wolf
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
User-agent: Mutt/1.10.1 (2018-07-13)

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

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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]