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

[Kevin Wolf <kwolf@redhat.com>]

Am 28.01.2019 um 15:42 hat Alberto Garcia geschrieben:
> On Thu 24 Jan 2019 10:12:22 AM CET, Kevin Wolf wrote:
> > Am 23.01.2019 um 17:16 hat Alberto Garcia geschrieben:
> >> On Wed 23 Jan 2019 04:47:30 PM CET, Paolo Bonzini wrote:
> >> >> You mean a common function with the code below?
> >> >> 
> >> >>>> +        ctx = blk_get_aio_context(sd->conf.blk);
> >> >>>> +        if (ctx != s->ctx && ctx != qemu_get_aio_context()) {
> >> >>>> +            error_setg(errp, "Cannot attach a blockdev that is using "
> >> >>>> +                       "a different iothread");
> >> >>>> +            return;
> >> >>>> +        }
> >> >> 
> >> >> Who else would be the user?
> >> >
> >> > If it isn't, probably virtio-blk should be using too.
> >> 
> >> I agree, but that's the problem that I mentioned on the cover letter.
> >> 
> >> In the virtio-blk case I don't know how to tell that the block device
> >> is using a different iothread during device_add, because the iothread
> >> is not set during realize() but by virtio_blk_data_plane_start() that
> >> happens only when I reboot the guest.
> >
> > 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. So probably we
need to do something to move the data plane initialisation into realize?

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.

> > Now, Paolo keeps talking about how AioContexts are going to disappear
> > soon (TM), so I wonder whether it's still worth fixing this properly
> > now?
> 
> Either way, should we commit this series already and later update it
> once we have a proper solution for virtio-blk?

Fine with me.

Kevin