qemu-devel
[Top][All Lists]
Advanced

[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: Alberto Garcia
Subject: Re: [Qemu-devel] [PATCH 3/3] virtio-scsi: Forbid devices with different iothreads sharing a blockdev
Date: Mon, 28 Jan 2019 15:42:17 +0100
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

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? :-?

> 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?

Berto



reply via email to

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