From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46427) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fGPqT-0001BI-3q for qemu-devel@nongnu.org; Wed, 09 May 2018 10:13:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fGPqO-0007PE-43 for qemu-devel@nongnu.org; Wed, 09 May 2018 10:13:29 -0400 References: <20180503154936.18946-1-david@redhat.com> From: David Hildenbrand Message-ID: <19eb43f8-3bdc-fbfe-47c1-bcc1de7a64ba@redhat.com> Date: Wed, 9 May 2018 16:13:14 +0200 MIME-Version: 1.0 In-Reply-To: <20180503154936.18946-1-david@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 0/8] MemoryDevice: introduce and use ResourceHandler 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 On 03.05.2018 17:49, David Hildenbrand wrote: > Hotplug handlers usually have the following tasks: > 1. Allocate some resources for a new device > 2. Make the new device visible for the guest > 3. Notify the guest about the new device > > Hotplug handlers have right now one limitation: They handle their own > context and only care about resources they manage. > > 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. > > So let's generalize the task of "assigning" resources and use it directly > for memory devices. We now have a clean way to support any kind of memory > device - independent of the underlying device type. Right now, only one > resource handler per device can be supported (in addition to the existing > hotplug handler). > > You can find more details in patch nr 2. > > This work is based on the already queued patch series > "[PATCH v4 00/11] pc-dimm: factor out MemoryDevice" > > David Hildenbrand (8): > memory-device: always compile support for memory devices for SOFTMMU > qdev: introduce ResourceHandler as a first-stage hotplug handler > machine: provide default resource handler > memory-device: new functions to handle resource assignment > pc-dimm: implement new memory device functions > machine: introduce enforce_memory_device_align() and add it for pc > memory-device: factor out pre-assign into default resource handler > memory-device: factor out (un)assign into default resource handler > > hw/Makefile.objs | 2 +- > hw/core/Makefile.objs | 1 + > hw/core/machine.c | 70 +++++++++++++++++++++++ > hw/core/qdev.c | 41 +++++++++++++- > hw/core/resource-handler.c | 57 +++++++++++++++++++ > hw/i386/pc.c | 31 ++++++----- > hw/mem/Makefile.objs | 2 +- > hw/mem/memory-device.c | 122 +++++++++++++++++++++++++---------------- > hw/mem/pc-dimm.c | 53 ++++++++---------- > hw/mem/trace-events | 4 +- > hw/ppc/spapr.c | 5 +- > include/hw/boards.h | 17 ++++++ > include/hw/mem/memory-device.h | 17 ++++-- > include/hw/mem/pc-dimm.h | 3 +- > include/hw/resource-handler.h | 46 ++++++++++++++++ > stubs/Makefile.objs | 1 - > stubs/qmp_memory_device.c | 13 ----- > 17 files changed, 364 insertions(+), 121 deletions(-) > create mode 100644 hw/core/resource-handler.c > create mode 100644 include/hw/resource-handler.h > delete mode 100644 stubs/qmp_memory_device.c > If there are no further comments, I'll send a v2 by the end of this week. Thanks! -- Thanks, David / dhildenb