From: Igor Mammedov <imammedo@redhat.com>
To: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] x86/acpi: build SRAT when memory hotplug is enabled
Date: Mon, 11 Sep 2017 12:58:14 +0200 [thread overview]
Message-ID: <20170911125814.27a8d496@nial.brq.redhat.com> (raw)
In-Reply-To: <e970608d-fb97-210c-72e9-bf4f43a3e54c@cn.fujitsu.com>
On Tue, 5 Sep 2017 09:17:06 +0800
Dou Liyang <douly.fnst@cn.fujitsu.com> wrote:
> Hi Eduardo,
>
> At 09/04/2017 09:08 PM, Eduardo Habkost wrote:
> [...]
> >> In my opinion, this may also add the hotpluggable memory, and see the
> >> following commemts.
> >>
> >> /*
> >> * Entry is required for Windows to enable memory hotplug in OS
> >> * and for Linux to enable SWIOTLB when booted with less than
> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> * 4G of RAM. Windows works better if the entry sets proximity
> >> * to the highest NUMA node in the machine.
> >> * Memory devices may override proximity set by this entry,
> >> * providing _PXM method if necessary.
> >> */
> >> if (hotplugabble_address_space_size) {
> >> numamem = acpi_data_push(table_data, sizeof *numamem);
> >> build_srat_memory(numamem, pcms->hotplug_memory.base,
> >> hotplugabble_address_space_size, pcms->numa_nodes
> >> - 1,
> >> MEM_AFFINITY_HOTPLUGGABLE | MEM_AFFINITY_ENABLED);
> >> }
> >
> > You are correct, I didn't see that part of the code. If that's
> > the entry that's missing, the patch makes sense. Thanks!
> >
> > However, the resulting tables still don't look correct: it will
> > generate an entry assigned to NUMA node (uint32_t)-1 if no NUMA
> > nodes are configured elsewhere, some APIC entries, but no entries
> > for the rest of the memory.
>
> Yes, indeed.
>
> >
> > Igor's suggestion to enable NUMA implicitly sounds safer to me.
> >
>
> I agree with Igor too.
>
> Is anybody doing this? If not, may I make a patch to enable adding NUMA
> node implicitly first. let's see what it looks like.
As far as I'm aware nobody is doing it, so fill free to look into it.
>
> Thanks,
> dou.
>
>
next prev parent reply other threads:[~2017-09-11 10:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-01 15:45 [Qemu-devel] [PATCH] x86/acpi: build SRAT when memory hotplug is enabled Thadeu Lima de Souza Cascardo
2017-09-01 16:11 ` Eduardo Habkost
2017-09-04 1:38 ` Dou Liyang
2017-09-04 13:08 ` Eduardo Habkost
2017-09-05 1:17 ` Dou Liyang
2017-09-11 10:58 ` Igor Mammedov [this message]
2017-09-12 0:58 ` Dou Liyang
2017-09-04 7:23 ` 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=20170911125814.27a8d496@nial.brq.redhat.com \
--to=imammedo@redhat.com \
--cc=cascardo@canonical.com \
--cc=douly.fnst@cn.fujitsu.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.