linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Christoffer Dall <cdall@cs.columbia.edu>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>
Subject: Re: linux-next: manual merge of the kvm-arm tree with the arm64 tree
Date: Mon, 19 Feb 2024 15:22:14 +0000	[thread overview]
Message-ID: <86bk8c4gyh.wl-maz@kernel.org> (raw)
In-Reply-To: <ZdNGGrUDWfvqCudV@arm.com>

On Mon, 19 Feb 2024 12:14:18 +0000,
Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> On Mon, Feb 19, 2024 at 01:58:05PM +1100, Stephen Rothwell wrote:
> > diff --cc arch/arm64/kernel/cpufeature.c
> > index 0be9296e9253,f309fd542c20..000000000000
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@@ -721,13 -754,12 +756,14 @@@ static const struct __ftr_reg_entry 
> >   			       &id_aa64isar2_override),
> >   
> >   	/* Op1 = 0, CRn = 0, CRm = 7 */
> >  -	ARM64_FTR_REG(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0),
> >  +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR0_EL1, ftr_id_aa64mmfr0,
> >  +			       &id_aa64mmfr0_override),
> >   	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR1_EL1, ftr_id_aa64mmfr1,
> >   			       &id_aa64mmfr1_override),
> >  -	ARM64_FTR_REG(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2),
> >  +	ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64MMFR2_EL1, ftr_id_aa64mmfr2,
> >  +			       &id_aa64mmfr2_override),
> >   	ARM64_FTR_REG(SYS_ID_AA64MMFR3_EL1, ftr_id_aa64mmfr3),
> > + 	ARM64_FTR_REG(SYS_ID_AA64MMFR4_EL1, ftr_id_aa64mmfr4),
> >   
> >   	/* Op1 = 1, CRn = 0, CRm = 0 */
> >   	ARM64_FTR_REG(SYS_GMID_EL1, ftr_gmid),
> > @@@ -2701,33 -2817,13 +2779,40 @@@ static const struct arm64_cpu_capabilit
> >   		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> >   		.matches = has_lpa2,
> >   	},
> >  +#ifdef CONFIG_ARM64_VA_BITS_52
> >  +	{
> >  +		.capability = ARM64_HAS_VA52,
> >  +		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
> >  +		.matches = has_cpuid_feature,
> >  +		.field_width = 4,
> >  +#ifdef CONFIG_ARM64_64K_PAGES
> >  +		.desc = "52-bit Virtual Addressing (LVA)",
> >  +		.sign = FTR_SIGNED,
> >  +		.sys_reg = SYS_ID_AA64MMFR2_EL1,
> >  +		.field_pos = ID_AA64MMFR2_EL1_VARange_SHIFT,
> >  +		.min_field_value = ID_AA64MMFR2_EL1_VARange_52,
> >  +#else
> >  +		.desc = "52-bit Virtual Addressing (LPA2)",
> >  +		.sys_reg = SYS_ID_AA64MMFR0_EL1,
> >  +#ifdef CONFIG_ARM64_4K_PAGES
> >  +		.sign = FTR_SIGNED,
> >  +		.field_pos = ID_AA64MMFR0_EL1_TGRAN4_SHIFT,
> >  +		.min_field_value = ID_AA64MMFR0_EL1_TGRAN4_52_BIT,
> >  +#else
> >  +		.sign = FTR_UNSIGNED,
> >  +		.field_pos = ID_AA64MMFR0_EL1_TGRAN16_SHIFT,
> >  +		.min_field_value = ID_AA64MMFR0_EL1_TGRAN16_52_BIT,
> >  +#endif
> >  +#endif
> >  +	},
> >  +#endif
> > + 	{
> > + 		.desc = "NV1",
> > + 		.capability = ARM64_HAS_HCR_NV1,
> > + 		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > + 		.matches = has_nv1,
> > + 		ARM64_CPUID_FIELDS_NEG(ID_AA64MMFR4_EL1, E2H0, NI_NV1)
> > + 	},
> >   	{},
> >   };
> 
> Thanks Stephen. It looks fine.

Actually, it breaks 52bit support in a "subtle" way (multiple reports
on the list and IRC, all pointing to failures on QEMU). The KVM tree
adds support for feature ranges, which this code is totally unaware
of, and only provides the min value and not the max. Things go wrong
from there.

