Re: [PATCH v3 2/7] xen/arm: Import ID features sanitize from linux
On Wed, 25 Aug 2021, Bertrand Marquis wrote: > Import structures declared in Linux file arch/arm64/kernel/cpufeature.c > and the required types from arch/arm64/include/asm/cpufeature.h. > > Current code has been imported from Linux 5.13-rc5 (Commit ID > cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9) and copied into cpufeature.c > in arm64 code and cpufeature.h in arm64 specific headers. > > Those structure will be used to sanitize the cpu features available to > the ones availble on all cores of a system even if we are on an > heterogeneous platform (from example a big/LITTLE). > > For each feature field of all ID registers, those structures define what > is the safest value and if we can allow to have different values in > different cores. > > This patch is introducing Linux code without any changes to it. > > Signed-off-by: Bertrand Marquis Reviewed-by: Stefano Stabellini > --- > Changes in v3: none > Changes in v2: > - Move add to Makefile to following patch to allow bisection > - Remove GPL text as SPDL is there > - Re-add introduction comment from Linux Kernel file > - Rename cpusanitize.c to cpufeature.c to keep Linux file name > - Move structures imported from linux headers into a new cpufeature.h > header in asm-arm/arm64. > - Move comment about imported code origin to the file header > - Remove not needed linux function declarations instead of removing them > in the following patch > - Add original arm64_ftr_safe_value from Linux > - include kernel.h to use max() > - remove unused ftr_single32 as we will not use it > - remove ctr associated structures that we cannot use (keep the one > defining sanitization bits) > --- > xen/arch/arm/arm64/cpufeature.c| 504 + > xen/include/asm-arm/arm64/cpufeature.h | 104 + > 2 files changed, 608 insertions(+) > create mode 100644 xen/arch/arm/arm64/cpufeature.c > create mode 100644 xen/include/asm-arm/arm64/cpufeature.h > > diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c > new file mode 100644 > index 00..5777e33e5c > --- /dev/null > +++ b/xen/arch/arm/arm64/cpufeature.c > @@ -0,0 +1,504 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Contains CPU feature definitions > + * > + * The following structures have been imported directly from Linux kernel and > + * should be kept in sync. > + * The current version has been imported from arch/arm64/kernel/cpufeature.c > + * from kernel version 5.13-rc5 together with the required structures and > + * macros from arch/arm64/include/asm/cpufeature.h which are stored in > + * include/asm-arm/arm64/cpufeature.h > + * > + * Copyright (C) 2021 Arm Ltd. > + * based on code from the Linux kernel, which is: > + * Copyright (C) 2015 ARM Ltd. > + * > + * A note for the weary kernel hacker: the code here is confusing and hard to > + * follow! That's partly because it's solving a nasty problem, but also > because > + * there's a little bit of over-abstraction that tends to obscure what's > going > + * on behind a maze of helper functions and macros. > + * > + * The basic problem is that hardware folks have started gluing together CPUs > + * with distinct architectural features; in some cases even creating SoCs > where > + * user-visible instructions are available only on a subset of the available > + * cores. We try to address this by snapshotting the feature registers of the > + * boot CPU and comparing these with the feature registers of each secondary > + * CPU when bringing them up. If there is a mismatch, then we update the > + * snapshot state to indicate the lowest-common denominator of the feature, > + * known as the "safe" value. This snapshot state can be queried to view the > + * "sanitised" value of a feature register. > + * > + * The sanitised register values are used to decide which capabilities we > + * have in the system. These may be in the form of traditional "hwcaps" > + * advertised to userspace or internal "cpucaps" which are used to configure > + * things like alternative patching and static keys. While a feature mismatch > + * may result in a TAINT_CPU_OUT_OF_SPEC kernel taint, a capability mismatch > + * may prevent a CPU from being onlined at all. > + * > + * Some implementation details worth remembering: > + * > + * - Mismatched features are *always* sanitised to a "safe" value, which > + * usually indicates that the feature is not supported. > + * > + * - A mismatched feature marked with FTR_STRICT will cause a "SANITY CHECK" > + * warning when onlining an offending CPU and the kernel will be tainted > + * with TAINT_CPU_OUT_OF_SPEC. > + * > + * - Features marked as FTR_VISIBLE have their sanitised value visible to > + * userspace. FTR_VISIBLE features in registers that are only visible > + * to EL0 by trapping *must* have a corresponding HWCAP so that late > + * onlining of CPUs cannot lead to features disappearing at runtime. > + * > + * - A "feature" is typically a 4-bit register field. A "c
[PATCH v3 2/7] xen/arm: Import ID features sanitize from linux
Import structures declared in Linux file arch/arm64/kernel/cpufeature.c
and the required types from arch/arm64/include/asm/cpufeature.h.
Current code has been imported from Linux 5.13-rc5 (Commit ID
cd1245d75ce93b8fd206f4b34eb58bcfe156d5e9) and copied into cpufeature.c
in arm64 code and cpufeature.h in arm64 specific headers.
Those structure will be used to sanitize the cpu features available to
the ones availble on all cores of a system even if we are on an
heterogeneous platform (from example a big/LITTLE).
For each feature field of all ID registers, those structures define what
is the safest value and if we can allow to have different values in
different cores.
This patch is introducing Linux code without any changes to it.
Signed-off-by: Bertrand Marquis
---
Changes in v3: none
Changes in v2:
- Move add to Makefile to following patch to allow bisection
- Remove GPL text as SPDL is there
- Re-add introduction comment from Linux Kernel file
- Rename cpusanitize.c to cpufeature.c to keep Linux file name
- Move structures imported from linux headers into a new cpufeature.h
header in asm-arm/arm64.
- Move comment about imported code origin to the file header
- Remove not needed linux function declarations instead of removing them
in the following patch
- Add original arm64_ftr_safe_value from Linux
- include kernel.h to use max()
- remove unused ftr_single32 as we will not use it
- remove ctr associated structures that we cannot use (keep the one
defining sanitization bits)
---
xen/arch/arm/arm64/cpufeature.c| 504 +
xen/include/asm-arm/arm64/cpufeature.h | 104 +
2 files changed, 608 insertions(+)
create mode 100644 xen/arch/arm/arm64/cpufeature.c
create mode 100644 xen/include/asm-arm/arm64/cpufeature.h
diff --git a/xen/arch/arm/arm64/cpufeature.c b/xen/arch/arm/arm64/cpufeature.c
new file mode 100644
index 00..5777e33e5c
--- /dev/null
+++ b/xen/arch/arm/arm64/cpufeature.c
@@ -0,0 +1,504 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Contains CPU feature definitions
+ *
+ * The following structures have been imported directly from Linux kernel and
+ * should be kept in sync.
+ * The current version has been imported from arch/arm64/kernel/cpufeature.c
+ * from kernel version 5.13-rc5 together with the required structures and
+ * macros from arch/arm64/include/asm/cpufeature.h which are stored in
+ * include/asm-arm/arm64/cpufeature.h
+ *
+ * Copyright (C) 2021 Arm Ltd.
+ * based on code from the Linux kernel, which is:
+ * Copyright (C) 2015 ARM Ltd.
+ *
+ * A note for the weary kernel hacker: the code here is confusing and hard to
+ * follow! That's partly because it's solving a nasty problem, but also because
+ * there's a little bit of over-abstraction that tends to obscure what's going
+ * on behind a maze of helper functions and macros.
+ *
+ * The basic problem is that hardware folks have started gluing together CPUs
+ * with distinct architectural features; in some cases even creating SoCs where
+ * user-visible instructions are available only on a subset of the available
+ * cores. We try to address this by snapshotting the feature registers of the
+ * boot CPU and comparing these with the feature registers of each secondary
+ * CPU when bringing them up. If there is a mismatch, then we update the
+ * snapshot state to indicate the lowest-common denominator of the feature,
+ * known as the "safe" value. This snapshot state can be queried to view the
+ * "sanitised" value of a feature register.
+ *
+ * The sanitised register values are used to decide which capabilities we
+ * have in the system. These may be in the form of traditional "hwcaps"
+ * advertised to userspace or internal "cpucaps" which are used to configure
+ * things like alternative patching and static keys. While a feature mismatch
+ * may result in a TAINT_CPU_OUT_OF_SPEC kernel taint, a capability mismatch
+ * may prevent a CPU from being onlined at all.
+ *
+ * Some implementation details worth remembering:
+ *
+ * - Mismatched features are *always* sanitised to a "safe" value, which
+ * usually indicates that the feature is not supported.
+ *
+ * - A mismatched feature marked with FTR_STRICT will cause a "SANITY CHECK"
+ * warning when onlining an offending CPU and the kernel will be tainted
+ * with TAINT_CPU_OUT_OF_SPEC.
+ *
+ * - Features marked as FTR_VISIBLE have their sanitised value visible to
+ * userspace. FTR_VISIBLE features in registers that are only visible
+ * to EL0 by trapping *must* have a corresponding HWCAP so that late
+ * onlining of CPUs cannot lead to features disappearing at runtime.
+ *
+ * - A "feature" is typically a 4-bit register field. A "capability" is the
+ * high-level description derived from the sanitised field value.
+ *
+ * - Read the Arm ARM (DDI 0487F.a) section D13.1.3 ("Principles of the ID
+ * scheme for fields in ID registers") to understand when feature fields
+ * may be signed or unsigned (FTR_SIGNED and
