Re: [Qemu-devel] [PATCH v5 05/14] vl: handle "-device dimm"

[Paolo Bonzini <pbonzini@redhat.com>]

Il 16/07/2013 14:00, Igor Mammedov ha scritto:
>>> we can leave -numa for initial memory mapping and manage of the mapping
>>> of hotpluggable regions with -device dimm,node=X,size=Y.
>>>
>>> It that case command line -device dimm will provide a fully initialized
>>> dimm device usable at startup (but hot-unplugable) and
>>>   (monitor) device_add dimm,,node=X,size=Y
>>> would serve hot-plug case.
>>>
>>> That way arbitrary sized dimm could be hot-pluged without specifying them
>>> at startup, like it's done on bare-metal.
>>
>> But the memory ranges need to be specified at startup in the ACPI
>> tables, and that's what "-numa mem" is for.
> not really, there is caveat with windows, which needs a hotplugable SRAT entry
> that tells it max possible limit (otherwise windows sees new dimm device but
> refuses to use it saying "server is not configured for hotplug" or something
> like this), but as far as such entry exists, windows is happily uses dynamic
> _CRS() and _PXM() if they are below that limit (even if a new range is not in
> any range defined by SRAT).
> 
> And ACPI spec doesn't say that SRAT MUST be populated with hotplug ranges.

Right, what is required in ACPI is only pre-allocation of slots.

> It's kind of simplier for bare-metal, where they might do it due to limited
> supported DIMM capacity by reserving static entries with max supported ranges
> per DIMM and know in advance DIMM count for platform. But actual _CRS() anyway
> dynamic since plugged in DIMM could have a smaller capacity then supported
> max for slot.
> 
> To summarize ACPI + windows limitations:
>  - ACPI needs to pre-allocate memory devices, i.e. number of possible increments
>    OSPM could utilize. It might be possible to overcome limitation be using
>    Load() or LoadTable() in runtime, but I haven't tried it.
>  - Windows needs to know max supported limit, a fake entry in SRAT from RamSize
>    to max_mem works nicely there (tested with ws2008r2DC and ws2012DC).
> 
> That's why I was proposing to extend "-m" option for "slots" number (i.e. nr of
> memory devices) and 'max_mem' to make Windows happy and cap mgmt tools from
> going over initially configured limit.

As far as memory hot-plug is concerned, the "-numa mem" proposal is
exactly the same thing that you are proposing, minus the ability to
specify many slots in one go.  The same "-numa mem" can be used for host
node binding as well, but that's not really relevant for memory hot-plug.

In case you want multiple hotpluggable ranges, bonud to different host
nodes, It doesn't matter if the SRAT will have one or many fake entries.

> then -device dimm could be used for hotpluggable mem available at startup
> and device_add fir adding more dimms with user defined sizes to desired nodes
> at runtime.

Yes, no disagreement on this.

> Works nice without any need for 'populated=xxx' and predefined ranges.
> 
> PS:
> I'll be able to post more or less usable RFC that does it on top of mst's ACPI
> tables in QEMU by the end of this week.

Good!

Paolo

>>
>>> In addition command line -device would be used in migration case to describe
>>> already hot-plugged dimms on target.
>>
>> Yep.
>>
>> Paolo
>