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