[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH v3 2/3] machine: make MemoryHotplugState accessibl
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [PATCH v3 2/3] machine: make MemoryHotplugState accessible via the machine |
Date: |
Mon, 23 Apr 2018 20:44:35 +1000 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
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 <address@hidden>
> >
> > 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.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
[Qemu-ppc] [PATCH v3 1/3] pc-dimm: factor out MemoryDevice interface, David Hildenbrand, 2018/04/20
Re: [Qemu-ppc] [Qemu-devel] [PATCH v3 1/3] pc-dimm: factor out MemoryDevice interface, Pankaj Gupta, 2018/04/22
[Qemu-ppc] [PATCH v3 3/3] pc-dimm: factor out address space logic into MemoryDevice code, David Hildenbrand, 2018/04/20