I propose to fix it like below, which makes it robust against the KVM
changes (patch applies to arm64/for-next/core). I have tested it in
combination with kvmarm/next, with 4kB and 16kB (LVA2), as well as
64kB (LVA).

Thanks,

	M.

From f24638a5f41424faf47f3d9035e6dcbd3800fcb6 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <maz@kernel.org>
Date: Mon, 19 Feb 2024 15:13:22 +0000
Subject: [PATCH] arm64: Use Signed/Unsigned enums for TGRAN{4,16,64} and
 VARange

Open-coding the feature matching parameters for LVA/LVA2 leads to
issues with upcoming changes to the cpufeature code.

By making TGRAN{4,16,64} and VARange signed/unsigned as per the
architecture, we can use the existing macros, making the feature
match robust against those changes.

Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 arch/arm64/kernel/cpufeature.c | 15 +++------------
 arch/arm64/tools/sysreg        |  8 ++++----
 2 files changed, 7 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 8f9665e8774b..2119e9dd0c4e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2791,24 +2791,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		.capability = ARM64_HAS_VA52,
 		.type = ARM64_CPUCAP_BOOT_CPU_FEATURE,
 		.matches = has_cpuid_feature,
-		.field_width = 4,
 #ifdef CONFIG_ARM64_64K_PAGES
 		.desc = "52-bit Virtual Addressing (LVA)",
-		.sign = FTR_SIGNED,
-		.sys_reg = SYS_ID_AA64MMFR2_EL1,
-		.field_pos = ID_AA64MMFR2_EL1_VARange_SHIFT,
-		.min_field_value = ID_AA64MMFR2_EL1_VARange_52,
+		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, VARange, 52)
 #else
 		.desc = "52-bit Virtual Addressing (LPA2)",
-		.sys_reg = SYS_ID_AA64MMFR0_EL1,
 #ifdef CONFIG_ARM64_4K_PAGES
-		.sign = FTR_SIGNED,
-		.field_pos = ID_AA64MMFR0_EL1_TGRAN4_SHIFT,
-		.min_field_value = ID_AA64MMFR0_EL1_TGRAN4_52_BIT,
+		ARM64_CPUID_FIELDS(ID_AA64MMFR0_EL1, TGRAN4, 52_BIT)
 #else
-		.sign = FTR_UNSIGNED,
-		.field_pos = ID_AA64MMFR0_EL1_TGRAN16_SHIFT,
-		.min_field_value = ID_AA64MMFR0_EL1_TGRAN16_52_BIT,
+		ARM64_CPUID_FIELDS(ID_AA64MMFR0_EL1, TGRAN16, 52_BIT)
 #endif
 #endif
 	},
diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index fa3fe0856880..670a33fca3bc 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -1540,16 +1540,16 @@ Enum	35:32	TGRAN16_2
 	0b0010	IMP
 	0b0011	52_BIT
 EndEnum
-Enum	31:28	TGRAN4
+SignedEnum	31:28	TGRAN4
 	0b0000	IMP
 	0b0001	52_BIT
 	0b1111	NI
 EndEnum
-Enum	27:24	TGRAN64
+SignedEnum	27:24	TGRAN64
 	0b0000	IMP
 	0b1111	NI
 EndEnum
-Enum	23:20	TGRAN16
+UnsignedEnum	23:20	TGRAN16
 	0b0000	NI
 	0b0001	IMP
 	0b0010	52_BIT
@@ -1697,7 +1697,7 @@ Enum	23:20	CCIDX
 	0b0000	32
 	0b0001	64
 EndEnum
-Enum	19:16	VARange
+UnsignedEnum	19:16	VARange
 	0b0000	48
 	0b0001	52
 EndEnum
-- 
2.39.2


