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 19:12, Igor Mammedov wrote:
> On Tue, 23 Sep 2014 18:11:35 +0800
> zhanghailiang <zhang.zhanghailiang@huawei.com> wrote:
>
>> 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? ;)
>>
> '-numa' will add SRAT table to ACPI tables blob, as result it will grow in size,
> depending on config options #cpus, #dimms, #pci-bridges it could trigger
> issues we've had with prior 2.1 was released.

Hmm, i guess i know what happened, i have found in function acpi_build
there are annotations for the migration issue...
I will look deep into it, Thanks for your patient explanation.:)