[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [PATCH v2 04/17] pc: route all memory devices through t
From: |
David Hildenbrand |
Subject: |
Re: [qemu-s390x] [PATCH v2 04/17] pc: route all memory devices through the machine hotplug handler |
Date: |
Sat, 12 May 2018 18:45:50 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 12.05.2018 16:47, Paolo Bonzini wrote:
> On 11/05/2018 15:19, David Hildenbrand wrote:
>> + if (dev->parent_bus) {
>> + if (object_dynamic_cast(OBJECT(dev), TYPE_MEMORY_DEVICE)) {
>> + return HOTPLUG_HANDLER(machine);
>> + }
>> + }
>> +
>
> How do you get here with a MemoryDevice that has !dev->parent_bus?
>
Excellent question :)
This is for now (for pc and spapr) a theoretical case, but I
included it to make all hotplug handler look alike and also show for
other potential device (interfaces) how it should be handled.
I'll give you the s390x example I had in mind:
s390x cannot hotplug dimms. dimms, however are busless devices that
implement the MemoryDevice interface.
If we would simply always indicate this way that we have a hotplug
handler, e.g. the check in qdev_device_add() would not trigger:
...
if (bus) {
qdev_set_parent_bus(dev, bus);
} else if (qdev_hotplug && !qdev_get_machine_hotplug_handler(dev)) {
/* No bus, no machine hotplug handler --> device is not hotpluggable */
error_setg(&err, "Device '%s' can not be hotplugged on this machine",
driver);
goto err_del_dev;
}
...
So the rational is "if its a busless device and I (the machine)
am not able to fully plug it, I must also not partially plug it."
However, right now I am not sure (due to qdev_hotplug) if this
is enough.
> Thanks,
>
> Paolo
>
--
Thanks,
David / dhildenb
- [qemu-s390x] [PATCH v2 00/17] MemoryDevice: use multi stage hotplug handlers, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 02/17] qdev: let machine hotplug handler to override bus hotplug handler, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 01/17] memory-device: drop assert related to align and start of address space, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 04/17] pc: route all memory devices through the machine hotplug handler, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 05/17] spapr: prepare for multi stage hotplug handlers, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 06/17] spapr: route all memory devices through the machine hotplug handler, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 03/17] pc: prepare for multi stage hotplug handlers, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 07/17] spapr: handle pc-dimm unplug via hotplug handler chain, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 08/17] spapr: handle cpu core unplug via hotplug handler chain, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 09/17] memory-device: new functions to handle plug/unplug, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 10/17] pc-dimm: implement new memory device functions, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 11/17] memory-device: factor out pre-plug into hotplug handler, David Hildenbrand, 2018/05/11
- [qemu-s390x] [PATCH v2 12/17] memory-device: factor out unplug into hotplug handler, David Hildenbrand, 2018/05/11