From: David Hildenbrand <david@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>,
Eduardo Habkost <ehabkost@redhat.com>,
Eric Blake <eblake@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Pankaj Gupta <pagupta@redhat.com>,
Luiz Capitulino <lcapitul@redhat.com>,
Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler
Date: Wed, 3 Oct 2018 19:21:25 +0200 [thread overview]
Message-ID: <cb8dd5d6-bb8c-f4a1-85c3-6b7ba53ad828@redhat.com> (raw)
In-Reply-To: <20181003062949.GZ1886@umbus.fritz.box>
On 03/10/2018 08:29, David Gibson wrote:
> On Wed, Sep 26, 2018 at 11:42:13AM +0200, David Hildenbrand wrote:
>> The unplug and unplug_request handlers are special: They are not
>> executed when unrealizing a device, but rather trigger the removal of a
>> device from device_del() via object_unparent() - to effectively
>> unrealize a device.
>>
>> If such a device has a child bus and another device attached to
>> that bus (e.g. how virtio devices are created with their proxy device),
>> we will not get a call to the unplug handler. As we want to support
>> hotplug handlers (and especially also some unplug logic to undo resource
>> assignment) for such devices, we cannot simply call the unplug handler
>> when unrealizing - it has a different semantic ("trigger removal").
>>
>> To handle this scenario, we need a do_unplug handler, that will be
>> executed for all devices with a hotplug handler.
>>
>> While at it, introduce hotplug_fn_nofail and fix a spelling mistake in
>> a comment.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>> hw/core/hotplug.c | 10 ++++++++++
>> hw/core/qdev.c | 6 ++++++
>> include/hw/hotplug.h | 26 ++++++++++++++++++++++++--
>> 3 files changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/core/hotplug.c b/hw/core/hotplug.c
>> index 2253072d0e..e7a68d5160 100644
>> --- a/hw/core/hotplug.c
>> +++ b/hw/core/hotplug.c
>> @@ -45,6 +45,16 @@ void hotplug_handler_post_plug(HotplugHandler *plug_handler,
>> }
>> }
>>
>> +void hotplug_handler_do_unplug(HotplugHandler *plug_handler,
>> + DeviceState *plugged_dev)
>
> Hrm. I really dislike things named "do_X". The "do" rarely adds any
> useful meaning. And when there's also something called just plain
> "X", it's *always* unclear how they relate to each other.
>
> That's doubly true when it's a general interface like this, rather
> than just some local functions.
>
Yes, the naming is not the best, but I didn't want to rename all unplug
handlers before we have an agreement on how to proceed. My concept would
be that
1. unplug() is renamed to trigger_unplug(). unplug_request() remains.
2. do_unplug() is renamed to pre_unplug() (just like pre_plug())
3. we might have in addition unplug() after realize(false) - just like
plug()
trigger_unplug() would perform checks and result in object_unparent().
>From there, all cleanup/unplugging would be performed via the unrealize
chain, just like we have for realize() now. That would allow to properly
unplug complete device hierarchies.
But Igor rather wants one hotplug handler chain, and no dedicated
hotplug handlers for other devices in the device hierarchy. As long as
there are no other opinions I guess I will have to go into the direction
Igor proposes to get virtio-pmem and friends upstream.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2018-10-03 17:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180926094219.20322-1-david@redhat.com>
[not found] ` <20180926094219.20322-9-david@redhat.com>
[not found] ` <df729c85-6fa1-93d7-c91e-7d3738fbf38f@redhat.com>
2018-10-01 8:13 ` [Qemu-devel] [PATCH v4 08/24] memory-device: document MemoryDeviceClass David Hildenbrand
2018-10-01 10:40 ` Auger Eric
[not found] ` <20180926094219.20322-15-david@redhat.com>
[not found] ` <99ab8baf-37c9-2df1-7292-8e0ac4f31137@redhat.com>
2018-10-01 8:15 ` [Qemu-devel] [PATCH v4 14/24] memory-device: complete factoring out plug handling David Hildenbrand
2018-10-01 8:18 ` David Hildenbrand
2018-10-01 9:01 ` Igor Mammedov
[not found] ` <20180926094219.20322-17-david@redhat.com>
[not found] ` <2c164355-1592-a785-b761-463f00dee259@redhat.com>
2018-10-01 8:21 ` [Qemu-devel] [PATCH v4 16/24] memory-device: trace when pre_assigning/assigning/unassigning addresses David Hildenbrand
[not found] ` <20180926094219.20322-18-david@redhat.com>
[not found] ` <9be6d517-615d-34ef-f6f4-4d478ef21944@redhat.com>
2018-10-01 8:36 ` [Qemu-devel] [PATCH v4 17/24] memory-device: add class function get_device_id() David Hildenbrand
[not found] ` <20180926094219.20322-20-david@redhat.com>
2018-10-01 13:37 ` [Qemu-devel] [PATCH v4 19/24] virtio-pmem: prototype Igor Mammedov
[not found] ` <20180926094219.20322-22-david@redhat.com>
2018-10-01 18:57 ` [Qemu-devel] [PATCH v4 21/24] hmp: handle virtio-pmem when printing memory device infos Dr. David Alan Gilbert
[not found] ` <20180926094219.20322-23-david@redhat.com>
2018-10-01 18:59 ` [Qemu-devel] [PATCH v4 22/24] numa: handle virtio-pmem in NUMA stats Dr. David Alan Gilbert
[not found] ` <20180926094219.20322-19-david@redhat.com>
[not found] ` <20180927150141.60a6488a@redhat.com>
[not found] ` <dc5d7b2d-5b51-2c0b-aac7-ebf04a4e7859@redhat.com>
2018-10-01 13:24 ` [Qemu-devel] [PATCH v4 18/24] qdev: hotplug: provide do_unplug handler Igor Mammedov
2018-10-02 9:49 ` David Hildenbrand
2018-10-02 14:23 ` Igor Mammedov
2018-10-02 15:36 ` David Hildenbrand
2018-10-08 11:47 ` David Hildenbrand
2018-10-08 12:19 ` Igor Mammedov
2018-10-08 12:41 ` David Hildenbrand
2018-10-08 14:12 ` Igor Mammedov
2018-10-11 8:50 ` David Hildenbrand
2018-10-12 8:27 ` Igor Mammedov
2018-10-12 8:45 ` David Hildenbrand
2018-10-12 14:21 ` Igor Mammedov
2018-10-15 7:21 ` David Hildenbrand
2018-10-03 6:29 ` David Gibson
2018-10-03 17:21 ` David Hildenbrand [this message]
2018-10-04 15:59 ` Igor Mammedov
2018-10-05 7:40 ` David Hildenbrand
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=cb8dd5d6-bb8c-f4a1-85c3-6b7ba53ad828@redhat.com \
--to=david@redhat.com \
--cc=agraf@suse.de \
--cc=armbru@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=dgilbert@redhat.com \
--cc=eblake@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=lcapitul@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=pagupta@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=rth@twiddle.net \
--cc=xiaoguangrong.eric@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).