From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRJ4W-0002em-Eg for qemu-devel@nongnu.org; Fri, 08 Jun 2018 11:13:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRJ4S-0008Uw-Ed for qemu-devel@nongnu.org; Fri, 08 Jun 2018 11:13:00 -0400 Date: Fri, 8 Jun 2018 18:12:46 +0300 From: "Michael S. Tsirkin" Message-ID: <20180608181004-mutt-send-email-mst@kernel.org> References: <20180530150806.061c26b9@redhat.com> <5dcb16e5-b9b9-d07d-dfe3-98724e911f83@redhat.com> <20180531161310.52ea9507@redhat.com> <20180607154455.6eab4e24@redhat.com> <5dda6237-88d8-f0f8-58d2-af996368cea4@redhat.com> <20180608142442.0d97b7c6@redhat.com> <397d37ee-b3a8-dae0-37d1-fd3c942448c2@redhat.com> <20180608155432-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v4 04/14] pc: prepare for multi stage hotplug handlers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand Cc: Igor Mammedov , qemu-devel@nongnu.org, qemu-s390x@nongnu.org, 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 On Fri, Jun 08, 2018 at 03:07:53PM +0200, David Hildenbrand wrote: > On 08.06.2018 14:55, Michael S. Tsirkin wrote: > > On Fri, Jun 08, 2018 at 02:32:09PM +0200, David Hildenbrand wrote: > >> > >>>>> if (TYPE_PC_DIMM) { > >>>>> pc_dimm_plug() > >>>>> /* do here additional concrete machine specific things */ > >>>>> } else if (TYPE_VIRTIO_MEM) { > >>>>> virtio_mem_plug() <- do forwarding in there > >>>>> /* and do here additional concrete machine specific things */ > >>>>> } else if (TYPE_CPU) { > >>>>> cpu_plug() > >>>>> /* do here additional concrete machine specific things */ > >>>>> } > >>>> > >>>> That will result in a lot of duplicate code - for every machine we > >>>> support (dimm/virtio-mem/virtio-pmem/*add more memory devices here*) - > >>>> virtio-mem and virtio-pmem could most probably share the code. > >>> maybe or maybe not, depending on if pmem endups as memory device or > >>> separate controller. And even with duplication, machine code would > >>> be easy to follow just down one explicit call chain. > >> > >> Not 100% convinced but I am now going into that direction. > > > > Can this go into DeviceClass? Failover has the same need to > > allocate/free resources for vfio without a full realize/unrealize. > > > > Conceptually, I would have called here something like > > virtio_mem_plug() ... > > Which would end up calling memory_device_plug() and triggering the > target hotplug handler. > > I assume this can also be done from a device class callback. > > So we would need a total of 3 callbacks for > > a) pre_plug > b) plug > c) unplug > > In addition, unplug requests might be necessary, so > > d) unplug_request Right - basically HotplugHandlerClass. > >> -- > >> > >> Thanks, > >> > >> David / dhildenb > > > -- > > Thanks, > > David / dhildenb