From: Salil Mehta <salil.mehta@huawei.com>
To: Jonathan Cameron <jonathan.cameron@huawei.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
"x86@kernel.org" <x86@kernel.org>,
Russell King <linux@armlinux.org.uk>,
"Rafael J . Wysocki" <rafael@kernel.org>,
"Miguel Luis" <miguel.luis@oracle.com>,
James Morse <james.morse@arm.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
Linuxarm <linuxarm@huawei.com>,
"justin.he@arm.com" <justin.he@arm.com>,
"jianyong.wu@arm.com" <jianyong.wu@arm.com>
Subject: RE: [PATCH v6 13/16] arm64: arch_register_cpu() variant to check if an ACPI handle is now available.
Date: Wed, 17 Apr 2024 16:33:02 +0000 [thread overview]
Message-ID: <073c665c658e40f080c766803d326b77@huawei.com> (raw)
In-Reply-To: <20240417131909.7925-14-Jonathan.Cameron@huawei.com>
Hi Jonathan,
> From: Jonathan Cameron <jonathan.cameron@huawei.com>
> Sent: Wednesday, April 17, 2024 2:19 PM
>
> The ARM64 architecture does not support physical CPU HP today.
> To avoid any possibility of a bug against such an architecture if defined in
> future, check for the physical CPU HP case (not present) and return an error
> on any such attempt.
>
> On ARM64 virtual CPU Hotplug relies on the status value that can be queried
> via the AML method _STA for the CPU object.
>
> There are two conditions in which the CPU can be registered.
> 1) ACPI disabled.
> 2) ACPI enabled and the acpi_handle is available.
> _STA evaluates to the CPU is both enabled and present.
> (Note that in absence of the _STA method they are always in this
> state).
>
> If neither of these conditions is met the CPU is not 'yet' ready to be used
> and -EPROBE_DEFER is returned.
>
> Success occurs in the early attempt to register the CPUs if we are booting
> with DT (no concept yet of vCPU HP) if not it succeeds for already enabled
> CPUs when the ACPI Processor driver attaches to them. Finally it may
> succeed via the CPU Hotplug code indicating that the CPU is now enabled.
>
> For ACPI if CONFIG_ACPI_PROCESSOR the only path to get to
> arch_register_cpu() with that handle set is via
> acpi_processor_hot_add_init() which is only called from an ACPI bus scan in
> which _STA has already been queried there is no need to repeat it here.
> Add a comment to remind us of this in the future.
>
> Suggested-by: Rafael J. Wysocki <rafael@kernel.org>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> v6: Add protection again Physical CPU HP to the arch specific code
> and don't actually check _STA
>
> Tested on arm64 with ACPI + DT build and DT only builds, booting with ACPI
> and DT as appropriate.
> ---
> arch/arm64/kernel/smp.c | 53
> +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index
> dc0e0b3ec2d4..ccb6ad347df9 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -504,6 +504,59 @@ static int __init smp_cpu_setup(int cpu) static bool
> bootcpu_valid __initdata; static unsigned int cpu_count = 1;
>
> +int arch_register_cpu(int cpu)
> +{
> + acpi_handle acpi_handle = acpi_get_processor_handle(cpu);
> + struct cpu *c = &per_cpu(cpu_devices, cpu);
> +
> + if (!acpi_disabled && !acpi_handle &&
> + IS_ENABLED(CONFIG_ACPI_HOTPLUG_CPU))
> + return -EPROBE_DEFER;
> +
> +#ifdef CONFIG_ACPI_HOTPLUG_CPU
> + /* For now block anything that looks like physical CPU Hotplug */
> + if (invalid_logical_cpuid(cpu) || !cpu_present(cpu)) {
> + pr_err_once("Changing CPU present bit is not
> supported\n");
> + return -ENODEV;
> + }
> +#endif
> +
> + /*
> + * Availability of the acpi handle is sufficient to establish
> + * that _STA has aleady been checked. No need to recheck here.
> + */
> + c->hotpluggable = arch_cpu_is_hotpluggable(cpu);
> +
We would still need 'enabled' bitmask as applications need a way to clearly
get which processors are enabled and usable in case of ARM64. Otherwise,
they will end up scanning the entire MAX CPU space to figure out which
processors have been plugged or unplugged. It is inefficient to bank upon
errors to detect this and unnecessary to scan again and again.
+ set_cpu_enabled(cpu, true); // will need this change
And its corresponding additions of enabled bitmask along side the present masks.
I think we had this discussion in Linaro Open Discussions group few years
back.
> + return register_cpu(c, cpu);
> +}
> +
> +#ifdef CONFIG_ACPI_HOTPLUG_CPU
> +void arch_unregister_cpu(int cpu)
> +{
> + acpi_handle acpi_handle = acpi_get_processor_handle(cpu);
> + struct cpu *c = &per_cpu(cpu_devices, cpu);
> + acpi_status status;
> + unsigned long long sta;
> +
> + if (!acpi_handle) {
> + pr_err_once("Removing a CPU without associated ACPI
> handle\n");
> + return;
> + }
> +
> + status = acpi_evaluate_integer(acpi_handle, "_STA", NULL, &sta);
> + if (ACPI_FAILURE(status))
> + return;
> +
> + /* For now do not allow anything that looks like physical CPU HP */
> + if (cpu_present(cpu) && !(sta & ACPI_STA_DEVICE_PRESENT)) {
> + pr_err_once("Changing CPU present bit is not
> supported\n");
> + return;
> + }
> +
For the same reasons as above:
+ set_cpu_enabled(cpu, flase); // will need this change
> + unregister_cpu(c);
> +}
> +#endif /* CONFIG_ACPI_HOTPLUG_CPU */
> +
> #ifdef CONFIG_ACPI
> static struct acpi_madt_generic_interrupt cpu_madt_gicc[NR_CPUS];
>
> --
> 2.39.2
next prev parent reply other threads:[~2024-04-17 16:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 13:18 [PATCH v6 00/16] ACPI/arm64: add support for virtual cpu hotplug Jonathan Cameron
2024-04-17 13:18 ` [PATCH v6 01/16] ACPI: processor: Simplify initial onlining to use same path for cold and hotplug Jonathan Cameron
2024-04-17 13:18 ` [PATCH v6 02/16] cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER Jonathan Cameron
2024-04-17 14:01 ` Russell King (Oracle)
2024-04-17 14:41 ` Jonathan Cameron
2024-04-17 13:18 ` [PATCH v6 03/16] ACPI: processor: Drop duplicated check on _STA (enabled + present) Jonathan Cameron
2024-04-17 13:18 ` [PATCH v6 04/16] ACPI: processor: Move checks and availability of acpi_processor earlier Jonathan Cameron
2024-04-17 15:08 ` Salil Mehta
2024-04-17 15:19 ` Jonathan Cameron
2024-04-18 8:16 ` Jonathan Cameron
2024-04-17 13:18 ` [PATCH v6 05/16] ACPI: processor: Add acpi_get_processor_handle() helper Jonathan Cameron
2024-04-17 13:18 ` [PATCH v6 06/16] ACPI: processor: Register deferred CPUs from acpi_processor_get_info() Jonathan Cameron
2024-04-17 15:03 ` Salil Mehta
2024-04-17 15:38 ` Jonathan Cameron
2024-04-17 15:59 ` Rafael J. Wysocki
2024-04-17 17:09 ` Jonathan Cameron
2024-04-17 17:59 ` Rafael J. Wysocki
2024-04-17 18:57 ` Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 07/16] ACPI: scan: switch to flags for acpi_scan_check_and_detach(); Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 08/16] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 09/16] arm64: acpi: Move get_cpu_for_acpi_id() to a header Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 10/16] irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc() Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 11/16] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 12/16] arm64: psci: Ignore DENIED CPUs Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 13/16] arm64: arch_register_cpu() variant to check if an ACPI handle is now available Jonathan Cameron
2024-04-17 16:33 ` Salil Mehta [this message]
2024-04-17 16:55 ` Jonathan Cameron
2024-04-17 17:03 ` Salil Mehta
2024-04-17 13:19 ` [PATCH v6 14/16] arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is enabled Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 15/16] arm64: document virtual CPU hotplug's expectations Jonathan Cameron
2024-04-17 13:19 ` [PATCH v6 16/16] cpumask: Add enabled cpumask for present CPUs that can be brought online Jonathan Cameron
2024-04-17 17:01 ` Salil Mehta
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=073c665c658e40f080c766803d326b77@huawei.com \
--to=salil.mehta@huawei.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=james.morse@arm.com \
--cc=jean-philippe@linaro.org \
--cc=jianyong.wu@arm.com \
--cc=jonathan.cameron@huawei.com \
--cc=justin.he@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxarm@huawei.com \
--cc=loongarch@lists.linux.dev \
--cc=miguel.luis@oracle.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=will@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).