From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D9F0BC4345F for ; Fri, 12 Apr 2024 23:24:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=L2+eT9qu0MVC/mSlULHXT997lECEZqnzoh/lKjRhh8E=; b=NMrJI0thvPyNb+ VM/q/+80ofMt5ZfpSSpfPAGVPFRn64gqOjnJwfSnZrufQO5y9u02EXtZR5TZehaWU8ztmzy18vZ5/ bAjYgI+6Jdy2gyhEVpPooZvPY+cNR5bmGvto1LPhAItEV5srJnAeYNTroOyqoEtmfC3SGuIT2rbw1 9mI37SvLAz6Fj20CPSO8ux5yq4ExMmjMlOKV80vDl3t/g0FeLLodCgYAwhPvnQCZ7NyHuVO2YtU/w 6P7lu3YfZdP4CaeXOfBwpUq/PJqLOCHap9f0zaowpdrTuhj2ASmhQssxDqWjp3ICyStA1ke1xdzqq a1SH32BF5yNp7iRxzo4Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rvQFT-00000001f7p-0mV9; Fri, 12 Apr 2024 23:23:59 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rvQFN-00000001f62-1Qoy for linux-arm-kernel@lists.infradead.org; Fri, 12 Apr 2024 23:23:57 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1712964230; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=T5xu2FVtNRnOIqknb2Ux4D1eBvHtL7IvYUAUi+UDnWI=; b=tW6ap+zQjCfPb0Iu5NRfFG9LND9NrDkPfEJWzzMV7FCLTiO/67DEBwqkhnToa6FAcP2EMM 6MUD2W5m6nuwV2lpFNG3h+9zzeXDVM+p+g58Cp/G+e4GRZcfa5YXlQCXsvhowZhIeayP0F mX0bfZnV7zatQ27FSiwCVDCNzdKFDc9OqpMidB2qf2Cpn4vHrQKR1CDd5Jo0Vu7BskZTIr zk34+SsJ8yxAruaTIUuw2IA0vIdHj/NMRshMO3Ypq0Afb5kNOeHECSYmsLQEyGEwXiqLV8 1HqLCmjoZ7R9k59MXcM+5pSKlvvx5MjGxECT/fcNGhgdh8TjLYqmzvmpqlulZQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1712964230; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=T5xu2FVtNRnOIqknb2Ux4D1eBvHtL7IvYUAUi+UDnWI=; b=C6bVqxHCPN+wfRrnH1w7K16dZrgwWFLb9vxFt3+t2PJptgUt5gh64ablXIU/tU1hN5ia0j DVRgHQA0LBs0mhCA== To: "Russell King (Oracle)" Cc: "Rafael J. Wysocki" , Jonathan Cameron , linux-pm@vger.kernel.org, loongarch@lists.linux.dev, linux-acpi@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, x86@kernel.org, Miguel Luis , James Morse , Salil Mehta , Jean-Philippe Brucker , Catalin Marinas , Will Deacon , linuxarm@huawei.com, justin.he@arm.com, jianyong.wu@arm.com Subject: Re: [PATCH v5 03/18] ACPI: processor: Register deferred CPUs from acpi_processor_get_info() In-Reply-To: References: <20240412143719.11398-1-Jonathan.Cameron@huawei.com> <20240412143719.11398-4-Jonathan.Cameron@huawei.com> <87bk6ez4hj.ffs@tglx> Date: Sat, 13 Apr 2024 01:23:48 +0200 Message-ID: <878r1iyxkr.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240412_162353_790066_A21B512C X-CRM114-Status: GOOD ( 32.80 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Russell! On Fri, Apr 12 2024 at 22:52, Russell King (Oracle) wrote: > On Fri, Apr 12, 2024 at 10:54:32PM +0200, Thomas Gleixner wrote: >> > As for the cpu locking, I couldn't find anything in arch_register_cpu() >> > that depends on the cpu_maps_update stuff nor needs the cpus_write_lock >> > being taken - so I've no idea why the "make_present" case takes these >> > locks. >> >> Anything which updates a CPU mask, e.g. cpu_present_mask, after early >> boot must hold the appropriate write locks. Otherwise it would be >> possible to online a CPU which just got marked present, but the >> registration has not completed yet. > > Yes. As far as I've been able to determine, arch_register_cpu() > doesn't manipulate any of the CPU masks. All it seems to be doing > is initialising the struct cpu, registering the embedded struct > device, and setting up the sysfs links to its NUMA node. > > There is nothing obvious in there which manipulates any CPU masks, and > this is rather my fundamental point when I said "I couldn't find > anything in arch_register_cpu() that depends on ...". > > If there is something, then comments in the code would be a useful aid > because it's highly non-obvious where such a manipulation is located, > and hence why the locks are necessary. acpi_processor_hotadd_init() ... acpi_map_cpu(pr->handle, pr->phys_id, pr->acpi_id, &pr->id); That ends up in fiddling with cpu_present_mask. I grant you that arch_register_cpu() is not, but it might rely on the external locking too. I could not be bothered to figure that out. >> Define "real hotplug" :) >> >> Real physical hotplug does not really exist. That's at least true for >> x86, where the physical hotplug support was chased for a while, but >> never ended up in production. >> >> Though virtualization happily jumped on it to hot add/remove CPUs >> to/from a guest. >> >> There are limitations to this and we learned it the hard way on X86. At >> the end we came up with the following restrictions: >> >> 1) All possible CPUs have to be advertised at boot time via firmware >> (ACPI/DT/whatever) independent of them being present at boot time >> or not. >> >> That guarantees proper sizing and ensures that associations >> between hardware entities and software representations and the >> resulting topology are stable for the lifetime of a system. >> >> It is really required to know the full topology of the system at >> boot time especially with hybrid CPUs where some of the cores >> have hyperthreading and the others do not. >> >> >> 2) Hot add can only mark an already registered (possible) CPU >> present. Adding non-registered CPUs after boot is not possible. >> >> The CPU must have been registered in #1 already to ensure that >> the system topology does not suddenly change in an incompatible >> way at run-time. >> >> The same restriction would apply to real physical hotplug. I don't think >> that's any different for ARM64 or any other architecture. > > This makes me wonder whether the Arm64 has been barking up the wrong > tree then, and whether the whole "present" vs "enabled" thing comes > from a misunderstanding as far as a CPU goes. > > However, there is a big difference between the two. On x86, a processor > is just a processor. On Arm64, a "processor" is a slice of the system > (includes the interrupt controller, PMUs etc) and we must enumerate > those even when the processor itself is not enabled. This is the whole > reason there's a difference between "present" and "enabled" and why > there's a difference between x86 cpu hotplug and arm64 cpu hotplug. > The processor never actually goes away in arm64, it's just prevented > from being used. It's the same on X86 at least in the physical world. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel