All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-ppc@nongnu.org, Pankaj Gupta <pagupta@redhat.com>,
	Alexander Graf <agraf@suse.de>, Cornelia Huck <cohuck@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v4 06/14] spapr: prepare for multi stage hotplug handlers
Date: Tue, 5 Jun 2018 09:51:26 +0200	[thread overview]
Message-ID: <fbd2d738-7356-e991-7c15-f9cc436a9378@redhat.com> (raw)
In-Reply-To: <20180605010840.GF5140@umbus.fritz.box>

On 05.06.2018 03:08, David Gibson wrote:
> On Thu, May 17, 2018 at 10:15:19AM +0200, David Hildenbrand wrote:
>> For multi stage hotplug handlers, we'll have to do some error handling
>> in some hotplug functions, so let's use a local error variable (except
>> for unplug requests).
>>
>> Also, add code to pass control to the final stage hotplug handler at the
>> parent bus.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>>  hw/ppc/spapr.c | 54 +++++++++++++++++++++++++++++++++++++++++++-----------
>>  1 file changed, 43 insertions(+), 11 deletions(-)
>>
>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>> index ebf30dd60b..b7c5c95f7a 100644
>> --- a/hw/ppc/spapr.c
>> +++ b/hw/ppc/spapr.c
>> @@ -3571,27 +3571,48 @@ static void spapr_machine_device_plug(HotplugHandler *hotplug_dev,
>>  {
>>      MachineState *ms = MACHINE(hotplug_dev);
>>      sPAPRMachineClass *smc = SPAPR_MACHINE_GET_CLASS(ms);
>> +    Error *local_err = NULL;
>>  
>> +    /* final stage hotplug handler */
>>      if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
>>          int node;
>>  
>>          if (!smc->dr_lmb_enabled) {
>> -            error_setg(errp, "Memory hotplug not supported for this machine");
>> -            return;
>> +            error_setg(&local_err,
>> +                       "Memory hotplug not supported for this machine");
>> +            goto out;
>>          }
>> -        node = object_property_get_uint(OBJECT(dev), PC_DIMM_NODE_PROP, errp);
>> -        if (*errp) {
>> -            return;
>> +        node = object_property_get_uint(OBJECT(dev), PC_DIMM_NODE_PROP,
>> +                                        &local_err);
>> +        if (local_err) {
>> +            goto out;
>>          }
>>          if (node < 0 || node >= MAX_NODES) {
>> -            error_setg(errp, "Invaild node %d", node);
>> -            return;
>> +            error_setg(&local_err, "Invaild node %d", node);
>> +            goto out;
>>          }
>>  
>> -        spapr_memory_plug(hotplug_dev, dev, node, errp);
>> +        spapr_memory_plug(hotplug_dev, dev, node, &local_err);
>>      } else if (object_dynamic_cast(OBJECT(dev), TYPE_SPAPR_CPU_CORE)) {
>> -        spapr_core_plug(hotplug_dev, dev, errp);
>> +        spapr_core_plug(hotplug_dev, dev, &local_err);
>> +    } else if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
>> +        hotplug_handler_plug(dev->parent_bus->hotplug_handler, dev, &local_err);
>> +    }
>> +out:
>> +    error_propagate(errp, local_err);
>> +}
>> +
>> +static void spapr_machine_device_unplug(HotplugHandler *hotplug_dev,
>> +                                        DeviceState *dev, Error **errp)
>> +{
>> +    Error *local_err = NULL;
>> +
>> +    /* final stage hotplug handler */
>> +    if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
> 
> As I think Igor said on the equivalent PC patch, I don't quite get
> this.  Isn't this already handled by the generic hotplug code picking
> up the bus's hotplug handler if the machine doesn't supply one?

See my reply to patch nr 4.

What we do is, we install the machine hotplug handler as an
"intermediate" hotplug handler.

E.g. if we have a VIRTIO based MemoryDevice, we have to initialize the
MemoryDevice specific stuff in the machine hotplug handler, but then
pass the device onto the last stage hotplug handler (which will
eventually attach it to a bus and notify the guest).

For PC_DIMM, the machine hotplug handler is already the last stage
hotplug handler. Everything is fine. If it is not a PC_DIMM, we have to
pass it on to the right last stage hotplug handler (e.g. using the bus).

So the generic hotplug code will alway pick up the machine hotplug
handler for MemoryDevices first, do the MemoryDevice specific stuff and
then pass on control to the "actual" hotplug handler.

Please note that this handling only applies to device types we "route"
through the machine hotplug handler, what we will initially only do for
MemoryDevices.

Just like for PC, I factored out the introduction of the local error
variable and will add a better description to the patch descriptions on
how this plays together.

-- 

Thanks,

David / dhildenb

  reply	other threads:[~2018-06-05  7:51 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17  8:15 [Qemu-devel] [PATCH v4 00/14] MemoryDevice: use multi stage hotplug handlers David Hildenbrand
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 01/14] memory-device: drop assert related to align and start of address space David Hildenbrand
2018-05-29 13:27   ` Igor Mammedov
2018-05-29 16:02     ` David Hildenbrand
2018-05-30 12:57       ` Igor Mammedov
2018-05-30 14:06         ` David Hildenbrand
2018-05-31 13:54           ` Igor Mammedov
2018-06-04 10:53             ` David Hildenbrand
2018-06-07 13:26               ` Igor Mammedov
2018-06-07 14:12                 ` David Hildenbrand
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 02/14] memory-device: introduce separate config option David Hildenbrand
2018-05-30 12:58   ` Igor Mammedov
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 03/14] qdev: let machine hotplug handler to override bus hotplug handler David Hildenbrand
2018-06-05  1:02   ` David Gibson
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 04/14] pc: prepare for multi stage hotplug handlers David Hildenbrand
2018-05-30 13:08   ` Igor Mammedov
2018-05-30 14:13     ` David Hildenbrand
2018-05-31 14:13       ` Igor Mammedov
2018-06-04 11:27         ` David Hildenbrand
2018-06-07 13:44           ` Igor Mammedov
2018-06-07 14:00             ` David Hildenbrand
2018-06-08 12:24               ` Igor Mammedov
2018-06-08 12:32                 ` David Hildenbrand
2018-06-08 12:55                   ` Michael S. Tsirkin
2018-06-08 13:07                     ` David Hildenbrand
2018-06-08 15:12                       ` Michael S. Tsirkin
2018-06-13 10:58                         ` David Hildenbrand
2018-06-13 15:48                           ` Igor Mammedov
2018-06-13 15:51                             ` David Hildenbrand
2018-06-13 18:32                               ` Michael S. Tsirkin
2018-06-13 19:37                                 ` David Hildenbrand
2018-06-13 22:05                                   ` Michael S. Tsirkin
2018-06-14  6:14                                     ` David Hildenbrand
2018-06-14  9:16                                       ` Igor Mammedov
2018-06-14  9:20                               ` Igor Mammedov
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 05/14] pc: route all memory devices through the machine hotplug handler David Hildenbrand
2018-05-30 13:12   ` Igor Mammedov
2018-05-30 14:08     ` David Hildenbrand
2018-05-30 14:27       ` Paolo Bonzini
2018-05-30 14:31         ` David Hildenbrand
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 06/14] spapr: prepare for multi stage hotplug handlers David Hildenbrand
2018-05-17 12:43   ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2018-06-01 10:33   ` [Qemu-devel] " Igor Mammedov
2018-06-05  1:08   ` David Gibson
2018-06-05  7:51     ` David Hildenbrand [this message]
2018-06-07 14:26       ` Igor Mammedov
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 07/14] spapr: route all memory devices through the machine hotplug handler David Hildenbrand
2018-06-05  1:09   ` David Gibson
2018-06-05  7:51     ` David Hildenbrand
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 08/14] spapr: handle pc-dimm unplug via hotplug handler chain David Hildenbrand
2018-06-01 10:53   ` Igor Mammedov
2018-06-05  1:12   ` David Gibson
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 09/14] spapr: handle cpu core " David Hildenbrand
2018-06-01 10:57   ` Igor Mammedov
2018-06-05  1:13   ` David Gibson
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 10/14] memory-device: new functions to handle plug/unplug David Hildenbrand
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 11/14] pc-dimm: implement new memory device functions David Hildenbrand
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 12/14] memory-device: factor out pre-plug into hotplug handler David Hildenbrand
2018-06-01 11:17   ` Igor Mammedov
2018-06-04 11:45     ` David Hildenbrand
2018-06-07 15:00       ` Igor Mammedov
2018-06-07 15:10         ` David Hildenbrand
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 13/14] memory-device: factor out unplug " David Hildenbrand
2018-06-01 11:31   ` Igor Mammedov
2018-06-04 15:54     ` David Hildenbrand
2018-05-17  8:15 ` [Qemu-devel] [PATCH v4 14/14] memory-device: factor out plug " David Hildenbrand
2018-06-01 11:39   ` Igor Mammedov
2018-06-04 11:47     ` David Hildenbrand
2018-06-07 10:44       ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2018-05-25 12:43 ` [Qemu-devel] [qemu-s390x] [PATCH v4 00/14] MemoryDevice: use multi stage hotplug handlers David Hildenbrand
2018-05-30 14:03   ` Paolo Bonzini
2018-05-31 11:47     ` Igor Mammedov
2018-05-31 11:50       ` Paolo Bonzini
2018-06-01 12:13   ` Igor Mammedov
2018-06-04 10:03     ` David Hildenbrand
2018-06-08  9:57     ` 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=fbd2d738-7356-e991-7c15-f9cc436a9378@redhat.com \
    --to=david@redhat.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    /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.