qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: zhanghailiang
Subject: Re: [Qemu-devel] [PATCH 1/2] pc-dimm: No numa option shouldn't break hotplug memory feature
Date: Tue, 23 Sep 2014 20:38:52 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

On 2014/9/23 19:12, Igor Mammedov wrote:
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.

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.:)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]