Re: [Qemu-devel] [PATCH 21/27] pc: add memory hotplug 440fx machine

[Igor Mammedov]

On Thu, 21 Nov 2013 17:09:27 +0100
Andreas Färber <address@hidden> wrote:

> Am 21.11.2013 15:34, schrieb Igor Mammedov:
> > On Thu, 21 Nov 2013 15:13:12 +0100
> > Andreas Färber <address@hidden> wrote:
> >> Am 21.11.2013 06:48, schrieb Li Guang:
> >>> Why not give the memory that not be hot-added a chance to be placed on
> >>> one memory slot?
> >>
> >> Seconded, I believe I requested that on the previous version already.
> > Because current initial memory allocation is a mess and this already
> > large series would become even more large and intrusive, so far series
> > it relatively not intrusive and self contained.
> > 
> > I believe re-factoring of initial memory to use Dimm devices should be
> > done later on top of infrastructure this series provides.
> 
> My problem with that is that that would be a semantically incompatible
> modeling change. With your series we might have /machine/dimm.0/child[0]
> be the first hot-plugged memory and once such a refactoring is done,
> child[0] silently becomes -m and child[1] is the hot-added one.

I think there won't be silent change in child[0], since most likely
initial RAM would require additional DimmBus (maybe even 2)
for it's devices.

But anyway, why would this be an issue?

> So if we know that we want/need to change the infrastructure, why not
> add a single patch (?) to allocate one additional object on the bus now?
> Unless we actually write the code, we won't know whether there are some
> incorrect hot-plug assumptions in the dimm code.
It wouldn't be a single simple patch for PC, I'm afraid.
I don't see point in adding dummy DIMM device for initial memory and then
do re-aliasing of its memory region in GPA as it's done in current code.

As I see it (taking in account Marcolo's/Paolo's alignment path), current
single MR for initial RAM should be split in 1-4 separate MRs depending on
initial RAM amount and alignment requirements between HPA/GPA addresses.

That would probably introduce additional, non hotlugable DimmBus-es (1-2)
for low and high memory, which would be incompatible with old machine types
devices and GPA layout, so why care about what
/machine/dimm.0/child[0] would be in new machine version?

> Andreas
>