qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	marcel.a@redhat.com, qemu-devel <qemu-devel@nongnu.org>,
	"Blue Swirl" <blauwirbel@gmail.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Anthony Liguori" <anthony@codemonkey.ws>,
	dkoch@verizon.co, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH 00/11 v3] Refactor PCI/SHPC/PCIE hotplug to use a more generic hotplug API
Date: Wed, 18 Dec 2013 16:59:02 +0100	[thread overview]
Message-ID: <52B1C646.70000@redhat.com> (raw)
In-Reply-To: <20131218164809.7b4ddb07@nial.usersys.redhat.com>

Il 18/12/2013 16:48, Igor Mammedov ha scritto:
>> Hotplugging a device is a special case of plugging a device.  If a bus
>> or device only supports cold-plug, that can be done using
>> "bc->allow_hotplug = false" or "dc->hotpluggable = false".
> Do we need per instance ability to set "hotpluggable" property?
> For example board might want to mark some CPUs as not hotpluggable.

I think such fine-grained control could be handled from dc->unplug.
Let's not do anything more than we need, until we need it.

Right now, all we need to model is the fact that a device X can act as
hotplug controller for multiple buses, X is not the parent of those
buses, and we need to tell those buses about X.  This is hotplug-handler
in BusState.

We also like to distinguish devices that only support -device (or are
even only board-instantiatable) from devices that support device_add.
This is dc->hotpluggable.  It is not absolutely necessary, but it makes
sense if "plugging" gets a more central place in qdev.  This is the case
after you add hotplug-handler.

>>> Interfaces would be another option too.
>>
>> Interfaces are fine, but the question is who finds them and calls them.
>> In this case, the discovery mechanism is a link property, and the
>> calling mechanism is an explicit hook in the "realized" property.
>
> If we don't need per instance "hotpluggable" state and we can call
> interfaces from generic qdev/device code, then we would need at first
> only TYPE_HOTPLUGGABLE_BUS_DEVICE_IF and later for link<> based hotplug
> we could add just TYPE_HOTPLUGGABLE_DEVICE_IF. Difference would be in
> the way they get access to hotplug device link, former one will use bus
> for it and second some other way.

I think this is overengineered.  What you have is flexible and decently
clean.  I don't think there's any need to go from the device to the bus
and from there optionally to the handler.  Most of the time you couldn't
do anything really in the bus, you would have to call some sort of
bus-specific callback (like SCSIBusInfo).  It is then equivalent to set
the bus's parent device as a (hot)plug handler and go straight from the
device to the handler, as in your patches.

Paolo

  reply	other threads:[~2013-12-18 15:59 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-13 12:44 [Qemu-devel] [PATCH 00/11 v3] Refactor PCI/SHPC/PCIE hotplug to use a more generic hotplug API Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 01/11] qom: do not register interface "types" in the type table Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 02/11] qom: detect bad reentrance during object_class_foreach Igor Mammedov
2013-12-14  6:53   ` Peter Crosthwaite
2013-12-15 17:44     ` Andreas Färber
2013-12-13 12:44 ` [Qemu-devel] [PATCH 03/11] define hotplug interface Igor Mammedov
2013-12-14  7:03   ` Peter Crosthwaite
2013-12-16 15:37     ` Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 04/11] qdev: add to BusState "hotplug-handler" link Igor Mammedov
2013-12-14  7:05   ` Peter Crosthwaite
2013-12-16 15:26     ` Igor Mammedov
2013-12-16 15:53       ` Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 05/11] qdev: add "hotpluggable" property to Device Igor Mammedov
2013-12-14  7:10   ` Peter Crosthwaite
2013-12-16 15:37     ` Igor Mammedov
2013-12-16 23:22   ` Anthony Liguori
2013-12-13 12:44 ` [Qemu-devel] [PATCH 06/11] hw/acpi: move typeinfo to the file end Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 07/11] qdev:pci: refactor PCIDevice to use generic "hotpluggable" property Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 08/11] acpi/piix4pm: convert ACPI PCI hotplug to use hotplug-handler API Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 09/11] pci/shpc: convert SHPC " Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 10/11] pci/pcie: convert PCIE " Igor Mammedov
2013-12-13 12:44 ` [Qemu-devel] [PATCH 11/11] hw/pci: switch to a generic hotplug handling for PCIDevice Igor Mammedov
2013-12-16 23:26 ` [Qemu-devel] [PATCH 00/11 v3] Refactor PCI/SHPC/PCIE hotplug to use a more generic hotplug API Anthony Liguori
2013-12-16 23:34   ` Peter Crosthwaite
2013-12-17 11:58   ` Igor Mammedov
2013-12-17 12:38   ` Paolo Bonzini
2013-12-17 19:38     ` Anthony Liguori
2013-12-18 10:36       ` Paolo Bonzini
2013-12-18 15:48         ` Igor Mammedov
2013-12-18 15:59           ` Paolo Bonzini [this message]
2013-12-18 16:32             ` Igor Mammedov
2013-12-18 16:26           ` Michael S. Tsirkin
2013-12-18 16:34             ` Igor Mammedov

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=52B1C646.70000@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=afaerber@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=blauwirbel@gmail.com \
    --cc=dkoch@verizon.co \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=mst@redhat.com \
    --cc=peter.crosthwaite@xilinx.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 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).