From: Rob Herring <robh@kernel.org>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: x86@kernel.org, Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Michael Kelley <mhklinux@outlook.com>,
devicetree@vger.kernel.org,
Saurabh Sengar <ssengar@linux.microsoft.com>,
Chris Oo <cho@microsoft.com>,
linux-hyperv@vger.kernel.org,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Ricardo Neri <ricardo.neri@intel.com>
Subject: Re: [PATCH v3 05/13] x86/dt: Parse the `enable-method` property of CPU nodes
Date: Mon, 12 May 2025 10:54:15 -0500 [thread overview]
Message-ID: <20250512155415.GB3377771-robh@kernel.org> (raw)
In-Reply-To: <20250503191515.24041-6-ricardo.neri-calderon@linux.intel.com>
On Sat, May 03, 2025 at 12:15:07PM -0700, Ricardo Neri wrote:
> Add functionality to parse and validate the `enable-method` property for
> platforms that use alternative methods to wakeup secondary CPUs (e.g., a
> wakeup mailbox).
>
> Most x86 platforms boot secondary CPUs using INIT assert, de-assert
> followed by a Start-Up IPI messages. These systems do no need to specify an
> `enable-method` property in the cpu@N nodes of the DeviceTree.
>
> Although it is possible to specify a different `enable-method` for each
> secondary CPU, the existing functionality relies on using the
> APIC wakeup_secondary_cpu{ (), _64()} callback to wake up all CPUs. Ensure
> that either all CPUs specify the same `enable-method` or none at all.
>
> Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> ---
> Changes since v2:
> - Introduced this patch.
>
> Changes since v1:
> - N/A
> ---
> arch/x86/kernel/devicetree.c | 88 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 86 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
> index dd8748c45529..5835afc74acd 100644
> --- a/arch/x86/kernel/devicetree.c
> +++ b/arch/x86/kernel/devicetree.c
> @@ -127,8 +127,59 @@ static void __init dtb_setup_hpet(void)
>
> #ifdef CONFIG_X86_LOCAL_APIC
>
> +#ifdef CONFIG_SMP
> +static const char *dtb_supported_enable_methods[] __initconst = { };
If you expect this list to grow, I would say the firmware should support
"spin-table" enable-method and let's stop the list before it starts.
Look at the mess that's arm32 enable-methods... Considering you have no
interrupts, I imagine what you have is not much different from a
spin-table (write a jump address to an address)? Maybe it would already
work as long as jump table is reserved (And in that case you don't need
the compatible or any binding other than for cpu nodes).
OTOH, as the wakeup-mailbox seems to be defined by ACPI, that seems
fine to add, but I would simplify the code here to not invite more
entries. Further ones should be rejected IMO.
> +
> +static bool __init dtb_enable_method_is_valid(const char *enable_method_a,
> + const char *enable_method_b)
> +{
> + int i;
> +
> + if (!enable_method_a && !enable_method_b)
> + return true;
> +
> + if (strcmp(enable_method_a, enable_method_b))
> + return false;
> +
> + for (i = 0; i < ARRAY_SIZE(dtb_supported_enable_methods); i++) {
> + if (!strcmp(enable_method_a, dtb_supported_enable_methods[i]))
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static int __init dtb_configure_enable_method(const char *enable_method)
> +{
> + /* Nothing to do for a missing enable-method or if the system has one CPU */
> + if (!enable_method || IS_ERR(enable_method))
> + return 0;
> +
> + return -ENOTSUPP;
> +}
> +#else /* !CONFIG_SMP */
> +static inline bool dtb_enable_method_is_valid(const char *enable_method_a,
> + const char *enable_method_b)
> +{
> + /* No secondary CPUs. We do not care about the enable-method. */
> + return true;
> +}
> +
> +static inline int dtb_configure_enable_method(const char *enable_method)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_SMP */
> +
> +static void __init dtb_register_apic_id(u32 apic_id, struct device_node *dn)
> +{
> + topology_register_apic(apic_id, CPU_ACPIID_INVALID, true);
> + set_apicid_to_node(apic_id, of_node_to_nid(dn));
> +}
> +
> static void __init dtb_cpu_setup(void)
> {
> + const char *enable_method = ERR_PTR(-EINVAL), *this_em;
> struct device_node *dn;
> u32 apic_id;
>
> @@ -138,9 +189,42 @@ static void __init dtb_cpu_setup(void)
> pr_warn("%pOF: missing local APIC ID\n", dn);
> continue;
> }
> - topology_register_apic(apic_id, CPU_ACPIID_INVALID, true);
> - set_apicid_to_node(apic_id, of_node_to_nid(dn));
> +
> + /*
> + * Also check the enable-method of the secondary CPUs, if present.
> + *
> + * Systems that use the INIT-!INIT-StartUp IPI sequence to boot
> + * secondary CPUs do not need to define an enable-method.
> + *
> + * All CPUs must have the same enable-method. The enable-method
> + * must be supported. If absent in one secondary CPU, it must be
> + * absent for all CPUs.
> + *
> + * Compare the first secondary CPU with the rest. We do not care
> + * about the boot CPU, as it is enabled already.
> + */
> +
> + if (apic_id == boot_cpu_physical_apicid) {
> + dtb_register_apic_id(apic_id, dn);
> + continue;
> + }
> +
> + this_em = of_get_property(dn, "enable-method", NULL);
Use typed accessors. of_property_match_string() would be good here.
There's some desire to avoid more of_property_read_string() calls too
because that leaks un-refcounted DT data to the caller (really only an
issue in overlays).
> +
> + if (IS_ERR(enable_method)) {
> + enable_method = this_em;
> + dtb_register_apic_id(apic_id, dn);
> + continue;
> + }
> +
> + if (!dtb_enable_method_is_valid(enable_method, this_em))
> + continue;
> +
> + dtb_register_apic_id(apic_id, dn);
> }
> +
> + if (dtb_configure_enable_method(enable_method))
> + pr_err("enable-method '%s' needed but not configured\n", enable_method);
> }
>
> static void __init dtb_lapic_setup(void)
> --
> 2.43.0
>
next prev parent reply other threads:[~2025-05-12 15:54 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-03 19:15 [PATCH v3 00/13] x86/hyperv/hv_vtl: Use a wakeup mailbox to boot secondary CPUs Ricardo Neri
2025-05-03 19:15 ` [PATCH v3 01/13] x86/acpi: Add a helper function to setup the wakeup mailbox Ricardo Neri
2025-05-05 9:50 ` Rafael J. Wysocki
2025-05-06 5:20 ` Ricardo Neri
2025-05-03 19:15 ` [PATCH v3 02/13] x86/acpi: Add a helper function to get a pointer to " Ricardo Neri
2025-05-05 9:55 ` Rafael J. Wysocki
2025-05-06 5:23 ` Ricardo Neri
2025-05-03 19:15 ` [PATCH v3 03/13] x86/acpi: Move acpi_wakeup_cpu() and helpers to smpboot.c Ricardo Neri
2025-05-05 10:03 ` Rafael J. Wysocki
2025-05-06 5:37 ` Ricardo Neri
2025-05-06 17:26 ` Rafael J. Wysocki
2025-05-07 11:22 ` Ricardo Neri
2025-05-03 19:15 ` [PATCH v3 04/13] dt-bindings: x86: Add CPU bindings for x86 Ricardo Neri
2025-05-03 20:33 ` Rob Herring (Arm)
2025-05-04 16:45 ` Krzysztof Kozlowski
2025-05-06 4:52 ` Ricardo Neri
2025-05-06 7:25 ` Krzysztof Kozlowski
2025-05-07 23:16 ` Ricardo Neri
2025-05-03 19:15 ` [PATCH v3 05/13] x86/dt: Parse the `enable-method` property of CPU nodes Ricardo Neri
2025-05-12 15:54 ` Rob Herring [this message]
2025-05-14 3:00 ` Ricardo Neri
2025-05-03 19:15 ` [PATCH v3 06/13] dt-bindings: reserved-memory: Wakeup Mailbox for Intel processors Ricardo Neri
2025-05-04 16:51 ` Krzysztof Kozlowski
2025-05-06 5:16 ` Ricardo Neri
2025-05-06 7:10 ` Krzysztof Kozlowski
2025-05-07 3:23 ` Ricardo Neri
2025-05-12 15:32 ` Rob Herring
2025-05-13 22:14 ` Ricardo Neri
2025-05-14 15:42 ` Rob Herring
2025-05-15 3:53 ` Ricardo Neri
2025-05-19 15:29 ` Rob Herring
2025-05-19 17:56 ` Ricardo Neri
2025-05-24 15:56 ` Ricardo Neri
2025-05-29 13:16 ` Rob Herring
2025-06-02 1:31 ` Ricardo Neri
2025-05-05 13:07 ` Rafael J. Wysocki
2025-05-06 5:50 ` Ricardo Neri
2025-05-06 14:00 ` Rafael J. Wysocki
2025-05-07 11:48 ` Ricardo Neri
2025-05-03 19:15 ` [PATCH v3 07/13] x86/dt: Parse the " Ricardo Neri
2025-05-03 19:15 ` [PATCH v3 08/13] x86/hyperv/vtl: Set real_mode_header in hv_vtl_init_platform() Ricardo Neri
2025-05-20 1:24 ` Michael Kelley
2025-05-03 19:15 ` [PATCH v3 09/13] x86/realmode: Make the location of the trampoline configurable Ricardo Neri
2025-05-20 1:30 ` Michael Kelley
2025-05-03 19:15 ` [PATCH v3 10/13] x86/hyperv/vtl: Setup the 64-bit trampoline for TDX guests Ricardo Neri
2025-05-20 1:31 ` Michael Kelley
2025-05-03 19:15 ` [PATCH v3 11/13] x86/smpboot: Add a helper get the address of the wakeup mailbox Ricardo Neri
2025-05-20 1:32 ` Michael Kelley
2025-05-03 19:15 ` [PATCH v3 12/13] x86/hyperv/vtl: Mark the wakeup mailbox page as private Ricardo Neri
2025-05-20 1:33 ` Michael Kelley
2025-05-03 19:15 ` [PATCH v3 13/13] x86/hyperv/vtl: Use the wakeup mailbox to boot secondary CPUs Ricardo Neri
2025-05-20 1:35 ` Michael Kelley
2025-05-24 0:31 ` Ricardo Neri
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=20250512155415.GB3377771-robh@kernel.org \
--to=robh@kernel.org \
--cc=cho@microsoft.com \
--cc=conor+dt@kernel.org \
--cc=decui@microsoft.com \
--cc=devicetree@vger.kernel.org \
--cc=haiyangz@microsoft.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=krzk+dt@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhklinux@outlook.com \
--cc=ravi.v.shankar@intel.com \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=ricardo.neri@intel.com \
--cc=ssengar@linux.microsoft.com \
--cc=wei.liu@kernel.org \
--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