From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 AB1B91DDEA for ; Sat, 4 Jan 2025 23:18:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736032723; cv=none; b=dKXjyIKoXkU1AfylM5cMenR1dM3ihoEwWZcAaiXRfYakt4ngPKakUZF/hQFBhwbduTfJDsPvO70AsTdZ0PPpBlHK5JbtJos89Y+RqSedxPIMHQvH8Vr52j93lWPsChuMHBC9Kl8uVdJV+XhSxCp4mB7V+Qqgu/8/AftO4mjUZbI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736032723; c=relaxed/simple; bh=2IwbPQAeICFB7CzXnKOfstJGTRv78J7FIK50ptpPlIE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=I4HBMS7EAaMTv9SkcPHwU1hcODblXMXiBMd3dqI5laH146lbQ4POVyiy9n4xXY/WpvGdeAwEHLlR1BhjmJnoTsnpL98S+sSoDkb+Vpeq0KamLnvyQjmP52XHZd0x8CMAcb5KO8fqvrt18/baiJI7qdXAGruuoUAmr+0cmfs/Keg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NX0KxrFr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NX0KxrFr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BEB71C4CED1; Sat, 4 Jan 2025 23:18:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736032723; bh=2IwbPQAeICFB7CzXnKOfstJGTRv78J7FIK50ptpPlIE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NX0KxrFr+bpKFLNjCmR1mah3PSVZaft8Fn2fGjuhkWXR9Im+S+OaiBvRApt0XFxzw /X5BZd8OlHoc/TbvUrLyiXdxPq9YVWhkoLQxoHWzfVc/T93PfiPyKtMcx5L/hK3Ram E5XNnhmm2srOE2dYNgBmVzOu+eFsWLyEO5AUvLEiTmHMo/6N7DdOSQTNArBJAYjD6f ykjxsNIc8FgfryU7L2Jc1azbrm6InX9g6hVWYI1gf55jwfRSqBuhrX+XLtKvOBKlke 64TsbQwz0ftX7fObpozf9Zbv40jylsjMa5s0jWWi6yuH67Hi2roDkLcxhrVYW7kFdX V3hrEOz3ERcZw== Date: Sun, 5 Jan 2025 00:18:40 +0100 From: Frederic Weisbecker To: Will Deacon Cc: LKML , Catalin Marinas , Marc Zyngier , Oliver Upton , Ard Biesheuvel , Mark Rutland , Andrew Morton , Peter Zijlstra , Thomas Gleixner Subject: Re: [PATCH 09/19] arm64: Exclude nohz_full CPUs from 32bits el0 support Message-ID: References: <20241211154035.75565-1-frederic@kernel.org> <20241211154035.75565-10-frederic@kernel.org> <20250103152043.GA3816@willie-the-truck> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250103152043.GA3816@willie-the-truck> Le Fri, Jan 03, 2025 at 03:20:44PM +0000, Will Deacon a écrit : > On Wed, Dec 11, 2024 at 04:40:22PM +0100, Frederic Weisbecker wrote: > > +NOHZ FULL > > +-------- > > + > > +Nohz full CPUs are not a desirable fallback target to run 32bits el0 > > +applications. If present, a set of housekeeping CPUs that can do > > +the job instead is preferred. Otherwise 32-bit EL0 is not supported. > > +Should the need arise, appropriate support can be introduced in the > > +future. > > I think we can probably word this slightly better. How about something > more along these lines? > > To avoid perturbing an adaptive-ticks CPU (specified using > ``nohz_full=``) when a 32-bit task is forcefully migrated, these CPUs > are treated as 64-bit-only when support for asymmetric 32-bit systems > is enabled. Indeed! > > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > > index 6ce71f444ed8..7ce1b8ab417f 100644 > > --- a/arch/arm64/kernel/cpufeature.c > > +++ b/arch/arm64/kernel/cpufeature.c > > @@ -75,6 +75,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -3742,7 +3743,10 @@ static int enable_mismatched_32bit_el0(unsigned int cpu) > > static int lucky_winner = -1; > > > > struct cpuinfo_arm64 *info = &per_cpu(cpu_data, cpu); > > - bool cpu_32bit = id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0); > > + bool cpu_32bit = false; > > + > > + if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0) && housekeeping_cpu(cpu, HK_TYPE_TICK)) > > + cpu_32bit = true; > > I think it would be helpful to emit a diagnostic when a 32-bit CPU is > ignored because of the housekeeping check. e.g. > > > if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) { > if (!housekeeping_cpu(cpu, HK_TYPE_TICK)) > pr_info("Treating adaptive-ticks CPU %u as 64-bit only\n", cpu); > else > cpu_32bit = true; > } > > > It's a bit of a bummer that this will fire on hardware that isn't > asymmetric, but I suppose that's easily resolved by not passing the > 'allow_mismatched_32bit_el0' option in that case. Right! How is the following updated version? --- From: Frederic Weisbecker Date: Fri, 25 Oct 2024 00:12:59 +0200 Subject: [PATCH 1/2] arm64: Exclude nohz_full CPUs from 32bits el0 support Nohz full CPUs are not a desirable fallback target to run 32bits el0 applications. If present, prefer a set of housekeeping CPUs that can do the job instead. Otherwise just don't support el0 32 bits. Should the need arise, appropriate support can be introduced in the future. Suggested-by: Will Deacon Signed-off-by: Frederic Weisbecker --- Documentation/arch/arm64/asymmetric-32bit.rst | 8 ++++++++ arch/arm64/kernel/cpufeature.c | 10 +++++++++- 2 files changed, 17 insertions(+), 1 deletion(-) diff --git a/Documentation/arch/arm64/asymmetric-32bit.rst b/Documentation/arch/arm64/asymmetric-32bit.rst index 64a0b505da7d..1ca2b359a907 100644 --- a/Documentation/arch/arm64/asymmetric-32bit.rst +++ b/Documentation/arch/arm64/asymmetric-32bit.rst @@ -153,3 +153,11 @@ asymmetric system, a broken guest at EL1 could still attempt to execute mode will return to host userspace with an ``exit_reason`` of ``KVM_EXIT_FAIL_ENTRY`` and will remain non-runnable until successfully re-initialised by a subsequent ``KVM_ARM_VCPU_INIT`` operation. + +NOHZ FULL +--------- + +To avoid perturbing an adaptive-ticks CPU (specified using +``nohz_full=``) when a 32-bit task is forcefully migrated, these CPUs +are treated as 64-bit-only when support for asymmetric 32-bit systems +is enabled. diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 6ce71f444ed8..3c87659c14db 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -75,6 +75,7 @@ #include #include #include +#include #include #include @@ -3742,7 +3743,14 @@ static int enable_mismatched_32bit_el0(unsigned int cpu) static int lucky_winner = -1; struct cpuinfo_arm64 *info = &per_cpu(cpu_data, cpu); - bool cpu_32bit = id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0); + bool cpu_32bit = false; + + if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0)) { + if (!housekeeping_cpu(cpu, HK_TYPE_TICK)) + pr_info("Treating adaptive-ticks CPU %u as 64-bit only\n", cpu); + else + cpu_32bit = true; + } if (cpu_32bit) { cpumask_set_cpu(cpu, cpu_32bit_el0_mask); -- 2.46.0