Received: by 2002:ab2:1347:0:b0:1f4:ac9d:b246 with SMTP id g7csp330139lqg; Thu, 11 Apr 2024 04:35:45 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVB0fm3K5M9T79GbqBAxLJoSP5VCeFKB+M89Z+JPZQ4hauYEWQXo7xKtwSUf3zfyrnkgkpumcd8+h3O5OE1nF7iiWWX24PDenAFgZEbOg== X-Google-Smtp-Source: AGHT+IGhDZVFm8YrBlgeTA0yg9QEpskLp1JaSv12mw045mw0/04v/5QLRkOYVWd4z8lgZ2zyk77r X-Received: by 2002:a50:9ea2:0:b0:56c:3dfb:a1f5 with SMTP id a31-20020a509ea2000000b0056c3dfba1f5mr3781083edf.22.1712835345383; Thu, 11 Apr 2024 04:35:45 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712835345; cv=pass; d=google.com; s=arc-20160816; b=px0iKkP+3ZuvhQcoU7mtyOz9A557smT3VIXm+GjZBFJpnoi/iVMAUqrAmLeNwhLMha OgQqR73j302fxDAqPg+Gjfv4lvaFk8a9rIDnOJe+bYne0Cb092QFyX7YjeOlJxP/qE6n DBYRKwU0oP7j8n7Ku+wvcqfGLw/k31kSoYNqafOaeMZr4R7xLhhhEVvFCnMgALzTXiGo odoRna4VRP4wyCbLyUwE4EJsrEAIjfJhT/chUzYB+XipsBHwlTtucUxRngEieDfCcj8b dHNKfdE3X8FEh8Sv+2b3onX54NBxVRMDNzU/UwWEr1ujmYDROviC3g5A6AaObW8rbH8h GaTg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:organization:references :in-reply-to:message-id:subject:cc:to:from:date; bh=hpSMwI3rOxisKAExAP7xsK2MqZb/eBqfEPWcdpC2h+0=; fh=lLFzLxnA2bTSDJOAN2M46KTvy3hB4Ry+sZ6lfaHI8gY=; b=j9Qlu/NuwbF6zu/BDmUtKJ7Y0e+xIprtFow076LIZZTcKwIRmVsFHbIn2YDywg/DQF LPcw3aZOQMLoFzCTXeRpWiGM3SwKjzQjrt4OfTUA/SSronOMylqYNdx+rWtHWI2ttB9m e6zn2aBCan4+pym6IP1xnnsYsJDicGaoDa2SEdyRfmQ2Ve4ZF33/55BXfQ6jRrosVGY/ ZkDQU67h7KivK4u/duk6k3HXz0LN2tSDAVDfbeAlyxkF9VvmxOCbdkTwv2WUcVAy/07j JDLsyrheNlDqKVrqyJjNw67ZuwiLLYifutjNoF/vulh5fJRkM1JxiMZUFs3+4lyJQkKC qfRw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-140345-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-140345-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id h1-20020a056402280100b0056e310e663asi713839ede.640.2024.04.11.04.35.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Apr 2024 04:35:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-140345-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-140345-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-140345-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id E2ED41F228A4 for ; Thu, 11 Apr 2024 11:35:44 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8662B149C7E; Thu, 11 Apr 2024 11:35:31 +0000 (UTC) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A53A5145B08; Thu, 11 Apr 2024 11:35:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.176.79.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712835330; cv=none; b=Hbehevc1NMptQTQf3LGreMFahzHdL70Wkk+NdrRQmXW1AQ+3VBK/iDa3ippdLxIdYHkGRL3WZxoSvRoU4WD8b/H68y4oGgGUkTIWAgAvPYrd5W18Icvr3CkCTXG9pxgQgj6gPjUKwMsH6KXMG15Xk0S/N1Vb/Fy0bFjCrFrhLTI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712835330; c=relaxed/simple; bh=2QoydNUa8ohr5BSqBTKFBG9DaUQmDb6Pl/IqqSheoek=; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Siggv+M5vIGlvTY4z9aEuhxh2gsnyc2VMBeiz7H9duYZ4+dwfLobYhJl4M5uqNNyFq3pQoQvFdnjqlvhXVpG4ttlA1Gn82ZGX1E4NnzfNpsVjZgXwZDqTaPkt4GgbHQ8Kp2HKR49SqpkZ8a/Li53/NzSKhFymZtnxWE/sevlz80= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=185.176.79.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VFcyt3VLqz6JB2Q; Thu, 11 Apr 2024 19:33:42 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id 09DC51400E7; Thu, 11 Apr 2024 19:35:25 +0800 (CST) Received: from localhost (10.122.247.231) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 11 Apr 2024 12:35:24 +0100 Date: Thu, 11 Apr 2024 12:35:23 +0100 From: Jonathan Cameron To: "Russell King (Oracle)" CC: , , , , , , , , , , , , , , Salil Mehta , Jean-Philippe Brucker , , , James Morse , "Rafael J. Wysocki" , Miguel Luis Subject: Re: [PATCH RFC v4 12/15] arm64: psci: Ignore DENIED CPUs Message-ID: <20240411123523.0000487a@huawei.com> In-Reply-To: References: Organization: Huawei Technologies R&D (UK) Ltd. X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; x86_64-w64-mingw32) 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-Transfer-Encoding: 7bit X-ClientProxiedBy: lhrpeml100005.china.huawei.com (7.191.160.25) To lhrpeml500005.china.huawei.com (7.191.163.240) On Wed, 31 Jan 2024 16:50:38 +0000 Russell King (Oracle) wrote: > From: Jean-Philippe Brucker > > When a CPU is marked as disabled, but online capable in the MADT, PSCI > applies some firmware policy to control when it can be brought online. > PSCI returns DENIED to a CPU_ON request if this is not currently > permitted. The OS can learn the current policy from the _STA enabled bit. > > Handle the PSCI DENIED return code gracefully instead of printing an > error. > > See https://developer.arm.com/documentation/den0022/f/?lang=en page 58. > > Signed-off-by: Jean-Philippe Brucker > [ morse: Rewrote commit message ] > Signed-off-by: James Morse > Tested-by: Miguel Luis > Tested-by: Vishnu Pajjuri > Tested-by: Jianyong Wu > Reviewed-by: Jonathan Cameron > Signed-off-by: Russell King (Oracle) > --- This change to return failure from __cpu_up in non error cases exposes an possible issue with cpu_up() in kernel/cpu.c in that it brings the numa node before we try (and fail) to bring up CPUs that may be denied. We could try offlining the numa node on error, or just register it later. Currently I'm testing this change which I think is harmless for cases that don't fail the cpu_up() For the cpu hotplug path note the node only comes online wiht the cpu online, not the earlier hotplug. Reasonable given there is nothing online in the node before that point. diff --git a/kernel/cpu.c b/kernel/cpu.c index 537099bf5d02..a4730396ccea 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -1742,10 +1742,6 @@ static int cpu_up(unsigned int cpu, enum cpuhp_state target) return -EINVAL; } - err = try_online_node(cpu_to_node(cpu)); - if (err) - return err; - cpu_maps_update_begin(); if (cpu_hotplug_disabled) { @@ -1760,7 +1756,10 @@ static int cpu_up(unsigned int cpu, enum cpuhp_state target) err = _cpu_up(cpu, 0, target); out: cpu_maps_update_done(); - return err; + if (err) + return err; + + return try_online_node(cpu_to_node(cpu)); } There is a kicker in the remove path where currently check_cpu_on_node() checks for_each_present_cpu() whereas to work for us we need to use for_each_online_cpu() or the node is never removed. Now my current view is that we should only show nodes in /sys/bus/nodes/devices/ if there is a CPU online (assuming no other reasons the node should be online such as memory). That's easy enough to make work but all I'm really learning is that the semantics of what is an online form a node point of view is not consistent. Fixing this will create a minor change on x86 but does anyone really care about what happens in the offline path wrt to 'when' the node disappears? I think the corner case is. 1. Add 2 CPUs (A, B) in a CPU only node. 2. Online CPU A - this brings /sys/bus/devices/nodeX online 3. Remove CPU A - no effect because the check for try_remove is on presence and CPU B is still present. 4. Online CPU B - no change. 5. Offline CPU B - no change. 4. Remove CPU B - /sys/bus/device/nodeX offline (disappears) To make it work on arm64 where we never make CPUs not present. 1. Add 2 CPUs (A, B) in a CPU only node. 2. Online CPU A - this brings /sys/bus/devices/nodeX online 3. Remove CPU A - /sys/bus/devices/nodeX offline (disappears) 4. Online CPU B - this brings /sys/bus/device/nodeX online 5. Offline CPU B - no change (node updates only happen in hotplug code) 6. Remove CPU B - /sys/bus/device/nodeX offline (disappears). Step 5 may seem weird but I think we can't mess with nodes there because userspace may well rely on them still being around for some reason (it's a much more common situation). My assumption is that step3 removing the node isn't going to hurt anyone? If no one shouts, i'll go ahead with rolling a v5 patch set where this is done. Jonathan > Changes since RFC v2 > * Add specification reference > * Use EPERM rather than EPROBE_DEFER > Changes since RFC v3: > * Use EPERM everywhere > * Drop unnecessary changes to drivers/firmware/psci/psci.c > --- > arch/arm64/kernel/psci.c | 2 +- > arch/arm64/kernel/smp.c | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c > index 29a8e444db83..fabd732d0a2d 100644 > --- a/arch/arm64/kernel/psci.c > +++ b/arch/arm64/kernel/psci.c > @@ -40,7 +40,7 @@ static int cpu_psci_cpu_boot(unsigned int cpu) > { > phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry); > int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry); > - if (err) > + if (err && err != -EPERM) > pr_err("failed to boot CPU%d (%d)\n", cpu, err); > > return err; > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c > index 4ced34f62dab..dc0e0b3ec2d4 100644 > --- a/arch/arm64/kernel/smp.c > +++ b/arch/arm64/kernel/smp.c > @@ -132,7 +132,8 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle) > /* Now bring the CPU into our world */ > ret = boot_secondary(cpu, idle); > if (ret) { > - pr_err("CPU%u: failed to boot: %d\n", cpu, ret); > + if (ret != -EPERM) > + pr_err("CPU%u: failed to boot: %d\n", cpu, ret); > return ret; > } >