public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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);
 	}
 }

  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