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: Tang Chen
Subject: Re: [Qemu-devel] [PATCH 1/2] pc-dimm: No numa option shouldn't break hotplug memory feature
Date: Tue, 23 Sep 2014 18:32:08 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0


On 09/23/2014 06:11 PM, zhanghailiang 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? ;)

Not sure.  This one ?

https://www.mail-archive.com/qemu-devel%40nongnu.org/msg249146.html

Thanks. :)


.





reply via email to

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