From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpqHt-0007Cy-Jj for qemu-devel@nongnu.org; Fri, 30 Sep 2016 01:23:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpqHr-0005o4-IL for qemu-devel@nongnu.org; Fri, 30 Sep 2016 01:23:08 -0400 Date: Fri, 30 Sep 2016 13:22:58 +0800 From: Fam Zheng Message-ID: <20160930052258.GA2564@lemon> References: <1474958276-7715-1-git-send-email-famz@redhat.com> <1474958276-7715-6-git-send-email-famz@redhat.com> <20160929030543.GD6412@lemon> <3a5afa67-e580-cd20-6d19-9c9071bf55a0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a5afa67-e580-cd20-6d19-9c9071bf55a0@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 5/5] block: keep AioContext pointer in BlockBackend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: mreitz@redhat.com, kwolf@redhat.com, jcody@redhat.com Cc: Paolo Bonzini , stefanha@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org On Thu, 09/29 09:47, Paolo Bonzini wrote: > > > On 29/09/2016 05:05, Fam Zheng wrote: > > > So whether we can move a certain BB from some context to another depends > > > on what the frontend supports, I don't think there is a generic answer > > > we can implement here in the generic BB code. NBD for instance allows > > > any movement; but devices probably only allow movements they have > > > initiated themselves (e.g. dataplane will allow exactly what you > > > describe here with that assertion, and any other device will probably > > > not allow anything but the main loop). > > > > Indeed, you make me think this should be an op blocker (that applies on whole > > graph). > > The concept of a BDS or BB's AioContext is going to disappear sooner or > later, take this into account to decide how much effort to put into > fixing this. Taking one step back, the whole thing is so broken considering the node reference. Currently, even this is possible: -drive file=null-co://,if=virtio,id=d0 \ -drive file.file=d0,driver=raw,file.driver=raw,if=virtio AioContext is actually a factor to make it worse. Maybe we should instead think about some generic protection mechanism? Is this in the scope of new op blocker? Fam