From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 54EAA2D5940 for ; Thu, 23 Apr 2026 20:11:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776975084; cv=none; b=G9cw/5Rn0nnBOFqiP29H47C2mK2rZ3lIn3R27cadmUVAJnlvqSHoyS9osg8KQIezEoFW3QKQj7EhFT7OEQujxWmuGAkVMPnN5uOfbffMOrTR/i0K5/gRCJ9531YnwPkhZBwmvK4+5y5bS+lERNbkrRYWIgsmYz95O1mZA6lMNrM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776975084; c=relaxed/simple; bh=PjY9Tzmxrr+2BgE+O/ko5UVXdPmLbtgzi9wqdcok6u0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Bi2FluQTWs/BIr4ls/PcM6GGm4Y3mqwehzwflobXXuxaIWVsuVisyMisJP8Vh4xwjtOJu9V6aDsFEFgmFL3yyUsZ5pdZi3VUBZIXMOgz5xP9SBD8WUV5gdh4GHic7ExbKY3E8DU+++M9eBFCKq+amt4uuYEcK3c55cjLnn4ty9g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=l64vNcxS; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="l64vNcxS" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BB6F31BC0; Thu, 23 Apr 2026 13:11:14 -0700 (PDT) Received: from arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 015F83F641; Thu, 23 Apr 2026 13:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776975080; bh=PjY9Tzmxrr+2BgE+O/ko5UVXdPmLbtgzi9wqdcok6u0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l64vNcxScnpE4yIQKse2JJiEh8xAEijsFJ8hsy8VJ1qiCtpPv1uQZQQBZqXjpbJw/ 2L0aV0UubqZ6h9KkX2Ldf7ChbPMcN1ApUFwj4K9aKrkazoXAIZx57tFz0Z9ASZDOSS cWa2u0jDck743dWzKu1Zw9j2uytA5Z4bhDFswAvE= Date: Thu, 23 Apr 2026 21:11:16 +0100 From: Catalin Marinas To: Jinjie Ruan Cc: Thomas Gleixner , 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 , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable() Message-ID: References: <20260417075534.3745793-1-ruanjinjie@huawei.com> <87ldee0z1w.ffs@tglx> <78515da3-03a1-4fdb-a606-3fea9f4cd20b@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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); } }