Re: [Qemu-ppc] [qemu-s390x] [PATCH v4 00/14] MemoryDevice: use multi stage hotplug handlers

[Paolo Bonzini]

On 25/05/2018 14:43, David Hildenbrand wrote:
> On 17.05.2018 10:15, David Hildenbrand wrote:
>> We can have devices that need certain other resources that are e.g.
>> system resources managed by the machine. We need a clean way to assign
>> these resources (without violating layers as brought up by Igor).
>>
>> One example is virtio-mem/virtio-pmem. Both device types need to be
>> assigned some region in guest physical address space. This device memory
>> belongs to the machine and is managed by it. However, virito devices are
>> hotplugged using the hotplug handler their proxy device implements. So we
>> could trigger e.g. a PCI hotplug handler for virtio-pci or a CSS/CCW
>> hotplug handler for virtio-ccw. But definetly not the machine.
>>
>> Now, we can route other devices through the machine hotplug handler, to
>> properly assign/unassign resources - like a portion in guest physical
>> address space.
>>
>> v3 -> v4:
>> - Removed the s390x bits, will send that out separately (was just a proof
>>   that it works just fine with s390x)
>> - Fixed a typo and reworded a comment
>>
>> v2 -> v3:
>> - Added "memory-device: introduce separate config option"
>> - Dropped "parent_bus" check from hotplug handler lookup functions
>> - "Handly" -> "Handle" in patch description.
>>
>> v1 -> v2:
>> - Use multi stage hotplug handler instead of resource handler
>> - MemoryDevices only compiled if necessary (CONFIG_MEM_HOTPLUG)
>> - Prepare PC/SPAPR machines properly for multi stage hotplug handlers
>> - Route SPAPR unplug code via the hotunplug handler
>> - Directly include s390x support. But there are no usable memory devices
>>   yet (well, only my virtio-mem prototype)
>> - Included "memory-device: drop assert related to align and start of address
>>   space"
>>
>> David Hildenbrand (13):
>>   memory-device: drop assert related to align and start of address space
>>   memory-device: introduce separate config option
>>   pc: prepare for multi stage hotplug handlers
>>   pc: route all memory devices through the machine hotplug handler
>>   spapr: prepare for multi stage hotplug handlers
>>   spapr: route all memory devices through the machine hotplug handler
>>   spapr: handle pc-dimm unplug via hotplug handler chain
>>   spapr: handle cpu core unplug via hotplug handler chain
>>   memory-device: new functions to handle plug/unplug
>>   pc-dimm: implement new memory device functions
>>   memory-device: factor out pre-plug into hotplug handler
>>   memory-device: factor out unplug into hotplug handler
>>   memory-device: factor out plug into hotplug handler
>>
>> Igor Mammedov (1):
>>   qdev: let machine hotplug handler to override bus hotplug handler
>>
>>  default-configs/i386-softmmu.mak   |   3 +-
>>  default-configs/ppc64-softmmu.mak  |   3 +-
>>  default-configs/x86_64-softmmu.mak |   3 +-
>>  hw/Makefile.objs                   |   2 +-
>>  hw/core/qdev.c                     |   6 +-
>>  hw/i386/pc.c                       | 102 ++++++++++++++++++++++-------
>>  hw/mem/Makefile.objs               |   4 +-
>>  hw/mem/memory-device.c             | 129 
>> +++++++++++++++++++++++--------------
>>  hw/mem/pc-dimm.c                   |  48 ++++++--------
>>  hw/mem/trace-events                |   4 +-
>>  hw/ppc/spapr.c                     | 129 
>> +++++++++++++++++++++++++++++++------
>>  include/hw/mem/memory-device.h     |  21 ++++--
>>  include/hw/mem/pc-dimm.h           |   3 +-
>>  include/hw/qdev-core.h             |  11 ++++
>>  qapi/misc.json                     |   2 +-
>>  15 files changed, 330 insertions(+), 140 deletions(-)
>>
> 
> As there was no negative feedback so far, I will go ahead and assume
> that this approach is the right thing to do.

Ok, I'll queue this.

Paolo