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 >
