Re: [Qemu-devel] [RFC PATCH v3 06/19] Implement "-dimm" command line option

[Vasilis Liaskovitis]

Hi,

sorry for the delayed answer.

On Sat, Sep 29, 2012 at 11:13:04AM +0000, Blue Swirl wrote:
> >
> > The "-dimm" option is supposed to specify the dimm/memory layout, and not 
> > create
> > any devices.
> >
> > If we don't want this new option, I have a question:
> >
> > A "-device/device_add" means we create a new qdev device at startup or as a
> > hotplug operation respectively. So, the semantics of
> > "-device dimm,id=dimm0,size=512M,node=0,populated=on" are clear to me.
> >
> > What does "-device dimm,populated=off" mean from a qdev perspective? There 
> > are 2
> > alternatives:
> >
> > - The device is created on the dimmbus, but is not used/populated yet. Than 
> > the
> > activation/acpi-hotplug of the dimm may require a separate command (we used 
> > to have
> > "dimm_add" in versions < 3). "device_add" handling always hotplugs a new 
> > qdev
> > device, so this wouldn't fit this usecase, because the device already 
> > exists. In
> > this case, the actual "acpi hotplug" operation is decoupled from qdev device
> > creation.
> 
> The bus exists but the devices do not, device_add would add DIMMs to
> the bus. This matches PCI bus created by the host bridge and PCI
> device hotplug.
> 
> A more complex setup would be dimm bus, dimm slot devices and DIMM
> devices. The intermediate slot device would contain one DIMM device if
> plugged.

interesting, I haven't thought about this alternative. It does sounds overly
complex, but a dimmslot / dimmdevice splitup could consolidate hotplug semantic
differences between populated=on/off. Something similar to the dimmslot device
is already present in v3 (dimmcfg structure), but it's not a qdev visible 
device.
I 'd rather avoid the complication, but i might revisit this idea.

> 
> >
> > - The dimmdevice is not created when "-device dimm,populated=off" (this 
> > would
> > require some ugly checking in normal -device argument handling). Only the 
> > dimm
> > layout is saved. The hotplug is triggered from a normal device_add later. 
> > So in
> > this case, the "acpi hotplug" happens at the same time as the qdev hotplug.
> >
> > Do you see a simpler alternative without introducing a new option?
> >
> > Using the "-dimm" option follows the second semantic and avoids changing 
> > the "-device"
> > semantics. Dimm layout description is decoupled from dimmdevice creation, 
> > and qdev
> > hotplug coincides with acpi hotplug.
> 
> Maybe even the dimmbus device shouldn't exist by itself after all, or
> it should be pretty much invisible to users. On real HW, the memory
> controller or south bridge handles the memory. For i440fx, it's part
> of the same chipset. So I think we should just add qdev properties to
> i440fx to specify the sizes, nodes etc. Then i440fx should create the
> dimmbus device unconditionally using the properties. The default
> properties should create a sane configuration, otherwise -global
> i440fx.dimm_size=512M etc. could be used. Then the bus would be
> populated as before or with device_add.

hmm the problem with using only i440fx properties, is that size/nodes look
dimm specific to me, not chipset-memcontroller specific. Unless we only allow
uniform size dimms. Is it possible to have a dynamic list of sizes/nodes pairs 
as 
properties of a qdev device?

Also if there is no dimmbus, and instead we have only links<> from i440fx to 
dimm-devices,
would the current qdev hotplug API be enough?

I am currently leaning towards this: i440fx unconditionally creates the 
dimmbus. Users
don't have to specify the bus (i assume this is what you mean by "dimmbus should
be invisible to the users")

We only use "-device dimm" to describe dimms. With "-device 
dimm,populated=off", only
the dimm config layout will be saved in the dimmbus. The hotplug is triggered 
from a normal
device_add later (same as pci hotplug). 

thanks,

- Vasilis