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:
Hot-add with monitor command:
If on the other hand we specify:
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