From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57541 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDHks-0005t1-NZ for qemu-devel@nongnu.org; Tue, 02 Nov 2010 10:22:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDHka-0004Yv-Ni for qemu-devel@nongnu.org; Tue, 02 Nov 2010 10:22:13 -0400 Received: from e3.ny.us.ibm.com ([32.97.182.143]:56511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDHka-0004Ym-K8 for qemu-devel@nongnu.org; Tue, 02 Nov 2010 10:22:12 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oA2E546D004810 for ; Tue, 2 Nov 2010 10:05:04 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oA2EM4er1102034 for ; Tue, 2 Nov 2010 10:22:05 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oA2EM4KA020177 for ; Tue, 2 Nov 2010 10:22:04 -0400 Date: Tue, 2 Nov 2010 09:22:01 -0500 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal Message-ID: <20101102142201.GH22904@us.ibm.com> References: <1288030956-28383-1-git-send-email-ryanh@us.ibm.com> <20101029150336.GJ22904@us.ibm.com> <20101029165044.GM22904@us.ibm.com> <20101102134622.GG22904@us.ibm.com> <20101102135827.GB31007@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101102135827.GB31007@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Kevin Wolf , Markus Armbruster , qemu-devel@nongnu.org, Anthony Liguori , Ryan Harper , Stefan Hajnoczi * Michael S. Tsirkin [2010-11-02 08:59]: > On Tue, Nov 02, 2010 at 08:46:22AM -0500, Ryan Harper wrote: > > * Markus Armbruster [2010-11-02 04:40]: > > > >> >> I'd like to have some consistency among net, block and char device > > > >> >> commands, i.e. a common set of operations that work the same for all of > > > >> >> them. Can we agree on such a set? > > > >> > > > > >> > Yeah; the current trouble (or at least what I perceive to be trouble) is > > > >> > that in the case where the guest responds to device_del induced ACPI > > > >> > removal event; the current qdev code already does the host-side device > > > >> > tear down. Not sure if it is OK to do a blockdev_del() immediately > > > >> > after the device_del. What happens when we do: > > > >> > > > > >> > device_del > > > >> > ACPI to guest > > > >> > blockdev_del /* removes host-side device */ > > > >> > > > >> Fails in my tree, because the blockdev's still in use. See below. > > > >> > > > >> > guest responds to ACPI > > > >> > qdev calls pci device removal code > > > >> > qemu attempts to destroy the associated host-side block > > > >> > > > > >> > That may just work today; and if not, it shouldn't be hard to fix up the > > > >> > code to check for NULLs > > > >> > > > >> I hate the automatic deletion of host part along with the guest part. > > > >> device_del should undo device_add. {block,net,char}dev_{add,del} should > > > >> be similarly paired. > > > > > > > > Agreed. > > > >> > > > >> In my blockdev branch, I keep the automatic delete only for backwards > > > >> compatibility: if you create the drive with drive_add, it gets > > > >> auto-deleted, but if you use blockdev_add, it stays around. > > > > > > > > But what to do about the case where we're doing drive_add and then a > > > > device_del() That's the urgent situation that needs to be resolved. > > > > > > What's the exact problem we need to solve urgently? > > > > > > Is it "provide means to cut the connection to the host part immediately, > > > even with an uncooperative guest"? > > > > Yes, need to ensure that if the mgmt layer (libvirt) has done what it > > believes should have disassociated the host block device from the guest, > > we want to ensure that the host block device is no longer accessible > > from the guest. > > > > > > > > Does this need to be separate from device_del? > > > > no, it doesn't have to be. Honestly, I didn't see a clear way to do > > something like unplug early in the device_del because that's all pci > > device code which has no knowledge of host block devices; having it > > disconnect seemed like a layering violation. > > We invoke the cleanup callback, isn't that enough? Won't that look a bit strange? on device_del, call the cleanup callback first;, then notify the guest, if the guest responds, I suppose as long as the cleanup callback can handle being called a second time that'd work. I like the idea of disconnect; if part of the device_del method was to invoke a disconnect method, we could implement that for block, net, etc; I'd think we'd want to send the notification, then disconnect. Struggling with whether it's worth having some reasonable timeout between notification and disconnect. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com