From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:47418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1go87Z-0002NT-5k for qemu-devel@nongnu.org; Mon, 28 Jan 2019 09:42:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1go87Y-0007bI-CG for qemu-devel@nongnu.org; Mon, 28 Jan 2019 09:42:45 -0500 From: Alberto Garcia In-Reply-To: <20190124091222.GB4601@localhost.localdomain> References: <6ad371df66eecffccce29a0bd14695f40edd6120.1548171741.git.berto@igalia.com> <735410dc-a63e-6a28-4526-2caa810a797d@redhat.com> <20190124091222.GB4601@localhost.localdomain> Date: Mon, 28 Jan 2019 15:42:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 3/3] virtio-scsi: Forbid devices with different iothreads sharing a blockdev List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Paolo Bonzini , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz , Stefan Hajnoczi 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