From: Greg Kurz <groug@kaod.org>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, peter.maydell@linaro.org,
berrange@redhat.com, alex.williamson@redhat.com,
pbonzini@redhat.com, david@gibson.dropbear.id.au,
armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH for-2.10 3/3] qdev: defer DEVICE_DEL event until instance_finalize()
Date: Mon, 31 Jul 2017 19:11:19 +0200 [thread overview]
Message-ID: <20170731191119.13687ee2@bahia.lan> (raw)
In-Reply-To: <1501119055-4060-4-git-send-email-mdroth@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3646 bytes --]
On Wed, 26 Jul 2017 20:30:55 -0500
Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> DEVICE_DEL is currently emitted when a Device is unparented, as
> opposed to when it is finalized. The main design motivation for this
> seems to be that after unparent()/unrealize(), the Device is no
> longer visible to the guest, and thus the operation is complete
> from the perspective of management.
>
> However, there are cases where remaining host-side cleanup is also
> pertinent to management. The is generally handled by treating these
> resources as aspects of the "backend", which can be managed via
> separate interfaces/events, such as blockdev_add/del, netdev_add/del,
> object_add/del, etc, but some devices do not have this level of
> compartmentalization, namely vfio-pci, and possibly to lend themselves
> well to it.
>
> In the case of vfio-pci, the "backend" cleanup happens as part of
> the finalization of the vfio-pci device itself, in particular the
> cleanup of the VFIO group FD. Failing to wait for this cleanup can
> result in tools like libvirt attempting to rebind the device to
> the host while it's still being used by VFIO, which can result in
> host crashes or other misbehavior depending on the host driver.
>
> Deferring DEVICE_DEL still affords us the ability to manage backends
> explicitly, while also addressing cases like vfio-pci's, so we
> implement that approach here.
>
> An alternative proposal involving having VFIO emit a separate event
> to denote completion of host-side cleanup was discussed, but the
> prevailing opinion seems to be that it is not worth the added
> complexity, and leaves the issue open for other Device implementations
> solve in the future.
>
> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> ---
Reviewed-by: Greg Kurz <groug@kaod.org>
> hw/core/qdev.c | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> index 08c4061..d14acba 100644
> --- a/hw/core/qdev.c
> +++ b/hw/core/qdev.c
> @@ -1067,7 +1067,6 @@ static void device_finalize(Object *obj)
> NamedGPIOList *ngl, *next;
>
> DeviceState *dev = DEVICE(obj);
> - qemu_opts_del(dev->opts);
>
> QLIST_FOREACH_SAFE(ngl, &dev->gpios, node, next) {
> QLIST_REMOVE(ngl, node);
> @@ -1078,6 +1077,18 @@ static void device_finalize(Object *obj)
> * here
> */
> }
> +
> + /* Only send event if the device had been completely realized */
> + if (dev->pending_deleted_event) {
> + g_assert(dev->canonical_path);
> +
> + qapi_event_send_device_deleted(!!dev->id, dev->id, dev->canonical_path,
> + &error_abort);
> + g_free(dev->canonical_path);
> + dev->canonical_path = NULL;
> + }
> +
> + qemu_opts_del(dev->opts);
> }
>
> static void device_class_base_init(ObjectClass *class, void *data)
> @@ -1107,16 +1118,6 @@ static void device_unparent(Object *obj)
> object_unref(OBJECT(dev->parent_bus));
> dev->parent_bus = NULL;
> }
> -
> - /* Only send event if the device had been completely realized */
> - if (dev->pending_deleted_event) {
> - g_assert(dev->canonical_path);
> -
> - qapi_event_send_device_deleted(!!dev->id, dev->id, dev->canonical_path,
> - &error_abort);
> - g_free(dev->canonical_path);
> - dev->canonical_path = NULL;
> - }
> }
>
> static void device_class_init(ObjectClass *class, void *data)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-07-31 17:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-27 1:30 [Qemu-devel] [PATCH for-2.10 0/3] qdev/vfio: defer DEVICE_DEL to avoid races with libvirt Michael Roth
2017-07-27 1:30 ` [Qemu-devel] [PATCH for-2.10 1/3] qdev: store DeviceState's canonical path to use when unparenting Michael Roth
2017-07-27 1:30 ` [Qemu-devel] [PATCH for-2.10 2/3] Revert "qdev: Free QemuOpts when the QOM path goes away" Michael Roth
2017-07-31 15:51 ` Greg Kurz
2017-07-31 16:39 ` Michael Roth
2017-07-31 17:10 ` Greg Kurz
2017-07-27 1:30 ` [Qemu-devel] [PATCH for-2.10 3/3] qdev: defer DEVICE_DEL event until instance_finalize() Michael Roth
2017-07-31 17:11 ` Greg Kurz [this message]
2017-08-09 14:04 ` Auger Eric
2017-10-07 0:03 ` Michael Roth
2017-07-27 9:11 ` [Qemu-devel] [PATCH for-2.10 0/3] qdev/vfio: defer DEVICE_DEL to avoid races with libvirt Peter Maydell
2017-07-27 10:53 ` David Gibson
2017-07-27 11:50 ` Daniel P. Berrange
2017-08-08 19:40 ` Alex Williamson
2017-08-09 5:08 ` David Gibson
2017-09-05 19:35 ` Greg Kurz
2017-07-27 11:54 ` Michael Roth
2017-07-27 14:47 ` Alex Williamson
2017-07-28 3:14 ` David Gibson
2017-08-09 14:53 ` Auger Eric
2017-10-03 22:21 ` Michael Roth
2017-10-04 6:01 ` David Gibson
2017-10-06 10:23 ` David Gibson
2017-10-06 12:31 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170731191119.13687ee2@bahia.lan \
--to=groug@kaod.org \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=mdroth@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.