Hi Catalin, Will, et al,
This patch series attempts to improve configuration of vendor-specific
errata, by
1. sorting them by vendor,
2. adding platform dependencies, to avoid asking irrelevant questions
when configuring your kernel.
Thanks for your comments!
Geert Uytterhoeven (2):
arm64: Sort vendor-specific errata
[RFC] arm64: Add dependencies to vendor-specific errata
arch/arm64/Kconfig | 82 ++++++++++++++++++++++++++--------------------
1 file changed, 46 insertions(+), 36 deletions(-)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Currently the user is asked about enabling support for each and every
vendor-specific erratum, even when support for the specific platform is
not enabled.
Fix this by adding platform dependencies to the config options
controlling support for vendor-specific errata.
Note that FUJITSU_ERRATUM_010001 is left untouched, as no config symbol
exists for the Fujitsu A64FX platform.
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
arch/arm64/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8d33d7fed6d8549b..81f52f0b988e6350 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -622,6 +622,8 @@ config ARM64_ERRATUM_1542419
If unsure, say Y.
+if ARCH_THUNDER2
+
config CAVIUM_ERRATUM_22375
bool "Cavium erratum 22375, 24313"
default y
@@ -697,6 +699,8 @@ config CAVIUM_TX2_ERRATUM_219
If unsure, say Y.
+endif # ARCH_THUNDER2
+
config FUJITSU_ERRATUM_010001
bool "Fujitsu-A64FX erratum E#010001: Undefined fault may occur wrongly"
default y
@@ -718,6 +722,7 @@ config FUJITSU_ERRATUM_010001
config HISILICON_ERRATUM_161600802
bool "Hip07 161600802: Erroneous redistributor VLPI base"
+ depends on ARCH_HISI
default y
help
The HiSilicon Hip07 SoC uses the wrong redistributor base
@@ -726,6 +731,8 @@ config HISILICON_ERRATUM_161600802
If unsure, say Y.
+if ARCH_QCOM
+
config QCOM_FALKOR_ERRATUM_1003
bool "Falkor E1003: Incorrect translation due to ASID change"
default y
@@ -768,8 +775,11 @@ config QCOM_FALKOR_ERRATUM_E1041
If unsure, say Y.
+endif # ARCH_QCOM
+
config SOCIONEXT_SYNQUACER_PREITS
bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
+ depends on ARCH_SYNQUACER
default y
help
Socionext Synquacer SoCs implement a separate h/w block to generate
--
2.17.1
Hi Geert,
On Thu, Apr 16, 2020 at 01:56:58PM +0200, Geert Uytterhoeven wrote:
> Currently the user is asked about enabling support for each and every
> vendor-specific erratum, even when support for the specific platform is
> not enabled.
>
> Fix this by adding platform dependencies to the config options
> controlling support for vendor-specific errata.
>
> Note that FUJITSU_ERRATUM_010001 is left untouched, as no config symbol
> exists for the Fujitsu A64FX platform.
>
> Signed-off-by: Geert Uytterhoeven <[email protected]>
I'm not su1re that it makes sense to do this in general, becaose the
ARCH_* platform symbols are about plactform/SoC support (e.g. pinctrl
drivers), and these are (mostly) CPU-local and/or VM-visible.
I think that it makes sense for those to be independent because:
* future SoCs in the same family might not need the same CPU errata
workarounds, and it's arguably just as confusing to have the option
there.
* It prevents building a minimal VM image with all (non-virtualized)
platform support disabled, but all possible (VM-visible) errata
options enabled. I do that occassionally for testing/analysis, and I
can imagine this is useful for those building images that are only
intended to be used in VMs.
I think the change to SOCIONEXT_SYNQUACER_PREITS makes sense given
that's a platform-level detail. Arguably that should be moved into
drivers/irqchip/Kconfig.
Thanks,
Mark.
> ---
> arch/arm64/Kconfig | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8d33d7fed6d8549b..81f52f0b988e6350 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -622,6 +622,8 @@ config ARM64_ERRATUM_1542419
>
> If unsure, say Y.
>
> +if ARCH_THUNDER2
> +
> config CAVIUM_ERRATUM_22375
> bool "Cavium erratum 22375, 24313"
> default y
> @@ -697,6 +699,8 @@ config CAVIUM_TX2_ERRATUM_219
>
> If unsure, say Y.
>
> +endif # ARCH_THUNDER2
> +
> config FUJITSU_ERRATUM_010001
> bool "Fujitsu-A64FX erratum E#010001: Undefined fault may occur wrongly"
> default y
> @@ -718,6 +722,7 @@ config FUJITSU_ERRATUM_010001
>
> config HISILICON_ERRATUM_161600802
> bool "Hip07 161600802: Erroneous redistributor VLPI base"
> + depends on ARCH_HISI
> default y
> help
> The HiSilicon Hip07 SoC uses the wrong redistributor base
> @@ -726,6 +731,8 @@ config HISILICON_ERRATUM_161600802
>
> If unsure, say Y.
>
> +if ARCH_QCOM
> +
> config QCOM_FALKOR_ERRATUM_1003
> bool "Falkor E1003: Incorrect translation due to ASID change"
> default y
> @@ -768,8 +775,11 @@ config QCOM_FALKOR_ERRATUM_E1041
>
> If unsure, say Y.
>
> +endif # ARCH_QCOM
> +
> config SOCIONEXT_SYNQUACER_PREITS
> bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
> + depends on ARCH_SYNQUACER
> default y
> help
> Socionext Synquacer SoCs implement a separate h/w block to generate
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Sort configuration options for vendor-specific errata by vendor, to
increase uniformity.
Move ARM64_WORKAROUND_REPEAT_TLBI up, as it is also selected by
ARM64_ERRATUM_1286807.
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
arch/arm64/Kconfig | 72 +++++++++++++++++++++++-----------------------
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 40fb05d96c6072c9..8d33d7fed6d8549b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -553,6 +553,9 @@ config ARM64_ERRATUM_1530923
If unsure, say Y.
+config ARM64_WORKAROUND_REPEAT_TLBI
+ bool
+
config ARM64_ERRATUM_1286807
bool "Cortex-A76: Modification of the translation table for a virtual address might lead to read-after-read ordering violation"
default y
@@ -694,6 +697,35 @@ config CAVIUM_TX2_ERRATUM_219
If unsure, say Y.
+config FUJITSU_ERRATUM_010001
+ bool "Fujitsu-A64FX erratum E#010001: Undefined fault may occur wrongly"
+ default y
+ help
+ This option adds a workaround for Fujitsu-A64FX erratum E#010001.
+ On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1), memory
+ accesses may cause undefined fault (Data abort, DFSC=0b111111).
+ This fault occurs under a specific hardware condition when a
+ load/store instruction performs an address translation using:
+ case-1 TTBR0_EL1 with TCR_EL1.NFD0 == 1.
+ case-2 TTBR0_EL2 with TCR_EL2.NFD0 == 1.
+ case-3 TTBR1_EL1 with TCR_EL1.NFD1 == 1.
+ case-4 TTBR1_EL2 with TCR_EL2.NFD1 == 1.
+
+ The workaround is to ensure these bits are clear in TCR_ELx.
+ The workaround only affects the Fujitsu-A64FX.
+
+ If unsure, say Y.
+
+config HISILICON_ERRATUM_161600802
+ bool "Hip07 161600802: Erroneous redistributor VLPI base"
+ default y
+ help
+ The HiSilicon Hip07 SoC uses the wrong redistributor base
+ when issued ITS commands such as VMOVP and VMAPP, and requires
+ a 128kB offset to be applied to the target address in this commands.
+
+ If unsure, say Y.
+
config QCOM_FALKOR_ERRATUM_1003
bool "Falkor E1003: Incorrect translation due to ASID change"
default y
@@ -705,9 +737,6 @@ config QCOM_FALKOR_ERRATUM_1003
is unchanged. Work around the erratum by invalidating the walk cache
entries for the trampoline before entering the kernel proper.
-config ARM64_WORKAROUND_REPEAT_TLBI
- bool
-
config QCOM_FALKOR_ERRATUM_1009
bool "Falkor E1009: Prematurely complete a DSB after a TLBI"
default y
@@ -729,25 +758,6 @@ config QCOM_QDF2400_ERRATUM_0065
If unsure, say Y.
-config SOCIONEXT_SYNQUACER_PREITS
- bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
- default y
- help
- Socionext Synquacer SoCs implement a separate h/w block to generate
- MSI doorbell writes with non-zero values for the device ID.
-
- If unsure, say Y.
-
-config HISILICON_ERRATUM_161600802
- bool "Hip07 161600802: Erroneous redistributor VLPI base"
- default y
- help
- The HiSilicon Hip07 SoC uses the wrong redistributor base
- when issued ITS commands such as VMOVP and VMAPP, and requires
- a 128kB offset to be applied to the target address in this commands.
-
- If unsure, say Y.
-
config QCOM_FALKOR_ERRATUM_E1041
bool "Falkor E1041: Speculative instruction fetches might cause errant memory access"
default y
@@ -758,22 +768,12 @@ config QCOM_FALKOR_ERRATUM_E1041
If unsure, say Y.
-config FUJITSU_ERRATUM_010001
- bool "Fujitsu-A64FX erratum E#010001: Undefined fault may occur wrongly"
+config SOCIONEXT_SYNQUACER_PREITS
+ bool "Socionext Synquacer: Workaround for GICv3 pre-ITS"
default y
help
- This option adds a workaround for Fujitsu-A64FX erratum E#010001.
- On some variants of the Fujitsu-A64FX cores ver(1.0, 1.1), memory
- accesses may cause undefined fault (Data abort, DFSC=0b111111).
- This fault occurs under a specific hardware condition when a
- load/store instruction performs an address translation using:
- case-1 TTBR0_EL1 with TCR_EL1.NFD0 == 1.
- case-2 TTBR0_EL2 with TCR_EL2.NFD0 == 1.
- case-3 TTBR1_EL1 with TCR_EL1.NFD1 == 1.
- case-4 TTBR1_EL2 with TCR_EL2.NFD1 == 1.
-
- The workaround is to ensure these bits are clear in TCR_ELx.
- The workaround only affects the Fujitsu-A64FX.
+ Socionext Synquacer SoCs implement a separate h/w block to generate
+ MSI doorbell writes with non-zero values for the device ID.
If unsure, say Y.
--
2.17.1
On Thu, Apr 16, 2020 at 2:56 PM Mark Rutland <[email protected]> wrote:
> On Thu, Apr 16, 2020 at 01:56:58PM +0200, Geert Uytterhoeven wrote:
> > Currently the user is asked about enabling support for each and every
> > vendor-specific erratum, even when support for the specific platform is
> > not enabled.
> >
> > Fix this by adding platform dependencies to the config options
> > controlling support for vendor-specific errata.
> >
> > Note that FUJITSU_ERRATUM_010001 is left untouched, as no config symbol
> > exists for the Fujitsu A64FX platform.
> >
> > Signed-off-by: Geert Uytterhoeven <[email protected]>
>
> I'm not su1re that it makes sense to do this in general, becaose the
> ARCH_* platform symbols are about plactform/SoC support (e.g. pinctrl
> drivers), and these are (mostly) CPU-local and/or VM-visible.
>
> I think that it makes sense for those to be independent because:
>
> * future SoCs in the same family might not need the same CPU errata
> workarounds, and it's arguably just as confusing to have the option
> there.
>
> * It prevents building a minimal VM image with all (non-virtualized)
> platform support disabled, but all possible (VM-visible) errata
> options enabled. I do that occassionally for testing/analysis, and I
> can imagine this is useful for those building images that are only
> intended to be used in VMs.
Most architectures over time grow a CPU selection option that is
at least somewhat orthogonal to the platform selection. I think so far
arm64 has intentionally resisted this based on the idea that the CPUs
are mostly equal and differences are better handled at runtime.
If we decide to revisit this in the future that might help both the
errata selection and give a way to e.g. build for an ARMv8.2
baseline.
This does seem pretty far out at the moment of course, given
that most SoCs we work on are still based on Cortex-A53 or A72 ;-)
> I think the change to SOCIONEXT_SYNQUACER_PREITS makes sense given
> that's a platform-level detail. Arguably that should be moved into
> drivers/irqchip/Kconfig.
Agreed
Arnd
Hi Mark,
On Thu, Apr 16, 2020 at 2:56 PM Mark Rutland <[email protected]> wrote:
> On Thu, Apr 16, 2020 at 01:56:58PM +0200, Geert Uytterhoeven wrote:
> > Currently the user is asked about enabling support for each and every
> > vendor-specific erratum, even when support for the specific platform is
> > not enabled.
> >
> > Fix this by adding platform dependencies to the config options
> > controlling support for vendor-specific errata.
> >
> > Note that FUJITSU_ERRATUM_010001 is left untouched, as no config symbol
> > exists for the Fujitsu A64FX platform.
> >
> > Signed-off-by: Geert Uytterhoeven <[email protected]>
>
> I'm not su1re that it makes sense to do this in general, becaose the
> ARCH_* platform symbols are about plactform/SoC support (e.g. pinctrl
> drivers), and these are (mostly) CPU-local and/or VM-visible.
>
> I think that it makes sense for those to be independent because:
>
> * future SoCs in the same family might not need the same CPU errata
> workarounds, and it's arguably just as confusing to have the option
> there.
True. But at least the dependency restricts the confusion to a smaller
audience.
> * It prevents building a minimal VM image with all (non-virtualized)
> platform support disabled, but all possible (VM-visible) errata
> options enabled. I do that occassionally for testing/analysis, and I
> can imagine this is useful for those building images that are only
> intended to be used in VMs.
Oh, you also want to build a "generic" guest kernel, with all ARCH_*
symbols disabled. Let's hope a maleficent user cannot disable errata
mitigations in the guest kernel and break the host ;-)
And perhaps you do want to enable some platform-specific drivers for
VFIO pass-through? Hence having ARCH_* dependencies on those drivers
means they cannot be enabled :-( Hmm...
> I think the change to SOCIONEXT_SYNQUACER_PREITS makes sense given
> that's a platform-level detail. Arguably that should be moved into
> drivers/irqchip/Kconfig.
OK, makes sense.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Thu, Apr 16, 2020 at 05:38:07PM +0200, Geert Uytterhoeven wrote:
> On Thu, Apr 16, 2020 at 2:56 PM Mark Rutland <[email protected]> wrote:
> > On Thu, Apr 16, 2020 at 01:56:58PM +0200, Geert Uytterhoeven wrote:
> > > Currently the user is asked about enabling support for each and every
> > > vendor-specific erratum, even when support for the specific platform is
> > > not enabled.
> > >
> > > Fix this by adding platform dependencies to the config options
> > > controlling support for vendor-specific errata.
> > I'm not su1re that it makes sense to do this in general, becaose the
> > ARCH_* platform symbols are about plactform/SoC support (e.g. pinctrl
> > drivers), and these are (mostly) CPU-local and/or VM-visible.
> >
> > I think that it makes sense for those to be independent because:
> > * It prevents building a minimal VM image with all (non-virtualized)
> > platform support disabled, but all possible (VM-visible) errata
> > options enabled. I do that occassionally for testing/analysis, and I
> > can imagine this is useful for those building images that are only
> > intended to be used in VMs.
>
> Oh, you also want to build a "generic" guest kernel, with all ARCH_*
> symbols disabled.
Yup! As above I do this today for building test kernels I run on a
number of different hosts, and I'm aware of other use-cases (e.g. WSL2
or docker for mac) where you may want to do this to minimize the core
kernel either for size or security reasons.
> Let's hope a maleficent user cannot disable errata mitigations in the
> guest kernel and break the host ;-)
Indeed ;)
For cases where a malicious guest could cause harm we've added
workarounds in KVM, so unless we've missed something that shouldn't be
the case.
Otherwise, a guest missing these is just shooting itself in the foot.
> And perhaps you do want to enable some platform-specific drivers for
> VFIO pass-through? Hence having ARCH_* dependencies on those drivers
> means they cannot be enabled :-( Hmm...
IIRC platform device passthrough requires an corresponding VFIO platform
driver in the host to handle reset and so on, but it does seem a shame
to not allow the user to select a driver if they really want it.
I guess there might be platform-specific PCIe drivers too, which might
work with VFIO regardless.
Thanks,
Mark.
On 16.04.20 13:56:58, Geert Uytterhoeven wrote:
> Currently the user is asked about enabling support for each and every
> vendor-specific erratum, even when support for the specific platform is
> not enabled.
>
> Fix this by adding platform dependencies to the config options
> controlling support for vendor-specific errata.
>
> Note that FUJITSU_ERRATUM_010001 is left untouched, as no config symbol
> exists for the Fujitsu A64FX platform.
>
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> ---
> arch/arm64/Kconfig | 10 ++++++++++
> 1 file changed, 10 insertions(+)
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 8d33d7fed6d8549b..81f52f0b988e6350 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -622,6 +622,8 @@ config ARM64_ERRATUM_1542419
>
> If unsure, say Y.
>
> +if ARCH_THUNDER2
> +
> config CAVIUM_ERRATUM_22375
> bool "Cavium erratum 22375, 24313"
> default y
> @@ -697,6 +699,8 @@ config CAVIUM_TX2_ERRATUM_219
>
> If unsure, say Y.
>
> +endif # ARCH_THUNDER2
For Cavium servers these ARCH_* options are only used to enable some
minor (mostly platform) drivers (i2c, spi, gpio, etc.), so the options
are not of much use and I better would like to get rid of them
completely, which makes us independent and more flexible when enabling
or disabling options. In ThunderX* systems there are not many devices
that are soc or board specific, most of them are detected using
generic methods like pci or acpi. So the situation is rather
comparable to x86 systems (there are options based on vendor or core)
than to ARM embedded chips.
Using the ARCH_* options to control also enablement of cpu errata
handling would add a strong dependency here and will make that options
a requirement.
How about having core/vendor specific submenus that make switching off
options easier?
Thanks,
-Robert