From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fJE4V-0002RR-Ql for qemu-devel@nongnu.org; Thu, 17 May 2018 04:15:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fJE4R-0002oO-PK for qemu-devel@nongnu.org; Thu, 17 May 2018 04:15:35 -0400 From: David Hildenbrand Date: Thu, 17 May 2018 10:15:13 +0200 Message-Id: <20180517081527.14410-1-david@redhat.com> Subject: [Qemu-devel] [PATCH v4 00/14] MemoryDevice: use multi stage hotplug handlers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: qemu-s390x@nongnu.org, "Michael S . Tsirkin" , Igor Mammedov , Marcel Apfelbaum , Paolo Bonzini , Richard Henderson , Eduardo Habkost , David Gibson , Markus Armbruster , qemu-ppc@nongnu.org, Pankaj Gupta , Alexander Graf , Cornelia Huck , Christian Borntraeger , Luiz Capitulino , David Hildenbrand 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(-) -- 2.14.3