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: Mon, 22 Sep 2014 17:46:35 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

On 2014/9/22 17:03, Tang Chen wrote:
Hi Igor,

On 09/19/2014 08:26 PM, Igor Mammedov wrote:
On Wed, 17 Sep 2014 16:32:20 +0800
Hu Tao <address@hidden> wrote:

On Tue, Sep 16, 2014 at 06:39:15PM +0800, zhanghailiang wrote:
If we do not configure numa option, memory hotplug should work as well.
It should not depend on numa option.

Steps to reproduce:
(1) Start VM: qemu-kvm -m 1024,slots=4,maxmem=8G
(2) Hotplug memory
It will fail and reports:
"'DIMM property node has value 0' which exceeds the number of numa nodes: 0"

I rememberd Tang Chen had a patch for this bug, this is what Andrey suggested:

   I thnk that there should be no
   cases when dimm is plugged (and check from patch is fired up) without
   actually populated NUMA, because not every OS will workaround this by
   faking the node.
This doesn't take in to account that dimm device by itself has nothing to do
with numa (numa is just optional property of its representation in ACPI land
and nothing else).

In case initial memory is converted to dimm devices, qemu can be

It seems that if we support pc-dimm memory without numa option in startup,
we still need this patch...

started without numa option and it still must work.

So I'm in favor of this path.

I just did some tests. Even if I modify qemu code and make hotpluggable bit in 
SRAT 0,
memory hotplug will still work on Linux guest, which means Linux kernel doesn't 
check
SRAT info after system is up when doing memory hotplug.

I did the following modification in hw/i386/acpi-build.c
-    ram_addr_t hotplugabble_address_space_size =
-        object_property_get_int(OBJECT(pcms), PC_MACHINE_MEMHP_REGION_SIZE,
-                                NULL);
+    ram_addr_t hotplugabble_address_space_size = 0;

And when the guest is up, no memory should be hotpluggable, I think. But I 
hot-added
memory successfully.

IMHO, I think memory hotplug should based on ACPI on Linux. And SRAT tells 
system
which memory ranges are hotpluggable, and we should follow it. So I think Linux 
kernel
has some problem in this issue.

I'd like to fix it like this:

1. Send patches to make Linux kernel to check SRAT info when doing memory 
hotplug.
     (Now, SRAT is only checked at boot time.)

2. In qemu, when users gave a memory hotplug option without NUMA options, we 
create
     node0 and node1, and make node1 hotpluggable.

In this case, guest os will see two numa node even if we don't configure any 
numa option.

     This is because when using MOVABLE_NODE, node0 in which the kernel resides 
in should
     not be hotpluggable.
     Of course, make part of memory in node0 hotpluggable is OK, but on a real 
machine, no
     one will do this, I think. So I suggest above idea.

In actual usage scenario, usually we use the guest numa cooperating with the 
host numa,
It may be strange that we can not hotplug memory to guest node0...


Thanks. :)


https://lists.nongnu.org/archive/html/qemu-devel/2014-08/msg04587.html

Have you tested this patch with Windows guest?

Regards,
Hu

.



.






reply via email to

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