From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fAZNf-0006Wk-Ut for qemu-devel@nongnu.org; Mon, 23 Apr 2018 07:11:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fAZNc-000407-OS for qemu-devel@nongnu.org; Mon, 23 Apr 2018 07:11:35 -0400 References: <20180420123456.22196-1-david@redhat.com> <20180420123456.22196-3-david@redhat.com> <20180423032825.GD19804@umbus.fritz.box> <20180423104435.GI19804@umbus.fritz.box> From: David Hildenbrand Message-ID: <44b21f8d-37c7-afc3-2a5a-dd9d7048389d@redhat.com> Date: Mon, 23 Apr 2018 13:11:17 +0200 MIME-Version: 1.0 In-Reply-To: <20180423104435.GI19804@umbus.fritz.box> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 2/3] machine: make MemoryHotplugState accessible via the machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org, "Michael S . Tsirkin" , Igor Mammedov , Marcel Apfelbaum , Paolo Bonzini , Richard Henderson , Eduardo Habkost , Markus Armbruster , qemu-ppc@nongnu.org, Pankaj Gupta On 23.04.2018 12:44, David Gibson wrote: > On Mon, Apr 23, 2018 at 11:36:48AM +0200, David Hildenbrand wrote: >> On 23.04.2018 05:28, David Gibson wrote: >>> On Fri, Apr 20, 2018 at 02:34:55PM +0200, David Hildenbrand wrote: >>>> Let's allow to query the MemoryHotplugState from the machine. >>>> >>>> This allows us to generically detect if a certain machine has support >>>> for memory devices, and to generically manage it (find free address >>>> range, plug/unplug a memory region). >>>> >>>> Signed-off-by: David Hildenbrand >>> >>> So, we're creating a hook where it seems very likely that the only >>> implementationss will be simply to retrieve the right field from the >>> machine specific structure. >>> >>> So.. should we instead just move the hotplug_memory structure to the >>> based MachineState type? >> >> It allows us in patch nr. 3 to report different error messages. >> >> "Not supported" vs. "Not enabled (maxmem)". >> >> We could also handle that via a simple boolean flag inside of the >> struct. What do you think? > > A third option would be to make it a pointer, rather than directly > embedded in the MachineState. That would also avoid the extra > allocation for machines that don't use it. > That sounds like a good alternative, will look into it! Thanks! -- Thanks, David / dhildenb