-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2024-02-19 15:22 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-19  2:58 linux-next: manual merge of the kvm-arm tree with the arm64 tree Stephen Rothwell
2024-02-19 12:14 ` Catalin Marinas
2024-02-19 15:22   ` Marc Zyngier [this message]
2024-02-19 15:35     ` Mark Rutland
2024-02-19 15:43     ` Ard Biesheuvel
2024-02-19 16:49     ` Catalin Marinas
  -- strict thread matches above, loose matches on Subject: below --
2024-03-08  1:54 Stephen Rothwell
2024-03-08  6:25 ` Oliver Upton
2024-03-08 12:30   ` Catalin Marinas
2024-03-08  1:47 Stephen Rothwell
2024-02-20  2:21 Stephen Rothwell
2023-10-24  2:28 Stephen Rothwell
2023-10-24  6:49 ` Oliver Upton
2023-10-17  1:30 Stephen Rothwell
2023-10-17 11:13 ` Catalin Marinas
2023-10-18 23:02   ` Oliver Upton
2023-11-01  2:36 ` Stephen Rothwell
2023-06-15  2:45 Stephen Rothwell
2023-06-15  7:37 ` Oliver Upton
2023-06-15  8:32   ` Catalin Marinas
2023-06-15  2:22 Stephen Rothwell
2023-06-15  7:14 ` Catalin Marinas
2023-07-03  0:50 ` Stephen Rothwell
2023-06-06  1:49 Stephen Rothwell
2023-06-06  9:20 ` Catalin Marinas
2023-06-07  1:05 ` Stephen Rothwell
2023-06-07  5:33   ` Oliver Upton
2023-06-07  8:45     ` Catalin Marinas
2023-02-06  1:44 Stephen Rothwell
2023-02-06  4:21 ` Stephen Rothwell
2023-02-06  8:37 ` Marc Zyngier
2023-02-06  8:43   ` Marc Zyngier
2022-09-19  4:05 Stephen Rothwell
2022-09-19  9:04 ` Marc Zyngier
2022-09-23 10:26   ` Catalin Marinas
2022-05-04  4:35 Stephen Rothwell
2022-05-04  7:06 ` Marc Zyngier
2022-05-04  8:08   ` Catalin Marinas
2022-05-23  6:36 ` Stephen Rothwell
2021-08-19  4:05 Stephen Rothwell
2021-08-20  9:27 ` Catalin Marinas
2021-08-12  3:33 Stephen Rothwell
2021-06-23  5:58 Stephen Rothwell
2021-04-13  5:43 Stephen Rothwell
2021-04-13 11:21 ` Ard Biesheuvel
2021-01-27  5:24 Stephen Rothwell
2020-12-04  5:44 Stephen Rothwell
2020-12-04 11:12 ` Marc Zyngier
2020-12-04  5:17 Stephen Rothwell
2020-09-30  6:26 Stephen Rothwell
2020-05-29  7:00 Stephen Rothwell
2019-07-08  7:24 Stephen Rothwell
2018-10-04  4:22 Stephen Rothwell
2018-10-04  4:07 Stephen Rothwell
2018-07-23  4:46 Stephen Rothwell
2018-07-23 10:45 ` Marc Zyngier
2018-08-16  0:15 ` Stephen Rothwell
2018-08-17  8:32   ` Paolo Bonzini
2018-08-17  9:33     ` Marc Zyngier
2018-06-01  6:23 Stephen Rothwell
2018-06-01  8:23 ` Marc Zyngier
2018-06-01  6:13 Stephen Rothwell
2018-03-28  5:05 Stephen Rothwell
2018-03-29  5:16 ` Stephen Rothwell
2018-03-28  5:00 Stephen Rothwell
2018-03-28 11:53 ` Will Deacon
2017-08-25  4:57 Stephen Rothwell
2017-08-25  8:11 ` Marc Zyngier
2017-08-25  8:44   ` Christoffer Dall
2016-02-29  5:18 Stephen Rothwell
2016-02-24  2:38 Stephen Rothwell
2016-02-22  2:33 Stephen Rothwell
2016-02-22  9:26 ` Catalin Marinas
2016-02-22  2:28 Stephen Rothwell
2016-02-22  9:24 ` Catalin Marinas
2016-02-12  2:26 Stephen Rothwell
2015-01-22  5:07 Stephen Rothwell
2015-01-22  8:51 ` Marc Zyngier
2015-01-22 10:29   ` Mark Rutland
2015-01-22 23:05     ` Stephen Rothwell
2015-01-23  1:36   ` Wei Huang
2015-01-23 11:53   ` Christoffer Dall
2015-01-22  5:06 Stephen Rothwell

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=86bk8c4gyh.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=cdall@cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=oliver.upton@linux.dev \
    --cc=sfr@canb.auug.org.au \
    --cc=will@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).