[PATCH v3 08/15] KVM: arm64: Add feature register flag definitions
Fuad Tabba
tabba at google.com
Thu Aug 12 02:21:01 PDT 2021
Hi Will,
On Thu, Aug 12, 2021 at 10:59 AM Will Deacon <will at kernel.org> wrote:
>
> On Mon, Jul 19, 2021 at 05:03:39PM +0100, Fuad Tabba wrote:
> > Add feature register flag definitions to clarify which features
> > might be supported.
> >
> > Consolidate the various ID_AA64PFR0_ELx flags for all ELs.
> >
> > No functional change intended.
> >
> > Signed-off-by: Fuad Tabba <tabba at google.com>
> > ---
> > arch/arm64/include/asm/cpufeature.h | 4 ++--
> > arch/arm64/include/asm/sysreg.h | 12 ++++++++----
> > arch/arm64/kernel/cpufeature.c | 8 ++++----
> > 3 files changed, 14 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> > index 9bb9d11750d7..b7d9bb17908d 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -602,14 +602,14 @@ static inline bool id_aa64pfr0_32bit_el1(u64 pfr0)
> > {
> > u32 val = cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_EL1_SHIFT);
> >
> > - return val == ID_AA64PFR0_EL1_32BIT_64BIT;
> > + return val == ID_AA64PFR0_ELx_32BIT_64BIT;
> > }
> >
> > static inline bool id_aa64pfr0_32bit_el0(u64 pfr0)
> > {
> > u32 val = cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_EL0_SHIFT);
> >
> > - return val == ID_AA64PFR0_EL0_32BIT_64BIT;
> > + return val == ID_AA64PFR0_ELx_32BIT_64BIT;
> > }
> >
> > static inline bool id_aa64pfr0_sve(u64 pfr0)
> > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> > index 326f49e7bd42..0b773037251c 100644
> > --- a/arch/arm64/include/asm/sysreg.h
> > +++ b/arch/arm64/include/asm/sysreg.h
> > @@ -784,14 +784,13 @@
> > #define ID_AA64PFR0_AMU 0x1
> > #define ID_AA64PFR0_SVE 0x1
> > #define ID_AA64PFR0_RAS_V1 0x1
> > +#define ID_AA64PFR0_RAS_ANY 0xf
>
> This doesn't correspond to an architectural definition afaict: the manual
> says that any values other than 0, 1 or 2 are "reserved" so we should avoid
> defining our own definitions here.
I'll add a ID_AA64PFR0_RAS_V2 definition in that case and use it for
the checking later. That would achieve the same goal and I wouldn't be
adding definitions to the reserved area.
Cheers,
/fuad
More information about the linux-arm-kernel
mailing list