From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39119 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PE3F8-0002oJ-JA for qemu-devel@nongnu.org; Thu, 04 Nov 2010 13:04:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PE3F6-00039h-Ui for qemu-devel@nongnu.org; Thu, 04 Nov 2010 13:04:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58206) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PE3F6-00039X-LB for qemu-devel@nongnu.org; Thu, 04 Nov 2010 13:04:52 -0400 Date: Thu, 4 Nov 2010 19:04:34 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH 0/3] v4 Decouple block device removal from device removal Message-ID: <20101104170434.GF1038@redhat.com> References: <20101102191749.GD2744@redhat.com> <20101102202338.GB3469@us.ibm.com> <20101103072134.GA6772@redhat.com> <20101103120443.GD3469@us.ibm.com> <20101103172910.GT3469@us.ibm.com> <20101103180224.GB19117@redhat.com> <20101103205929.GF3469@us.ibm.com> <20101103212640.GB20833@redhat.com> <20101104164551.GB20081@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101104164551.GB20081@us.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ryan Harper Cc: Kevin Wolf , yamahata@valinux.co.jp, Markus Armbruster , qemu-devel@nongnu.org, Anthony Liguori , Stefan Hajnoczi On Thu, Nov 04, 2010 at 11:45:51AM -0500, Ryan Harper wrote: > OK. With netdev_del and drive_unplug commands (not sure if we care to > change the names to be similar, maybe blockdev_del) in qemu, we can then > implement the following in libvirt: > > 1) detach-device invocation > 2) issue device_del to QEMU > 2a) notification is sent) > 3) issue netdev_del/blockdev_del as appropriate for the device type > 4) update guest XML to indicate device has been removed > And a fancier version would look like: > > 1) detach-device invocation > 2) issue device_del to QEMU > 2a) notification is sent) > 3) set a timeout for guest to respond > 4) when timeout expires > 4a) check if the pci device has been removed by quering QEMU > if it hasn't been removed, issue netdev_del/blockdev_del I think it's easier to check the network device: info network and whatever is appropriate for block > 5) update guest XML to indicate device has been removed > > > in both cases, I think we'll also want a patch that validates that the > pci slot is available before handing it out again; this will handle the > case where the guest doesn't respond to the device removal request; our > net/blockdev_del command will break the host/guest association, but we > don't want to attempt to attach a device to the same slot. Yes, absolutely. And same for qdev device id. > Marcus, do you think we're at a point where the mechanisms for > explicitly revoking access to the host resource is consistent between > net and block? > > If so, then I suppose I might have a consmetic patch to fix up the > monitor command name to line up with the netdev_del. > > > -- > Ryan Harper > Software Engineer; Linux Technology Center > IBM Corp., Austin, Tx > ryanh@us.ibm.com