Message ID | 1615175897-23509-1-git-send-email-vincent.chen@sifive.com (mailing list archive) |
---|---|
Headers | show |
Series | riscv: introduce alternative mechanism to apply errata patches | expand |
On Sun, 07 Mar 2021 19:58:13 PST (-0800), vincent.chen@sifive.com wrote: > With the emergence of more and more RISC-V CPUs, the request for how to > upstream the vendor errata patch may gradually appear. In order to resolve > this issue, this patch introduces the alternative mechanism from ARM64 and > x86 to enable the kernel to patch code at runtime according to the > manufacturer information of the running CPU. The main purpose of this patch > set is to propose a framework to apply vendor's errata solutions. Based on > this framework, it can be ensured that the errata only applies to the > specified CPU cores. Other CPU cores do not be affected. Therefore, some > complicated scenarios are unsupported in this patch set, such as patching > code to the kernel module, doing relocation in patching code, and > heterogeneous CPU topology. > > In the "alternative" scheme, Users could use the macro ALTERNATIVE to apply > an errata to the existing code flow. In the macro ALTERNATIVE, users need > to specify the manufacturer information (vendor id, arch id, and implement > id) for this errata. Therefore, kernel will know this errata is suitable > for which CPU core. During the booting procedure, kernel will select the > errata required by the CPU core and then patch it. It means that the kernel > only applies the errata to the specified CPU core. In this case, the > vendor's errata does not affect each other at runtime. The above patching > procedure only occurs during the booting phase, so we only take the > overhead of the "alternative" mechanism once. > > This "alternative" mechanism is enabled by default to ensure that all > required errata will be applied. However, users can disable this feature by > the Kconfig "CONFIG_RISCV_ERRATA_ALTERNATIVE". This all generally seems OK to me, though I have a few comments in the actual patches. > > The last patch is to apply the SiFive CIP-453 errata by this "alternative" > scheme. Therefore, It can be regarded as an example. According to the > results of running this image on the QEMU virt platform, kernel does not > apply this errata at run-time because the CPU manufacturer information > does not match the specified SiFive CPU core. Therefore, this errata does > not affect any CPU core except for the specified SiFive cores. Looking at the documentation for that I also saw CIP-1200. That one seems way scarier, and also probably a better driver for building an errata framework as it has more than one caller. Is that in this chip? It's in a document just titled "Errata_FU740-C000_20210205". > > Vincent Chen (4): > riscv: Add 3 SBI wrapper functions to get cpu manufacturer information > riscv: Get CPU manufacturer information > riscv: Introduce alternative mechanism to apply errata solution > riscv: sifive: apply errata "cip-453" patch > > arch/riscv/Kconfig | 1 + > arch/riscv/Kconfig.erratas | 32 ++++++++ > arch/riscv/Kconfig.socs | 1 + > arch/riscv/Makefile | 1 + > arch/riscv/errata/Makefile | 2 + > arch/riscv/errata/alternative.c | 69 +++++++++++++++++ > arch/riscv/errata/sifive/Makefile | 2 + > arch/riscv/errata/sifive/errata.c | 56 ++++++++++++++ > arch/riscv/errata/sifive/errata_cip_453.S | 34 +++++++++ > arch/riscv/include/asm/alternative-macros.h | 110 ++++++++++++++++++++++++++++ > arch/riscv/include/asm/alternative.h | 44 +++++++++++ > arch/riscv/include/asm/asm.h | 1 + > arch/riscv/include/asm/csr.h | 3 + > arch/riscv/include/asm/errata_list.h | 9 +++ > arch/riscv/include/asm/hwcap.h | 6 ++ > arch/riscv/include/asm/processor.h | 2 + > arch/riscv/include/asm/sbi.h | 3 + > arch/riscv/include/asm/sections.h | 2 + > arch/riscv/include/asm/soc.h | 1 + > arch/riscv/include/asm/vendorid_list.h | 6 ++ > arch/riscv/kernel/cpufeature.c | 17 +++++ > arch/riscv/kernel/entry.S | 12 ++- > arch/riscv/kernel/sbi.c | 15 ++++ > arch/riscv/kernel/setup.c | 2 + > arch/riscv/kernel/smpboot.c | 4 + > arch/riscv/kernel/soc.c | 1 + > arch/riscv/kernel/vmlinux.lds.S | 14 ++++ > 27 files changed, 448 insertions(+), 2 deletions(-) > create mode 100644 arch/riscv/Kconfig.erratas > create mode 100644 arch/riscv/errata/Makefile > create mode 100644 arch/riscv/errata/alternative.c > create mode 100644 arch/riscv/errata/sifive/Makefile > create mode 100644 arch/riscv/errata/sifive/errata.c > create mode 100644 arch/riscv/errata/sifive/errata_cip_453.S > create mode 100644 arch/riscv/include/asm/alternative-macros.h > create mode 100644 arch/riscv/include/asm/alternative.h > create mode 100644 arch/riscv/include/asm/errata_list.h > create mode 100644 arch/riscv/include/asm/vendorid_list.h
On Wed, Mar 10, 2021 at 12:39 PM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Sun, 07 Mar 2021 19:58:13 PST (-0800), vincent.chen@sifive.com wrote: > > With the emergence of more and more RISC-V CPUs, the request for how to > > upstream the vendor errata patch may gradually appear. In order to resolve > > this issue, this patch introduces the alternative mechanism from ARM64 and > > x86 to enable the kernel to patch code at runtime according to the > > manufacturer information of the running CPU. The main purpose of this patch > > set is to propose a framework to apply vendor's errata solutions. Based on > > this framework, it can be ensured that the errata only applies to the > > specified CPU cores. Other CPU cores do not be affected. Therefore, some > > complicated scenarios are unsupported in this patch set, such as patching > > code to the kernel module, doing relocation in patching code, and > > heterogeneous CPU topology. > > > > In the "alternative" scheme, Users could use the macro ALTERNATIVE to apply > > an errata to the existing code flow. In the macro ALTERNATIVE, users need > > to specify the manufacturer information (vendor id, arch id, and implement > > id) for this errata. Therefore, kernel will know this errata is suitable > > for which CPU core. During the booting procedure, kernel will select the > > errata required by the CPU core and then patch it. It means that the kernel > > only applies the errata to the specified CPU core. In this case, the > > vendor's errata does not affect each other at runtime. The above patching > > procedure only occurs during the booting phase, so we only take the > > overhead of the "alternative" mechanism once. > > > > This "alternative" mechanism is enabled by default to ensure that all > > required errata will be applied. However, users can disable this feature by > > the Kconfig "CONFIG_RISCV_ERRATA_ALTERNATIVE". > > This all generally seems OK to me, though I have a few comments in the actual > patches. > > > > > The last patch is to apply the SiFive CIP-453 errata by this "alternative" > > scheme. Therefore, It can be regarded as an example. According to the > > results of running this image on the QEMU virt platform, kernel does not > > apply this errata at run-time because the CPU manufacturer information > > does not match the specified SiFive CPU core. Therefore, this errata does > > not affect any CPU core except for the specified SiFive cores. > > Looking at the documentation for that I also saw CIP-1200. That one seems way > scarier, and also probably a better driver for building an errata framework as > it has more than one caller. Is that in this chip? It's in a document just > titled "Errata_FU740-C000_20210205". > This chip has the CIP-1200 issue, and we had a patch using this alternative scheme to apply this errata. The code is like below: static inline void local_flush_tlb_page(unsigned long addr) { - __asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory"); + __asm__ __volatile__( + ALTERNATIVE("sfence.vma %0", "sfence.vma",SIFIVE_VENDOR_ID, ERRATA_CIP_1200, CONFIG_ERRATA_SIFIVE_CIP_1200) + : + : "r" (addr) + : "memory"); } We originally plan to send this errata patch after each vendor accepts this alternative framework. > > > > Vincent Chen (4): > > riscv: Add 3 SBI wrapper functions to get cpu manufacturer information > > riscv: Get CPU manufacturer information > > riscv: Introduce alternative mechanism to apply errata solution > > riscv: sifive: apply errata "cip-453" patch > > > > arch/riscv/Kconfig | 1 + > > arch/riscv/Kconfig.erratas | 32 ++++++++ > > arch/riscv/Kconfig.socs | 1 + > > arch/riscv/Makefile | 1 + > > arch/riscv/errata/Makefile | 2 + > > arch/riscv/errata/alternative.c | 69 +++++++++++++++++ > > arch/riscv/errata/sifive/Makefile | 2 + > > arch/riscv/errata/sifive/errata.c | 56 ++++++++++++++ > > arch/riscv/errata/sifive/errata_cip_453.S | 34 +++++++++ > > arch/riscv/include/asm/alternative-macros.h | 110 ++++++++++++++++++++++++++++ > > arch/riscv/include/asm/alternative.h | 44 +++++++++++ > > arch/riscv/include/asm/asm.h | 1 + > > arch/riscv/include/asm/csr.h | 3 + > > arch/riscv/include/asm/errata_list.h | 9 +++ > > arch/riscv/include/asm/hwcap.h | 6 ++ > > arch/riscv/include/asm/processor.h | 2 + > > arch/riscv/include/asm/sbi.h | 3 + > > arch/riscv/include/asm/sections.h | 2 + > > arch/riscv/include/asm/soc.h | 1 + > > arch/riscv/include/asm/vendorid_list.h | 6 ++ > > arch/riscv/kernel/cpufeature.c | 17 +++++ > > arch/riscv/kernel/entry.S | 12 ++- > > arch/riscv/kernel/sbi.c | 15 ++++ > > arch/riscv/kernel/setup.c | 2 + > > arch/riscv/kernel/smpboot.c | 4 + > > arch/riscv/kernel/soc.c | 1 + > > arch/riscv/kernel/vmlinux.lds.S | 14 ++++ > > 27 files changed, 448 insertions(+), 2 deletions(-) > > create mode 100644 arch/riscv/Kconfig.erratas > > create mode 100644 arch/riscv/errata/Makefile > > create mode 100644 arch/riscv/errata/alternative.c > > create mode 100644 arch/riscv/errata/sifive/Makefile > > create mode 100644 arch/riscv/errata/sifive/errata.c > > create mode 100644 arch/riscv/errata/sifive/errata_cip_453.S > > create mode 100644 arch/riscv/include/asm/alternative-macros.h > > create mode 100644 arch/riscv/include/asm/alternative.h > > create mode 100644 arch/riscv/include/asm/errata_list.h > > create mode 100644 arch/riscv/include/asm/vendorid_list.h