From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDtYj-0006rc-1u for qemu-devel@nongnu.org; Fri, 08 Mar 2013 04:25:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDtYh-0000qv-1w for qemu-devel@nongnu.org; Fri, 08 Mar 2013 04:25:48 -0500 Received: from smtp.vivo.cz ([85.132.139.19]:42207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDtYg-0000qG-R9 for qemu-devel@nongnu.org; Fri, 08 Mar 2013 04:25:46 -0500 Date: Fri, 8 Mar 2013 10:25:42 +0100 From: Jiri Denemark Message-ID: <20130308092542.GG326424@orkuz.home> References: <20130307100740.GB5302@redhat.com> <5138921D.5050604@suse.de> <87ehfrcn60.fsf@blackfin.pond.sub.org> <20130307163540.GB29071@redhat.com> <87k3pj3yzh.fsf@blackfin.pond.sub.org> <20130307181229.GB30633@redhat.com> <5138E3CD.8090105@suse.de> <20130307191549.GA12543@redhat.com> <51398EA3.5030004@redhat.com> <87boaujmvk.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87boaujmvk.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH] qdev: DEVICE_DELETED event List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Anthony Liguori , Eduardo Habkost , "Michael S. Tsirkin" , "libvir-list@redhat.com" , Stefan Hajnoczi , qemu-devel@nongnu.org, Luiz Capitulino , laine@redhat.com, Gerd Hoffmann , Osier Yang , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= On Fri, Mar 08, 2013 at 09:50:55 +0100, Markus Armbruster wrote: > Osier Yang writes: > > > I'm wondering if it could be long time to wait for the device_del > > completes (AFAIK from previous bugs, it can be, though it should be > > fine for most of the cases). If it's too long, it will be a problem > > for management, because it looks like hanging. We can have a timeout > > for the device_del in libvirt, but the problem is the device_del > > can be still in progress by qemu, which could cause the inconsistency. > > Unless qemu has some command to cancel the device_del. > > I'm afraid cancelling isn't possible, at least not for PCI. I don't think we need anything like that. We just need the device deletion API to return immediately without actually removing stuff from domain definition (unless the device was really removed fast enough, e.g., USB devices are removed before device_del returns) and then remove the device from domain definition when we get the event from QEMU or when libvirtd reconnects to a domain and sees a particular device is no longer present. After all, devices may be removed even if we didn't ask for it (when the removal is initiated by a guest OS). And we should also provide similar event for higher level apps. The question is whether we can make use of our existing API or if we need to introduce a new one. But that's of little relevance to qemu-devel I guess. Jirka