From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fMC4Y-00011q-Bm for qemu-devel@nongnu.org; Fri, 25 May 2018 08:43:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fMC4U-0003Oj-D7 for qemu-devel@nongnu.org; Fri, 25 May 2018 08:43:54 -0400 References: <20180517081527.14410-1-david@redhat.com> From: David Hildenbrand Message-ID: <451cd080-12ab-42bd-0150-e1dbf0abd859@redhat.com> Date: Fri, 25 May 2018 14:43:39 +0200 MIME-Version: 1.0 In-Reply-To: <20180517081527.14410-1-david@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [qemu-s390x] [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: Pankaj Gupta , Eduardo Habkost , "Michael S . Tsirkin" , Cornelia Huck , Markus Armbruster , Alexander Graf , Christian Borntraeger , qemu-s390x@nongnu.org, qemu-ppc@nongnu.org, Paolo Bonzini , Marcel Apfelbaum , Igor Mammedov , Luiz Capitulino , David Gibson , Richard Henderson 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