From patchwork Thu May 3 15:49:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 908098 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=208.118.235.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 40cKR11vDbz9s35 for ; Fri, 4 May 2018 01:52:29 +1000 (AEST) Received: from localhost ([::1]:57361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fEGWx-0002Jl-3Y for incoming@patchwork.ozlabs.org; Thu, 03 May 2018 11:52:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fEGUS-0000h0-8O for qemu-devel@nongnu.org; Thu, 03 May 2018 11:49:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fEGUP-0003fh-5P for qemu-devel@nongnu.org; Thu, 03 May 2018 11:49:52 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:60474 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fEGUP-0003fO-0H; Thu, 03 May 2018 11:49:49 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 49A0B4270963; Thu, 3 May 2018 15:49:45 +0000 (UTC) Received: from t460s.redhat.com (ovpn-117-201.ams2.redhat.com [10.36.117.201]) by smtp.corp.redhat.com (Postfix) with ESMTP id 85A2A2166BAD; Thu, 3 May 2018 15:49:37 +0000 (UTC) From: David Hildenbrand To: qemu-devel@nongnu.org Date: Thu, 3 May 2018 17:49:28 +0200 Message-Id: <20180503154936.18946-1-david@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 03 May 2018 15:49:45 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Thu, 03 May 2018 15:49:45 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'david@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH v1 0/8] MemoryDevice: introduce and use ResourceHandler X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pankaj Gupta , Eduardo Habkost , "Michael S . Tsirkin" , David Hildenbrand , Markus Armbruster , Alexander Graf , qemu-s390x@nongnu.org, qemu-ppc@nongnu.org, Paolo Bonzini , Marcel Apfelbaum , Igor Mammedov , David Gibson , Richard Henderson Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" 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