From: Igor Mammedov <imammedo@redhat.com>
To: Gavin Shan <gshan@redhat.com>
Cc: peter.maydell@linaro.org, drjones@redhat.com,
ehabkost@redhat.com, richard.henderson@linaro.org,
qemu-devel@nongnu.org, qemu-arm@nongnu.org, shan.gavin@gmail.com
Subject: Re: [PATCH] hw/arm/virt: Expose empty NUMA nodes through ACPI
Date: Tue, 26 Oct 2021 11:47:51 +0200 [thread overview]
Message-ID: <20211026114751.427205bc@redhat.com> (raw)
In-Reply-To: <20211025234101.224705-1-gshan@redhat.com>
On Tue, 26 Oct 2021 07:41:01 +0800
Gavin Shan <gshan@redhat.com> wrote:
> The empty NUMA nodes, where no memory resides, aren't exposed
> through ACPI SRAT table. It's not user preferred behaviour because
> the corresponding memory node devices are missed from the guest
> kernel as the following example shows, and memory can't be hot
> added to these empty NUMA nodes at later point.
a error message one gets would be useful here.
btw:
memory hotplug seems to work for x86 without adding empty nodes.
So it beg a question, if absence of empty nodes is the issue here.
>
> /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64 \
> -accel kvm -machine virt,gic-version=host \
> -cpu host -smp 4,sockets=2,cores=2,threads=1 \
> -m 1024M,slots=16,maxmem=64G \
> -object memory-backend-ram,id=mem0,size=512M \
> -object memory-backend-ram,id=mem1,size=512M \
> -numa node,nodeid=0,cpus=0-1,memdev=mem0 \
> -numa node,nodeid=1,cpus=2-3,memdev=mem1 \
> -numa node,nodeid=2 \
> -numa node,nodeid=3 \
> :
> guest# ls /sys/devices/system/node | grep node
> node0
> node1
> node2
>
> This exposes these empty NUMA nodes through ACPI SRAT table. With
> this applied, the corresponding memory node devices can be found
> from the guest. Note that the hotpluggable capability is explicitly
> given to these empty NUMA nodes for sake of completeness.
>
> guest# ls /sys/devices/system/node | grep node
> node0
> node1
> node2
> node3
>
> Signed-off-by: Gavin Shan <gshan@redhat.com>
> ---
> hw/arm/virt-acpi-build.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 674f902652..a4c95b2f64 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -526,6 +526,7 @@ build_srat(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
> const CPUArchIdList *cpu_list = mc->possible_cpu_arch_ids(ms);
> AcpiTable table = { .sig = "SRAT", .rev = 3, .oem_id = vms->oem_id,
> .oem_table_id = vms->oem_table_id };
> + MemoryAffinityFlags flags;
>
> acpi_table_begin(&table, table_data);
> build_append_int_noprefix(table_data, 1, 4); /* Reserved */
> @@ -547,12 +548,15 @@ build_srat(GArray *table_data, BIOSLinker *linker, VirtMachineState *vms)
>
> mem_base = vms->memmap[VIRT_MEM].base;
> for (i = 0; i < ms->numa_state->num_nodes; ++i) {
> - if (ms->numa_state->nodes[i].node_mem > 0) {
> - build_srat_memory(table_data, mem_base,
> - ms->numa_state->nodes[i].node_mem, i,
> - MEM_AFFINITY_ENABLED);
> - mem_base += ms->numa_state->nodes[i].node_mem;
> + if (ms->numa_state->nodes[i].node_mem) {
> + flags = MEM_AFFINITY_ENABLED;
> + } else {
> + flags = MEM_AFFINITY_ENABLED | MEM_AFFINITY_HOTPLUGGABLE;
> }
> +
> + build_srat_memory(table_data, mem_base,
> + ms->numa_state->nodes[i].node_mem, i, flags);
> + mem_base += ms->numa_state->nodes[i].node_mem;
> }
>
> if (ms->nvdimms_state->is_enabled) {
next prev parent reply other threads:[~2021-10-26 9:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-25 23:41 [PATCH] hw/arm/virt: Expose empty NUMA nodes through ACPI Gavin Shan
2021-10-26 6:25 ` Andrew Jones
2021-10-27 5:16 ` Gavin Shan
2021-10-26 9:47 ` Igor Mammedov [this message]
2021-10-27 5:20 ` Gavin Shan
2021-10-27 14:31 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211026114751.427205bc@redhat.com \
--to=imammedo@redhat.com \
--cc=drjones@redhat.com \
--cc=ehabkost@redhat.com \
--cc=gshan@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=shan.gavin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.