From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42148 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PDNOc-0005mi-9d for qemu-devel@nongnu.org; Tue, 02 Nov 2010 16:23:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PDNOa-0003Hl-52 for qemu-devel@nongnu.org; Tue, 02 Nov 2010 16:23:53 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:38146) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PDNOa-0003Gm-19 for qemu-devel@nongnu.org; Tue, 02 Nov 2010 16:23:52 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oA2KGG3w025482 for ; Tue, 2 Nov 2010 16:16:16 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oA2KNijY448956 for ; Tue, 2 Nov 2010 16:23:44 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oA2KNhjs031160 for ; Tue, 2 Nov 2010 14:23:44 -0600 Date: Tue, 2 Nov 2010 15:23:38 -0500 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal Message-ID: <20101102202338.GB3469@us.ibm.com> References: <20101029165044.GM22904@us.ibm.com> <20101102134622.GG22904@us.ibm.com> <20101102135827.GB31007@redhat.com> <20101102142201.GH22904@us.ibm.com> <20101102154615.GB32448@redhat.com> <20101102165339.GK22904@us.ibm.com> <20101102175922.GA1939@redhat.com> <20101102190108.GA3469@us.ibm.com> <20101102191749.GD2744@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101102191749.GD2744@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 , yamahata@valinux.co.jp, Markus Armbruster , qemu-devel@nongnu.org, Anthony Liguori , Ryan Harper , Stefan Hajnoczi * Michael S. Tsirkin [2010-11-02 14:18]: > On Tue, Nov 02, 2010 at 02:01:08PM -0500, Ryan Harper wrote: > > > > > > 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. > > > > > > > > > > The problem with this is that it has no analog in real world. > > > > > In real world, you can send some notifications to the guest, and you can > > > > > remove the card. Tying them together is what created the problem in the > > > > > first place. > > > > > > > > > > Timeouts can be implemented by management, maybe with a nice dialog > > > > > being shown to the user. > > > > > > > > Very true. I'm fine with forcing a disconnect during the removal path > > > > prior to notification. Do we want a new disconnect method at the device > > > > level (pci)? or just use the existing removal callback and call that > > > > during the initial hotremov event? > > > > > > Not sure what you mean by that, but I don't see a device doing anything > > > differently wrt surprise or ordered removal. So probably the existing > > > callback should do. I don't think we need to talk about disconnect: > > > since we decided we are emulating device removal, let's call it > > > just that. > > > > Because current the "removal" process depends on the guest actually > > responding. What I'm suggesting is that, in Marcus's term, and what > > drive_unplug() implements, is to disconnect the host block device from > > the guest device to prevent any further access to it in the case the > > guest doesn't respond to the removal request made via ACPI. > > > > Very specifically, what we're suggesting instead of the drive_unplug() > > command so to complete the device removal operation without waiting for > > the guest to respond; that's what's going to happen if we invoke the > > response callback; it will appear as if the guest responded whether it > > did or not. > > > > What I was suggesting above was to instead of calling the callback for > > handing the guest response was to add a device function called > > disconnect which would remove any association of host resources from > > guest resources before we notified the guest. Thinking about it again > > I'm not sure this is useful, but if we're going to remove the device > > without the guests knowledge, I'm not sure how useful sending the > > removal requests via ACPI is in the first place. > > > > My feeling is that I'd like to have explicit control over the disconnect > > from host resources separate from the device removal *if* we're going to > > retain the guest notification. If we don't care to notify the guest, > > then we can just do device removal without notifying the guest > > and be done with it. > > I imagine management would typically want to do this: > 1. notify guest > 2. wait a bit > 3. remove device Yes; but this argues for (1) being a separate command from (3) unless we require (3) to include (1) and (2) in the qemu implementation. Currently we implement: 1. device_del (attempt to remove device) 2. notify guest 3. if guest responds, remove device 4. disconnect host resource from device on destruction With my drive_unplug patch we do: 1. disconnect host resource from device 2. device_del (attempt to remove device) 3. notify guest 4. if guest responds, remove device I think we're suggesting to instead do (if we keep disconnect as part of device_del) 1. device_del (attemp to remove device) 2. notify guest 3. invoke device destruction callback resulting in disconnect host resource from device 4. if guest responds, invoke device destruction path a second time. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com