From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDuyt-0001rY-UW for qemu-devel@nongnu.org; Fri, 08 Mar 2013 05:56:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDuys-0000R6-4f for qemu-devel@nongnu.org; Fri, 08 Mar 2013 05:56:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23846) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDuyr-0000Qp-TO for qemu-devel@nongnu.org; Fri, 08 Mar 2013 05:56:54 -0500 Message-ID: <5139C3EB.3070401@redhat.com> Date: Fri, 08 Mar 2013 18:56:43 +0800 From: Osier Yang MIME-Version: 1.0 References: <51374B42.2090405@suse.de> <20130306141324.GA30001@redhat.com> <87y5dzlek4.fsf@blackfin.pond.sub.org> <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> In-Reply-To: <87boaujmvk.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 , Gerd Hoffmann , laine@redhat.com, Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 2013=E5=B9=B403=E6=9C=8808=E6=97=A5 16:50, 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. > > Here's how device_del works for PCI when it works, roughly: > > 1. device_del asks the device model to unplug itself. > > 2. PCI device models delegate the job to the device model providing > their PCI bus. Let's assume it's our PIIX3/PIIX4 mongrel. That on= e > puts an unplug request into PIIX4 function 3 where guest ACPI can s= ee > it, and triggers its interrupt. Then it immediately sends the QMP > success reply. > > 3. Guest ACPI (SeaBIOS) services the interrupt. It finds the unplug > request, and asks the guest OS nicely to give up the device. > > 4. If the guest OS has a working ACPI driver, and it feels like giving > up the device, it does so, and tells ACPI when it's done. > > 5. Guest ACPI cleans up whatever it needs cleaned up, and signals > successful unplug by writing the slog number to a PIIX4 function 3 > register. > > 6. The PIIX device destroys the device in that slot. > > I call this the ACPI unplug dance. > > We don't control steps 3..5. > > There's no way for the guest to tell us "I got your unplug request, but > I'm not going to honor it". Even if their was, a guest without a > working ACPI driver wouldn't use it, so we couldn't rely on it anyway. > > There's no way for us to tell the guest "I changed my mind on this > unplug". All we can do is wait and see. Either the device goes away, > or it stays. Hum, as I replied to Jirka in later mail, IMHO it needs to change libvirt detaching APIs to either wait for the event or find the device is really removed by polling before returning success. But it sounds to me that how long it takes to wait or polling is really depended? Osier