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.
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)
Regards, Andreas
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
在 2013-01-09三的 01:08 +0100，Andreas Färber写道：
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.
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)
Sorry, what's link<>, did it adopted by cpu-QOM? can you give some hints?
Thanks!
On Wed, Mar 20, 2013 at 02:18:00PM +0800, li guang wrote:
在 2013-01-09三的 01:08 +0100，Andreas Färber写道：
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.
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)
Sorry, what's link<>, did it adopted by cpu-QOM?
"link<...>" is a QOM construct, allowing properties that point to other objects. We don't use it on the CPU objects yet.
can you give some hints?
Look for mentions of "link" in the doc comments at include/qom/object.h.
在 2013-03-26二的 11:20 -0300，Eduardo Habkost写道：
On Wed, Mar 20, 2013 at 02:18:00PM +0800, li guang wrote:
在 2013-01-09三的 01:08 +0100，Andreas Färber写道：
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.
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)
Sorry, what's link<>, did it adopted by cpu-QOM?
"link<...>" is a QOM construct, allowing properties that point to other objects. We don't use it on the CPU objects yet.
can you give some hints?
Look for mentions of "link" in the doc comments at include/qom/object.h.
OK, I see, Thanks!
-
Andreas Färber -
Eduardo Habkost -
li guang -
Vasilis Liaskovitis