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

[Vincent Chen <vincent.chen@sifive.com>]

On Mon, Mar 15, 2021 at 12:46 PM Ruinland ChuanTzu Tsai
<ruinland@andestech.com> wrote:
>
> Hi Vincent,
>
> > However, if all vendors are willing to suffer the performance impact
> > from other vendor's errata, I can change the framework to "#ifdef"
> > scheme. After all, it may need to take a lot of time to accumulate a
> > lot of errata to make the performance impact obvious.
> I'm not sure if I'm interpreting the alternative framework right, yet I have
> doubts about the performance arguments.
> Just as the example (CONFIG_QCOM_FALKOR_ERRATUM_E1041) I quoted in the
> previous
> mail, in their final decision, the `#ifdef` simply toggles the code in
> _compile time_ [1].
>
> I don't know why they chose to enable it by default [2], yet ideally, for
> irrelevant processors/SoCs, people should be able to turn the option off
> without issues.
>
> Somehow, to my best acknowledgment and as you mentioned, in ARM's ecosystem
> (more specifically, the distros), alternative-based errata fixes are all
> enabl-
> ed by default, so all the errata workarounds will be generated and gathered
> into a special section. This will cause the size of Linux image which
> distros
> shipped to become larger and larger.
>
> For ARM, that might not be a problem since most of the IC vendors
> nowadays are
> licensing from ARM and few of them are making their microarchitectures.
> So mi errata es su errata. (My errata is your errata.)
>
> Yet for RISC-V, we have plenty of players who make their home-grown cores on
> the field.
> This leads to a dilemma: either to enable all the workarounds by default
> so the
> distros could just build one general image which will become bloated or
> specially crafted images will be provided lead to a fractured experience for
> end-users.
>
> My 2 cents on this issue is that maybe we need to establish a principle
> (probably not in a written-down manner) on deciding what goes to alternative
> and what shall just be an option disabled by default.
>
> Cordially yours,
> Ruinland
>

Hi Ruinland,
I can understand and agree with what you worry about the image size.
However, I have a different idea to resolve this issue.

I prefer the RISC-V default configuration to enable all errata
KCONFIG. It can ensure that the default image can run on all vendors'
platforms without any known hardware issue. For general users, it is
more friendly because they do not need to worry whether missing the
required errata or not. For advanced users such as distros, given the
targeted platforms, they can use Kconfig to disable unneeded errata to
shrink the kernel image. Therefore, they do not ship a bloated kernel
image to their customers.

Back to the current alternative framework, it can support the above
case. Users can only enable particular CONFIG_ERRATA_XXX to generate a
customized image for a specified platform. Because the kernel patches
errata at runtime, it also allows users to enable multiple
CONFIG_ERRATA_XXX at the same time to generate a uniform image run on
multiple RISC-V platforms. Therefore, it reserves the flexibility for
distros or vendors to customize the kernel image.

In contrast to the alternative framework, if we only use "ifdef" to
patch errata at compile-time, one image can run on specified
platforms. In this case, not only distros but also vendors will have
kernel image fragmentation issues. It may increase the maintenance
effort.

Based on the above reason, I do not prefer to use "ifdef" to patch
errata at compile time.

Best regards,
Vincent

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv