From: David Daney <ddaney@caviumnetworks.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: David Daney <ddaney.cavm@gmail.com>,
Will Deacon <will.deacon@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
<x86@kernel.org>, Len Brown <lenb@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Robert Moore <robert.moore@intel.com>,
Lv Zheng <lv.zheng@intel.com>, Hanjun Guo <hanjun.guo@linaro.org>,
Marc Zyngier <Marc.Zyngier@arm.com>, <linux-ia64@vger.kernel.org>,
<linux-acpi@vger.kernel.org>, <devel@acpica.org>,
Robert Richter <rrichter@cavium.com>,
Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>,
<linux-kernel@vger.kernel.org>,
David Daney <david.daney@cavium.com>,
Jon Masters <jcm@redhat.com>
Subject: Re: [PATCH v6 13/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT
Date: Wed, 11 May 2016 17:06:13 -0700 [thread overview]
Message-ID: <5733C8F5.6090206@caviumnetworks.com> (raw)
In-Reply-To: <20160511103929.GC3051@e104818-lin.cambridge.arm.com>
On 05/11/2016 03:39 AM, Catalin Marinas wrote:
> On Wed, Apr 27, 2016 at 11:07:15AM -0700, David Daney wrote:
>> +static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
>> +{
>> + unsigned long madt_end, entry;
>> + struct acpi_table_madt *madt;
>> + acpi_size tbl_size;
>> +
>> + if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_MADT, 0,
>> + (struct acpi_table_header **)&madt, &tbl_size)))
>> + return -ENODEV;
>> +
>> + entry = (unsigned long)madt;
>> + madt_end = entry + madt->header.length;
>> +
>> + /* Parse all entries looking for a match. */
>> + entry += sizeof(struct acpi_table_madt);
>> + while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
>> + struct acpi_subtable_header *header =
>> + (struct acpi_subtable_header *)entry;
>> +
>> + if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
>> + struct acpi_madt_generic_interrupt *gicc =
>> + container_of(header,
>> + struct acpi_madt_generic_interrupt, header);
>> +
>> + if ((gicc->flags & ACPI_MADT_ENABLED) &&
>> + (gicc->uid == acpi_id)) {
>> + *mpidr = gicc->arm_mpidr;
>> + early_acpi_os_unmap_memory(madt, tbl_size);
>> + return 0;
>> + }
>> + }
>> + entry += header->length;
>> + }
>> +
>> + early_acpi_os_unmap_memory(madt, tbl_size);
>> + return -ENODEV;
>> +}
>> +
>> +/* Callback for Proximity Domain -> ACPI processor UID mapping */
>> +void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
>> +{
>> + int pxm, node;
>> + u64 mpidr;
>> +
>> + if (srat_disabled())
>> + return;
>> +
>> + if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
>> + pr_err("SRAT: Invalid SRAT header length: %d\n",
>> + pa->header.length);
>> + bad_srat();
>> + return;
>> + }
>> +
>> + if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
>> + return;
>> +
>> + if (cpus_in_srat >= NR_CPUS) {
>> + pr_warn_once("SRAT: cpu_to_node_map[%d] is too small, may not be able to use all cpus\n",
>> + NR_CPUS);
>> + return;
>> + }
>> +
>> + pxm = pa->proximity_domain;
>> + node = acpi_map_pxm_to_node(pxm);
>> +
>> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
>> + pr_err("SRAT: Too many proximity domains %d\n", pxm);
>> + bad_srat();
>> + return;
>> + }
>> +
>> + if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
>> + pr_err("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
>> + pxm, pa->acpi_processor_uid);
>> + bad_srat();
>> + return;
>> + }
>
> I wonder whether you could replace the get_mpidr_in_madt() function with
> something like acpi_get_phys_id(). It looks like get_mpidr_in_madt()
> duplicates functionality already available elsewhere.
>
I just tried that, and it doesn't work.
The problem is that this code is being run very early in the boot, and
kmalloc cannot be used. acpi_get_phys_id() and its ilk can only be used
once we have working kmalloc. We need to extract the NUMA information
early like this precisely because it is needed to initializing the slab
system
Notice that we are using early_acpi_os_unmap_memory() et al. in
get_mpidr_in_madt() explicitly for this reason.
In summary: I don't think we need another revision of this patch, it is
like this for a good reason.
David Daney
next prev parent reply other threads:[~2016-05-12 0:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 18:07 [PATCH v6 00/14] ACPI NUMA support for ARM64 David Daney
2016-04-27 18:07 ` [PATCH v6 01/14] acpi, numa: Use pr_fmt() instead of printk David Daney
2016-04-27 18:07 ` [PATCH v6 02/14] acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug() David Daney
2016-04-27 18:07 ` [PATCH v6 03/14] acpi, numa: remove duplicate NULL check David Daney
2016-04-27 18:07 ` [PATCH v6 04/14] acpi, numa: Move acpi_numa_arch_fixup() to ia64 only David Daney
2016-04-27 18:07 ` [PATCH v6 05/14] acpi, numa: move acpi_numa_slit_init() to drivers/acpi/numa.c David Daney
2016-04-27 18:07 ` [PATCH v6 06/14] arm64, numa: rework numa_add_memblk() David Daney
2016-05-11 9:12 ` Catalin Marinas
2016-04-27 18:07 ` [PATCH v6 07/14] arm64, numa: Cleanup NUMA disabled messages David Daney
2016-05-11 9:12 ` Catalin Marinas
2016-04-27 18:07 ` [PATCH v6 08/14] x86, acpi, numa: cleanup acpi_numa_processor_affinity_init() David Daney
2016-04-27 18:07 ` [PATCH v6 09/14] acpi, numa: move bad_srat() and srat_disabled() to drivers/acpi/numa.c David Daney
2016-04-27 18:07 ` [PATCH v6 10/14] acpi, numa: remove unneeded acpi_numa=1 David Daney
2016-04-27 18:07 ` [PATCH v6 11/14] acpi, numa: Move acpi_numa_memory_affinity_init() to drivers/acpi/numa.c David Daney
2016-04-27 18:07 ` [PATCH v6 12/14] acpi, numa, srat: Improve SRAT error detection and add messages David Daney
2016-04-27 18:07 ` [PATCH v6 13/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT David Daney
2016-05-11 10:39 ` Catalin Marinas
2016-05-12 0:06 ` David Daney [this message]
2016-05-12 1:03 ` Hanjun Guo
2016-05-12 9:49 ` Catalin Marinas
2016-05-12 15:27 ` David Daney
2016-05-12 16:24 ` Catalin Marinas
2016-05-12 20:40 ` David Daney
2016-04-27 18:07 ` [PATCH v6 14/14] acpi, numa: Enable ACPI based NUMA on ARM64 David Daney
2016-05-11 10:40 ` Catalin Marinas
2016-05-11 0:43 ` [PATCH v6 00/14] ACPI NUMA support for ARM64 Rafael J. Wysocki
2016-05-11 10:40 ` Will Deacon
2016-05-11 20:35 ` Rafael J. Wysocki
2016-05-11 21:08 ` David Daney
2016-05-11 21:22 ` Rafael J. Wysocki
2016-05-11 21:30 ` David Daney
2016-05-11 22:29 ` Rafael J. Wysocki
2016-05-12 8:56 ` Will Deacon
2016-05-12 12:54 ` Rafael J. Wysocki
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=5733C8F5.6090206@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=Marc.Zyngier@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=devel@acpica.org \
--cc=fenghua.yu@intel.com \
--cc=frowand.list@gmail.com \
--cc=gkulkarni@caviumnetworks.com \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=hpa@zytor.com \
--cc=jcm@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
--cc=robh+dt@kernel.org \
--cc=rrichter@cavium.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox