Re: [Qemu-devel] [PATCH 1/2] pc-dimm: No numa option shouldn't break hotplug memory feature

[zhanghailiang <zhang.zhanghailiang@huawei.com>]

On 2014/9/23 16:58, Tang Chen wrote:
>
> On 09/23/2014 04:40 PM, Igor Mammedov wrote:
>> ......
>> It's fine to use SRAT for these purposes on baremetal NUMA systems since
>> due to used chipset constrains it's possible statically allocate ranges
>> for every possible DIMM socket.
>> However SRAT(which is optional table BTW) entries are not mandatory
>> and override-able by ACPI Device's _PXM/_CRS methods replacing needs
>> for SRAT entries and QEMU uses this fact by supplying these methods.
>> QEMU adds FAKE SRAT entry only to workaround Windows limitation,
>> and for nothing else.
>>
>> I think Linux does not violate ACPI spec and behaves as expected, moreover
>> it's more correct than Windows since memory hotplug will work on non NUMA
>> machines as well.
>>
>> Hence I think this patch is correct and allows memory hotplug in absence
>> of NUMA configuration. It also would allow to use pc-dimm as replacement
>> for initial memory for non-NUMA configs (which is on my TODO list)
>>
>> As for the Windows, QEMU has no idea what OS it would be running,
>> I see 2 ways to solve issue:
>>   1. user should know that memory hotplug on Windows requires NUMA machine
>>      and specify "-numa ..." option for this case.
>>     (I've discussed this with libvirt folks and was promised that
>>      if user enables memory hotplug, libvirt would provide "-numa" option
>>      to workaround Windows issue)
>>
>>   2. QEMU could unconditionally create single NUMA if memory hotplug is
>>      enabled. (but that should be enable only for 2.2 or late machines
>>      to avoid migration issues)
>>
> I prefer 2. I'll try to send patches for it if Zhang is also OK with it.
>

Yep, It is a good scheme to create a dummy NUMA unconditionally.
But Igor has said there are migration issues for this scenario, do you know what's
it? ;)