[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] x86/acpi: build SRAT when memory hotplug is ena
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] [PATCH] x86/acpi: build SRAT when memory hotplug is enabled |
Date: |
Mon, 11 Sep 2017 12:58:14 +0200 |
On Tue, 5 Sep 2017 09:17:06 +0800
Dou Liyang <address@hidden> 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.
>
>