From: Paolo Bonzini <pbonzini@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: peter.maydell@linaro.org, ehabkost@redhat.com, mst@redhat.com,
marcel.a@redhat.com, qemu-devel@nongnu.org, blauwirbel@gmail.com,
alex.williamson@redhat.com, anthony@codemonkey.ws,
afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH 7/7] hw/pci: convert PCI bus to use "hotplug-device" interface.
Date: Mon, 09 Dec 2013 16:16:57 +0100 [thread overview]
Message-ID: <52A5DEE9.9030901@redhat.com> (raw)
In-Reply-To: <20131209160834.59bfdc98@nial.usersys.redhat.com>
Il 09/12/2013 16:08, Igor Mammedov ha scritto:
> On Mon, 09 Dec 2013 15:36:35 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>> Il 09/12/2013 15:14, Igor Mammedov ha scritto:
>>>>>
>>>>> Makes sense. realize() for the "plug" handler, and qdev_unplug for the
>>>>> unplug handler, I guess.
>>> Just to be sure, I've meant not DEVICE.realize() but each device specific
>>> one.
>>
>> If it's each specific device, then why should the hotplug handler link
>> be in DeviceState?
> The reason I've put it there is to eventually replace allow_hotplug field with it,
> it also reduces code duplication (i.e. we wont' have to add it in PCIDevice,
> DimmDevice ...) and potentially allows to use NULL for error in
> property lookup since each bus will have it.
I agree that's the right thing to do.
>> I think it should be in device_set_realized.
> if we dub it nofail then it's fine, otherwise failure path becomes more complicated.
>
> Calling handler in specific device realize() allows to gracefully abort
> realize() since that device knows what needs to be done to do so:
> For example:
> @@ -1720,6 +1714,8 @@ static int pci_qdev_init(DeviceState *qdev)
> ...
> + hdc->hotplug(hotplug_dev, qdev, &local_err);
> + if (error_is_set(&local_err)) {
> + int r = pci_unregister_device(&pci_dev->qdev);
>
> Calling handler in realize will not allow to do it.
> It's just much more flexible to call handler from specific device since it knows
> when it's the best to call handler and how to deal with failure.
We could have separate check/plug methods. Only check can fail, it must
be idempotent, and it can be invoked while the device is still unrealized.
The reason I liked the interface, is because it removes the need for
each bus to add its own plug/unplug handling.
Paolo
>>> qdev_unplug() might work for now, but I haven't checked all devices that
>>> might use interface and if it would break anything. Ideally it should be
>>> in device's unrealize() complementing realize() part.
>>>
>>> I'd wait till all buses converted to new interface before attempting to
>>> generalize current plug/unplug call pathes though.
>>
>> I agree that adding a default behavior for no link probably requires
>> conversion of all buses. However, looking for the link in the generic
>> code can be done now.
>>
>> Paolo
>>
>
next prev parent reply other threads:[~2013-12-09 15:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 17:03 [Qemu-devel] [PATCH 0/7] Refactor PCI/SHPC/PCIE hotplug to use a more generic hotplug API Igor Mammedov
2013-12-06 17:03 ` [Qemu-devel] [PATCH 1/7] define hotplug interface Igor Mammedov
2013-12-06 17:26 ` Paolo Bonzini
2013-12-09 12:42 ` Igor Mammedov
2013-12-09 13:15 ` Paolo Bonzini
2013-12-09 5:40 ` Li Guang
2013-12-09 9:11 ` Marcel Apfelbaum
2013-12-09 12:44 ` Igor Mammedov
2013-12-09 8:58 ` Marcel Apfelbaum
2013-12-09 12:52 ` Igor Mammedov
2013-12-06 17:03 ` [Qemu-devel] [PATCH 2/7] qdev: add to BusState "hotplug-device" link Igor Mammedov
2013-12-06 17:03 ` [Qemu-devel] [PATCH 3/7] hw/acpi: move typeinfo to the file end Igor Mammedov
2013-12-06 17:03 ` [Qemu-devel] [PATCH 4/7] acpi/piix4pm: convert ACPI PCI hotplug to use hotplug-device interface Igor Mammedov
2013-12-09 9:02 ` Marcel Apfelbaum
2013-12-09 13:24 ` Igor Mammedov
2013-12-06 17:03 ` [Qemu-devel] [PATCH 5/7] pci/shpc: convert SHPC " Igor Mammedov
2013-12-06 17:03 ` [Qemu-devel] [PATCH 6/7] pci/pcie: convert PCIE " Igor Mammedov
2013-12-06 17:03 ` [Qemu-devel] [PATCH 7/7] hw/pci: convert PCI bus to use "hotplug-device" interface Igor Mammedov
2013-12-06 17:29 ` Paolo Bonzini
2013-12-09 13:41 ` Igor Mammedov
2013-12-09 13:47 ` Paolo Bonzini
2013-12-09 14:14 ` Igor Mammedov
2013-12-09 14:36 ` Paolo Bonzini
2013-12-09 15:08 ` Igor Mammedov
2013-12-09 15:16 ` Paolo Bonzini [this message]
2013-12-09 16:48 ` Igor Mammedov
2013-12-09 17:18 ` Paolo Bonzini
2013-12-09 21:15 ` Igor Mammedov
2013-12-09 22:28 ` Paolo Bonzini
2013-12-09 9:09 ` Marcel Apfelbaum
2013-12-09 13:55 ` Igor Mammedov
2013-12-09 14:01 ` Marcel Apfelbaum
2013-12-06 17:31 ` [Qemu-devel] [PATCH 0/7] Refactor PCI/SHPC/PCIE hotplug to use a more generic hotplug API Paolo Bonzini
2013-12-09 14:15 ` 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=52A5DEE9.9030901@redhat.com \
--to=pbonzini@redhat.com \
--cc=afaerber@suse.de \
--cc=alex.williamson@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=blauwirbel@gmail.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=marcel.a@redhat.com \
--cc=mst@redhat.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 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.