On Tue, 23 Sep 2014 18:11:35 +0800
zhanghailiang <address@hidden> 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.