[RFC patch 0/4] riscv: introduce alternative mechanism to apply errata patches

[Ruinland ChuanTzu Tsai]

> 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

In general I love the idea of fixing errata dynamically, yet in the past,
vendors sometimes bump into the dilemma on the necessity of using alternative
framework or just plainly "ifdefine"-ing the CONFIG_ERRATUM_XXX to toggle their
fixups.

Quoting from the Qualcomm Falkor E1041 dicssusion threads [1][2] :

"Just do it with an #ifdef"

"There's really no need for this to be an alternative. It makes the kernel
larger and more complex due to all the altinstr data and probing code."

I wonder if there will be similar disputes end up here. And having a conclusion
on what should be resolved by alternative and what shouldn't might be more
complicated since we're having a more diversed group of vendors (or "users" who
can access the errata as you mentioned).

Cordially yours,
Ruinland

[1] https://lore.kernel.org/kvmarm/20171201112457.GE18083@arm.com/
[2] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512957823-18064-2-git-send-email-shankerd@codeaurora.org/#21249629

> 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".
> 
> 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.