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

[David Hildenbrand]

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.

-- 

Thanks,

David / dhildenb