From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh4p1-00071D-Qz for qemu-devel@nongnu.org; Mon, 05 Sep 2016 21:05:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bh4ox-00062p-Kc for qemu-devel@nongnu.org; Mon, 05 Sep 2016 21:05:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh4ox-00062U-CK for qemu-devel@nongnu.org; Mon, 05 Sep 2016 21:05:03 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6BD54C04B316 for ; Tue, 6 Sep 2016 01:05:02 +0000 (UTC) References: <20160901171148.697e696b@t450s.home> <5abeb25c-a8a9-9144-cb6f-724647c5f35a@redhat.com> <87d1ki3djk.fsf@dusky.pond.sub.org> <4b642f96-9fd6-844b-8d1f-395ad4b7bf79@redhat.com> From: Laine Stump Message-ID: <973ab732-8ea2-323f-f461-6c61d1ab8bd3@redhat.com> Date: Mon, 5 Sep 2016 21:05:00 -0400 MIME-Version: 1.0 In-Reply-To: <4b642f96-9fd6-844b-8d1f-395ad4b7bf79@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] qapi DEVICE_DELETED event issued *before* instance_finalize?! List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel Cc: Paolo Bonzini , Markus Armbruster , Michal Privoznik , libvir-list@redhat.com On 09/05/2016 05:36 AM, Paolo Bonzini wrote: > > On 05/09/2016 11:23, Markus Armbruster wrote: >>>> On the other hand, it is clearly documented that the DEVICE_DELETED >>>> event is sent as soon as guest acknowledges completion of device >>>> removal. So libvirt's buggy if we'd follow documentation strictly. But >>>> then again, I don't see much information value in "guest has detached >>>> device but qemu hasn't yet" event. Libvirt would ignore such event. >> Unless I'm missing something, libvirt needs an event that signals "Guest >> and QEMU are done with this device". Current DEVICE_DELETED isn't. >> >> Can we imagine a use for current DEVICE_DELETED, i.e. "Guest is done, >> but QEMU isn't"? >> >> Would anything break if we changed semantics of DEVICE_DELETED to what >> libvirt actually needs? >> >> If the answers are "no" and "no", let's do it. > There is a subtle aspect of this. After the current DEVICE_DELETED, the > device id is not used any more. So technically you could have > > device_add bar,id=foo > device_del foo > > // something in QEMU prevents the device from going away? > // for example there is a storage issue that blocks completion > // of a read(), and bar is a storage device > > device_add bar,id=foo > device_del foo > > // which foo is being deleted? The old one or the new one? > event DEVICE_DELETED > > DEVICE_DELETED does have a meaning: management cannot talk to the device > anymore in QMP once it is raised. > > Technically what libvirt wants to know for VFIO is not whether the > device is gone; it's whether the device's _backend_ (the VFIO file > descriptor) is gone. The device backend could have been a separate QOM > object, but it isn't. > > So perhaps we need a new event that is specific to VFIO? Sigh. I always hate adding more knobs... The original reason libvirt asked for the DEVICE_DELETED event was because there were cases where libvirt was attempting to re-use the device id when it was still in use by qemu, so attempts to attach new devices were failing. When it was provided we just assumed that "DEVICE_DELETED" meant "everybody is finished with this device, and it's safe to recycle all the resources now". I guess we generalized just a bit too much. From libvirt's point of view, I don't see any problem with widening the definition of the existing DEVICE_DELETED event. But if that doesn't make sense from QEMU's point of view, or if anyone can come up with a practical reason for wanting both events, we can of course modify our event handling accordingly (the simplest way would be to just ignore DEVICE_DELETED in the case of vfio devices, and wait for the new event to trigger both freeing of the device ID and re-attaching the device to its host driver; trying to release the device ID in response to DEVICE_DELETED, and then re-attach the device to the host driver in response to a separate event would just be adding an extra layer of waiting for no perceptible gain). Oh, or are you saying that for vfio devices it would have this new new event *instead of* DEVICE_DELETED for vfio devices? I don't really see the point of that... > > Thanks, > > Paolo > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list >