Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug

[Vasilis Liaskovitis]

Hi,
On Wed, Jan 09, 2013 at 01:08:52AM +0100, Andreas Färber wrote:
> Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis:
> > Because dimm layout needs to be configured on machine-boot, all dimm devices
> > need to be specified on startup command line (either with populated=on or 
> > with
> > populated=off). The dimm information is stored in dimm configuration 
> > structures.
> > 
> > After machine startup, dimms are hot-added or removed with normal device_add
> > and device_del operations e.g.:
> > Hot-add syntax: "device_add dimm,id=mydimm0,bus=membus.0"
> > Hot-remove syntax: "device_del dimm,id=mydimm0"
> 
> This sounds contradictory: Either all devices need to be specified on
> the command line, or they can be hot-added via monitor.

Due to the fixed layout requirement, all memory devices need to be specified at
the command line. This was done with a separate "-dimm" argument in previous
versions (see v3), but some reviewers didn't like the extra argument and
suggested handling everything with the normal "-device" arg.

So "-device dimm,..." saves the layout for *all* memory devices. However for
"populated=off" dimms, the device is actually *not* created at startup.

This is why the following combination is not contradictory:

Dimm descirption at startup:
-device dimm,id=mydimm0,bus=membus.0,size=1G,node=0,populated=off
Hot-add with monitor command: 
device_add dimm,id=mydimm0,bus=membus.0

If on the other hand we specify:
-device dimm,id=mydimm0,bus=membus.0,size=1G,node=0,populated=on
the dimm device is indeed created at startup.

granted it's confusing, but this is how v4 handles the fixed layout/device
creation without adding a new command line argument for the layout. Better
solutions are welcome.

> 
> Assuming a fixed layout at startup, I wonder if there is another clever
> way to model this... For CPU hotplug Anthony had suggested to have a
> fixed set of link<Socket> properties that get set to a CPU socket as
> needed. Might a similar strategy work for memory, i.e. a
> startup-configured amount of link<DIMM>s on /machine/dimm[n] that point
> to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then
> simply work via QMP qom-set command. (CC'ing some people)

This may work for a fixed number of PV dimms. On the other hand some other
reviewers like the idea of modelling the memory bus (DimmBus), either for
paravirtualized features (e.g.  i440fx) or for emulated memory controllers
in the future. I assume we either go with a bus or links<>, and not both.

Btw, is the CPU link<socket> feature already implemented in a qom-cpu branch? I
haven't tested qom-cpu for a long time, but I could take a look as a point of
reference.

thanks,

- Vasilis