All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Eduardo Habkost <ehabkost@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	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 04/14] pc: prepare for multi stage hotplug handlers
Date: Fri, 8 Jun 2018 14:24:42 +0200	[thread overview]
Message-ID: <20180608142442.0d97b7c6@redhat.com> (raw)
In-Reply-To: <5dda6237-88d8-f0f8-58d2-af996368cea4@redhat.com>

On Thu, 7 Jun 2018 16:00:54 +0200
David Hildenbrand <david@redhat.com> wrote:

> On 07.06.2018 15:44, Igor Mammedov wrote:
> > On Mon, 4 Jun 2018 13:27:01 +0200
> > David Hildenbrand <david@redhat.com> wrote:
> >   
> >> On 31.05.2018 16:13, Igor Mammedov wrote:  
> >>> On Wed, 30 May 2018 16:13:32 +0200
> >>> David Hildenbrand <david@redhat.com> wrote:
> >>>     
> >>>> On 30.05.2018 15:08, Igor Mammedov wrote:    
> >>>>> On Thu, 17 May 2018 10:15:17 +0200
> >>>>> David Hildenbrand <david@redhat.com> 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).      
> >>>>> I'd split out introducing local error into separate patch
> >>>>> so patch would do a single thing.    
> >>
> >> I can do that if it makes review easier.
> >>  
> >>>>>       
> >>>>>> Also, add code to pass control to the final stage hotplug handler at the
> >>>>>> parent bus.      
> >>>>> But I don't agree with generic
> >>>>>  "} else if ("dev->parent_bus && dev->parent_bus->hotplug_handler) {"
> >>>>> forwarding, it's done by 3/14 for generic case and in case of
> >>>>> special device that needs bus handler called from machine one,
> >>>>> I'd suggest to do forwarding explicitly for that device only
> >>>>> like we do with acpi_dev.      
> >>>>
> >>>> I decided to do it that way because it is generic and results in nicer
> >>>> recovery handling (e.g. in case pc_dimm plug fails, we can simply
> >>>> rollback all (for now MemoryDevice) previous plug operations).    
> >>> rollback should be managed by the caller of pc_dimm plug
> >>> directly, so it's not relevant here.
> >>>     
> >>>> IMHO, the resulting code is easier to read.
> >>>>
> >>>> From this handling it is clear that
> >>>> "if we reach the hotplug handler, and it is not some special device
> >>>> plugged by the machine (CPU, PC_DIMM), pass it on to the actual hotplug
> >>>> handler if any exists"    
> >>> I strongly disagree with that it's easier to deal with.
> >>> You are basically duplicating already generalized code
> >>> from qdev_get_hotplug_handler() back into boards.
> >>>
> >>> If a device doesn't have to be handled by machine handler,
> >>> than qdev_get_hotplug_handler() must return its bus handler
> >>> if any directly. So branch in question that your are copying
> >>> is a dead one, pls drop it.    
> >>
> >> We forward selected (pc_get_hotpug_handler()) devices to the
> >> right hotplug handler. Nothing wrong about that. I don't agree
> >> with "basically duplicating already generalized code" wrong.
> >> We have to forward at some place. Your idea simply places that
> >> code at some other place.
> >>
> >>
> >> But I think we have to get the general idea sorted out first.
> >>
> >> What you have in mind (e.g. plug):
> >>
> >> if (TYPE_MEMORY_DEVICE) {
> >> 	memory_device_plug();
> >> 	if (local_err) {
> >> 		goto out;
> >> 	}
> >>
> >> 	if (TYPE_PC_DIMM) {
> >> 		pc_dimm_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);
> >> 	}
> >> 	if (local_err) {
> >> 		memory_device_unplug()
> >> 		goto out;
> >> 	}
> >> } else if (TYPE_CPU)
> >> ...
> >>
> >>
> >> What I have in mind (and implemented in this series):
> >>
> >>
> >> if (TYPE_MEMORY_DEVICE) {
> >> 	memory_device_plug();
> >> }
> >> /* possibly other interfaces */
> >> if (local_err) {
> >> 	error_handling();
> >> 	return;
> >> }
> >>
> >> if (TYPE_PC_DIMM) {
> >> 	pc_dimm_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);
> >> }  
> > I don't like this implicit wiring, where reader of this part of code
> > has no idea that TYPE_MEMORY_DEVICE might be also bus device that needs
> > request forwarding.
> > I'd prefer [pre/un]plug handlers be concrete and explicit spaghetti code,
> > something like this:
> > 
> > if (TYPE_PC_DIMM) {
> >     pc_dimm_plug()
> >     /* do here additional concrete machine specific things */
> > } else if (TYPE_VIRTIO_MEM) {
> >     virtio_mem_plug() <- do forwarding in there
> >     /* and do here additional concrete machine specific things */
> > } else if (TYPE_CPU) {
> >     cpu_plug()
> >     /* do here additional concrete machine specific things */
> > }  
> 
> That will result in a lot of duplicate code - for every machine we
> support (dimm/virtio-mem/virtio-pmem/*add more memory devices here*) -
> virtio-mem and virtio-pmem could most probably share the code.
maybe or maybe not, depending on if pmem endups as memory device or
separate controller. And even with duplication, machine code would
be easy to follow just down one explicit call chain.

> 
> >   
> >> if (local_err) {
> >> 	if (object_dynamic_cast(OBJECT(dev), TYPE_MEMORY_DEVICE)) {
> >> 		memory_device_unplug()
> >> 	}
> >> 	/* possibly other interfaces */
> >> }
> >> ...
> >>
> >>
> >> I claim that my variant is more generic because:
> >> - it easily supports multiple interfaces (like MemoryDevice)
> >>   per Device that need a hotplug handler call
> >> - there is only one call to hotplug_handler_plug() in case we
> >>   add similar handling for another device  
> > As someone said "one more layer of indirection would solve problem".
> > But then one would have a clue how it works after a while (including
> > author of the feature).
> > I don't think we have a problem here and need generalization.
> >   
> >>
> >> Apart from that they do exactly the same thing.
> >>  
> >   
> 
> 

  reply	other threads:[~2018-06-08 12:24 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 [this message]
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
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=20180608142442.0d97b7c6@redhat.com \
    --to=imammedo@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=david@redhat.com \
    --cc=ehabkost@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.