All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jag Raman <jag.raman@oracle.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "eduardo@habkost.net" <eduardo@habkost.net>,
	Elena Ufimtseva <elena.ufimtseva@oracle.com>,
	John Johnson <john.g.johnson@oracle.com>,
	"berrange@redhat.com" <berrange@redhat.com>,
	"bleal@redhat.com" <bleal@redhat.com>,
	"john.levon@nutanix.com" <john.levon@nutanix.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"quintela@redhat.com" <quintela@redhat.com>,
	"f4bug@amsat.org" <f4bug@amsat.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Kanth Ghatraju <kanth.ghatraju@oracle.com>,
	"thanos.makatos@nutanix.com" <thanos.makatos@nutanix.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"eblake@redhat.com" <eblake@redhat.com>,
	"dgilbert@redhat.com" <dgilbert@redhat.com>
Subject: Re: [PATCH v6 03/19] qdev: unplug blocker for devices
Date: Mon, 28 Feb 2022 16:23:18 +0000	[thread overview]
Message-ID: <F110D666-049A-4F82-A5AB-044BD61843CC@oracle.com> (raw)
In-Reply-To: <YhOvYR463nBTfQFM@stefanha-x1.localdomain>



> On Feb 21, 2022, at 10:27 AM, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> 
> On Thu, Feb 17, 2022 at 02:48:50AM -0500, Jagannathan Raman wrote:
>> Add blocker to prevent hot-unplug of devices
>> 
>> Signed-off-by: Elena Ufimtseva <elena.ufimtseva@oracle.com>
>> Signed-off-by: John G Johnson <john.g.johnson@oracle.com>
>> Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
>> ---
>> include/hw/qdev-core.h | 35 +++++++++++++++++++++++++++++++++++
>> softmmu/qdev-monitor.c | 26 ++++++++++++++++++++++++++
>> 2 files changed, 61 insertions(+)
>> 
>> diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
>> index 92c3d65208..4b1d77f44a 100644
>> --- a/include/hw/qdev-core.h
>> +++ b/include/hw/qdev-core.h
>> @@ -193,6 +193,7 @@ struct DeviceState {
>>     int instance_id_alias;
>>     int alias_required_for_version;
>>     ResettableState reset;
>> +    GSList *unplug_blockers;
>> };
>> 
>> struct DeviceListener {
>> @@ -419,6 +420,40 @@ void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
>> void qdev_machine_creation_done(void);
>> bool qdev_machine_modified(void);
>> 
>> +/**
>> + * Device Unplug blocker: prevents a device from being unplugged. It could
>      ^^^^^^^^^^^^^^^^^^^^^
> 
> This looks strange. gtkdoc will probably treat it as the doc comment for
> qdev_add_unplug_blocker(), which is actually defined below. I suggest
> not trying to define a new section in the documentation and instead just
> focussing on doc comments for qdev_add_unplug_block() and other
> functions.

Sorry I assumed that we needed an extra ‘*’ at the beginning of the
comment. I got this idea when checking out block.c and blockdev.c
while working on the migration patch.

I’ll follow the “Comment style” section in “docs/devel/style.rst"

> 
> The gtkdoc way of defining sections is covered here but it's almost
> never used in QEMU:
> https://developer-old.gnome.org/gtk-doc-manual/stable/documenting_sections.html.en
> 
>> + * be used to indicate that another object depends on the device.
>> + *
>> + * qdev_add_unplug_blocker: Adds an unplug blocker to a device
>> + *
>> + * @dev: Device to be blocked from unplug
>> + * @reason: Reason for blocking
>> + *
>> + */
>> +void qdev_add_unplug_blocker(DeviceState *dev, Error *reason);
> 
> Does the caller have to call qdev_del_unplug_blocker() later?
> 
> An assert(!dev->unplug_blockers) would be nice when DeviceState is
> destroyed. That way leaks will be caught.

Makes sense, will add.

> 
>> +
>> +/**
>> + * qdev_del_unplug_blocker: Removes an unplug blocker from a device
>> + *
>> + * @dev: Device to be unblocked
>> + * @reason: Pointer to the Error used with qdev_add_unplug_blocker.
>> + *          Used as a handle to lookup the blocker for deletion.
>> + *
>> + */
>> +void qdev_del_unplug_blocker(DeviceState *dev, Error *reason);
>> +
>> +/**
>> + * qdev_unplug_blocked: Confirms if a device is blocked from unplug
>> + *
>> + * @dev: Device to be tested
>> + * @reason: Returns one of the reasons why the device is blocked,
>> + *          if any
>> + *
>> + * Returns: true if device is blocked from unplug, false otherwise
>> + *
>> + */
>> +bool qdev_unplug_blocked(DeviceState *dev, Error **errp);
>> +
>> /**
>>  * GpioPolarity: Polarity of a GPIO line
>>  *
>> diff --git a/softmmu/qdev-monitor.c b/softmmu/qdev-monitor.c
>> index 01f3834db5..69d9cf3f25 100644
>> --- a/softmmu/qdev-monitor.c
>> +++ b/softmmu/qdev-monitor.c
>> @@ -945,10 +945,36 @@ void qmp_device_del(const char *id, Error **errp)
>>             return;
>>         }
>> 
>> +        if (qdev_unplug_blocked(dev, errp)) {
>> +            return;
>> +        }
>> +
>>         qdev_unplug(dev, errp);
>>     }
>> }
>> 
>> +void qdev_add_unplug_blocker(DeviceState *dev, Error *reason)
> 
> These functions belong in hw/core/qdev.c because they are part of the
> DeviceState API, not qdev monitor commands?

Both hw/core/qdev.c and softmmu/qdev-monitor.c seem to manage the
DeviceState.

softmmu/qdev-monitor.c seems to manage device addition and
removal using qdev_device_add() and qdev_unplug(). I noticed
that some functions in this file change DeviceState. For example,
qdev_device_add() sets DeviceState->opts, qdev_set_id() sets
DeviceState->id. Given the above two reasons, I thought it the
unplug blockers could be better place here.

Since hw/core/qdev.c makes the majority of changes to the
DeviceState, moving the unplug blockers over there makes
sense to me.

Thank you!
--
Jag

> 
>> +{
>> +    dev->unplug_blockers = g_slist_prepend(dev->unplug_blockers, reason);
>> +}
>> +
>> +void qdev_del_unplug_blocker(DeviceState *dev, Error *reason)
>> +{
>> +    dev->unplug_blockers = g_slist_remove(dev->unplug_blockers, reason);
>> +}
>> +
>> +bool qdev_unplug_blocked(DeviceState *dev, Error **errp)
>> +{
>> +    ERRP_GUARD();
>> +
>> +    if (dev->unplug_blockers) {
>> +        error_propagate(errp, error_copy(dev->unplug_blockers->data));
>> +        return true;
>> +    }
>> +
>> +    return false;
>> +}
>> +
>> void hmp_device_add(Monitor *mon, const QDict *qdict)
>> {
>>     Error *err = NULL;
>> -- 
>> 2.20.1
>> 


  reply	other threads:[~2022-02-28 16:24 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17  7:48 [PATCH v6 00/19] vfio-user server in QEMU Jagannathan Raman
2022-02-17  7:48 ` [PATCH v6 01/19] configure, meson: override C compiler for cmake Jagannathan Raman
2022-02-17 12:09   ` Peter Maydell
2022-02-17 15:49     ` Jag Raman
2022-02-18  3:40     ` Jag Raman
2022-02-18 12:13       ` Paolo Bonzini
2022-02-18 14:49         ` Jag Raman
2022-02-18 15:16           ` Jag Raman
2022-02-20  8:27           ` Paolo Bonzini
2022-02-20 13:27             ` Paolo Bonzini
2022-02-22 19:05             ` Jag Raman
2022-02-24 17:52               ` Paolo Bonzini
2022-02-25  4:03                 ` Jag Raman
2022-02-28 18:12                   ` Paolo Bonzini
2022-02-28 19:55                     ` Jag Raman
2022-02-17  7:48 ` [PATCH v6 02/19] tests/avocado: Specify target VM argument to helper routines Jagannathan Raman
2022-02-17  7:48 ` [PATCH v6 03/19] qdev: unplug blocker for devices Jagannathan Raman
2022-02-21 15:27   ` Stefan Hajnoczi
2022-02-28 16:23     ` Jag Raman [this message]
2022-02-21 15:30   ` Stefan Hajnoczi
2022-02-28 19:11     ` Jag Raman
2022-02-17  7:48 ` [PATCH v6 04/19] remote/machine: add HotplugHandler for remote machine Jagannathan Raman
2022-02-21 15:30   ` Stefan Hajnoczi
2022-02-17  7:48 ` [PATCH v6 05/19] remote/machine: add vfio-user property Jagannathan Raman
2022-02-21 15:32   ` Stefan Hajnoczi
2022-02-17  7:48 ` [PATCH v6 06/19] vfio-user: build library Jagannathan Raman
2022-02-17  7:48 ` [PATCH v6 07/19] vfio-user: define vfio-user-server object Jagannathan Raman
2022-02-21 15:37   ` Stefan Hajnoczi
2022-02-28 19:14     ` Jag Raman
2022-03-02 16:45       ` Stefan Hajnoczi
2022-02-25 15:42   ` Eric Blake
2022-02-17  7:48 ` [PATCH v6 08/19] vfio-user: instantiate vfio-user context Jagannathan Raman
2022-02-21 15:42   ` Stefan Hajnoczi
2022-02-28 19:16     ` Jag Raman
2022-02-17  7:48 ` [PATCH v6 09/19] vfio-user: find and init PCI device Jagannathan Raman
2022-02-21 15:57   ` Stefan Hajnoczi
2022-02-28 19:17     ` Jag Raman
2022-02-17  7:48 ` [PATCH v6 10/19] vfio-user: run vfio-user context Jagannathan Raman
2022-02-22 10:13   ` Stefan Hajnoczi
2022-02-25 16:06   ` Eric Blake
2022-02-28 19:22     ` Jag Raman
2022-02-17  7:48 ` [PATCH v6 11/19] vfio-user: handle PCI config space accesses Jagannathan Raman
2022-02-22 11:09   ` Stefan Hajnoczi
2022-02-28 19:23     ` Jag Raman
2022-02-17  7:48 ` [PATCH v6 12/19] vfio-user: IOMMU support for remote device Jagannathan Raman
2022-02-22 10:40   ` Stefan Hajnoczi
2022-02-28 19:54     ` Jag Raman
2022-03-02 16:49       ` Stefan Hajnoczi
2022-03-03 14:49         ` Jag Raman
2022-03-07  9:45           ` Stefan Hajnoczi
2022-03-07 14:42             ` Jag Raman
2022-03-08 10:04               ` Stefan Hajnoczi
2022-02-17  7:49 ` [PATCH v6 13/19] vfio-user: handle DMA mappings Jagannathan Raman
2022-02-17  7:49 ` [PATCH v6 14/19] vfio-user: handle PCI BAR accesses Jagannathan Raman
2022-02-22 11:04   ` Stefan Hajnoczi
2022-02-17  7:49 ` [PATCH v6 15/19] vfio-user: handle device interrupts Jagannathan Raman
2022-03-07 10:24   ` Stefan Hajnoczi
2022-03-07 15:10     ` Jag Raman
2022-03-08 10:15       ` Stefan Hajnoczi
2022-03-26 23:47     ` Jag Raman
2022-03-29 14:24       ` Stefan Hajnoczi
2022-03-29 19:06         ` Jag Raman
2022-03-30  9:40           ` Thanos Makatos
2022-04-04  9:44             ` Stefan Hajnoczi
2022-02-17  7:49 ` [PATCH v6 16/19] softmmu/vl: defer backend init Jagannathan Raman
2022-03-07 10:48   ` Stefan Hajnoczi
2022-03-07 15:31     ` Jag Raman
2022-02-17  7:49 ` [PATCH v6 17/19] vfio-user: register handlers to facilitate migration Jagannathan Raman
2022-02-18 12:20   ` Paolo Bonzini
2022-02-18 14:55     ` Jag Raman
2022-03-07 11:26   ` Stefan Hajnoczi
2022-02-17  7:49 ` [PATCH v6 18/19] vfio-user: handle reset of remote device Jagannathan Raman
2022-03-07 11:36   ` Stefan Hajnoczi
2022-03-07 15:37     ` Jag Raman
2022-03-08 10:21       ` Stefan Hajnoczi
2022-02-17  7:49 ` [PATCH v6 19/19] vfio-user: avocado tests for vfio-user Jagannathan Raman

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=F110D666-049A-4F82-A5AB-044BD61843CC@oracle.com \
    --to=jag.raman@oracle.com \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=bleal@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=elena.ufimtseva@oracle.com \
    --cc=f4bug@amsat.org \
    --cc=john.g.johnson@oracle.com \
    --cc=john.levon@nutanix.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=thanos.makatos@nutanix.com \
    /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.