From: Catalin Marinas <catalin.marinas@arm.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: Thomas Gleixner <tglx@kernel.org>,
peterz@infradead.org, sudeep.holla@kernel.org,
yangyicong@hisilicon.com, dietmar.eggemann@arm.com,
Jonathan.Cameron@huawei.com, linux-kernel@vger.kernel.org,
James Morse <james.morse@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
Date: Thu, 23 Apr 2026 21:11:16 +0100 [thread overview]
Message-ID: <aep85G05D3TM9uj2@arm.com> (raw)
In-Reply-To: <78515da3-03a1-4fdb-a606-3fea9f4cd20b@huawei.com>
On Thu, Apr 23, 2026 at 08:32:34PM +0800, Jinjie Ruan wrote:
> On 4/23/2026 6:08 PM, Thomas Gleixner wrote:
> > On Sat, Apr 18 2026 at 12:55, Catalin Marinas wrote:
> >> Another option would have been to avoid marking such CPUs present but I
> >> think this will break other things. Yet another option is to register
> >> all CPU devices even if they never come up (like maxcpus greater than
> >> actual CPUs).
> >>
> >> Opinions? It might be an arm64+ACPI-only thing.
> >
> > I think so. The proper thing to do is to apply sane limits:
> >
> > 1) The possible CPUs enumerated by firmware N_POSSIBLE_FW
> >
> > 2) The maxcpus limit on the command line N_MAXCPUS_CL
> >
> > So the actual possible CPUs evaluates to:
> >
> > num_possible = min(N_POSSIBLE_FW, N_MAXCPUS_CL, CONFIG_NR_CPUS);
> >
> > The evaluation of the firmware should not mark CPUs present which are
> > actually not. ACPI gives you that information. See:
> >
> > 5.2.12.14 GIC CPU Interface (GICC) Structure
> >
> > in the ACPI spec. That has two related bits:
> >
> > Enabled:
> >
> > If this bit is set, the processor is ready for use. If this bit is
> > clear and the Online Capable bit is set, the system supports enabling
> > this processor during OS runtime. If this bit is clear and the Online
> > Capable bit is also clear, this processor is un- usable, and the
> > operating system support will not attempt to use it.
> >
> > Online Capable:
> >
> > The information conveyed by this bit depends on the value of the
> > Enabled bit. If the Enabled bit is set, this bit is reserved and must
> > be zero. Otherwise, if this bit is set, the system supports enabling
> > this processor later during OS runtime
> >
> > So the combination of those gives you the right answer:
> >
> > Enabled Online
> > Capable
> > 0 0 Not present, not possible
> > 0 1 Not present, but possible to "hotplug" layter
> > 1 0 Present
> > 1 1 Invalid
>
> On x86, it seems that all CPUs with the ACPI_MADT_ENABLED bit set will
> be marked as present.
>
> acpi_parse_x2apic()
> -> enabled = processor->lapic_flags & ACPI_MADT_ENABLED
> -> topology_register_apic(enabled)
> -> topo_register_apic(enabled)
> -> set_cpu_present(cpu, true)
Yes but arm64 marks all CPUs present even if !ACPI_MADT_ENABLED as we
don't have the notion of hardware CPU hotplug.
I need to dig some more into the original vCPU hotplug support and why
we ended up with all CPUs marked as present even if not calling
register_cpu():
https://lore.kernel.org/linux-arm-kernel/20240529133446.28446-1-Jonathan.Cameron@huawei.com/
What's the MADT GICC provided by qemu with "-smp cpus=4,maxcpus=8"? If
it says Enabled for the first 4 and Online Capable for the rest, maybe
we can try something like below:
----------------------8<-----------------
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 5891f92c2035..681aa2bbc399 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -448,12 +448,14 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 apci_id,
return *pcpu;
}
+ set_cpu_present(*pcpu, true);
return 0;
}
EXPORT_SYMBOL(acpi_map_cpu);
int acpi_unmap_cpu(int cpu)
{
+ set_cpu_present(cpu, false);
return 0;
}
EXPORT_SYMBOL(acpi_unmap_cpu);
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1aa324104afb..6421027669fc 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -566,6 +566,11 @@ struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu)
}
EXPORT_SYMBOL_GPL(acpi_cpu_get_madt_gicc);
+static bool acpi_cpu_is_present(int cpu)
+{
+ return acpi_cpu_get_madt_gicc(cpu)->flags & ACPI_MADT_ENABLED;
+}
+
/*
* acpi_map_gic_cpu_interface - parse processor MADT entry
*
@@ -670,6 +675,11 @@ static void __init acpi_parse_and_init_cpus(void)
early_map_cpu_to_node(i, acpi_numa_get_nid(i));
}
#else
+static bool acpi_cpu_is_present(int cpu)
+{
+ return false;
+}
+
#define acpi_parse_and_init_cpus(...) do { } while (0)
#endif
@@ -808,7 +818,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
if (err)
continue;
- set_cpu_present(cpu, true);
+ if (acpi_disabled || acpi_cpu_is_present(cpu))
+ set_cpu_present(cpu, true);
numa_store_cpu_info(cpu);
}
}
next prev parent reply other threads:[~2026-04-23 20:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 7:55 [PATCH] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable() Jinjie Ruan
2026-04-18 11:55 ` Catalin Marinas
2026-04-18 15:05 ` Catalin Marinas
2026-04-20 1:29 ` Jinjie Ruan
2026-04-23 12:46 ` Jinjie Ruan
2026-04-23 10:08 ` Thomas Gleixner
2026-04-23 12:32 ` Jinjie Ruan
2026-04-23 20:11 ` Catalin Marinas [this message]
2026-04-24 1:56 ` Jinjie Ruan
2026-04-24 2:47 ` Jinjie Ruan
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=aep85G05D3TM9uj2@arm.com \
--to=catalin.marinas@arm.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=dietmar.eggemann@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=ruanjinjie@huawei.com \
--cc=sudeep.holla@kernel.org \
--cc=tglx@kernel.org \
--cc=yangyicong@hisilicon.com \
/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