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

Re: [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.


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

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

[Vincent Chen]

On Thu, Mar 11, 2021 at 11:51 AM Ruinland ChuanTzu Tsai
<ruinland@andestech.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
>
> 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 be honest, We had a similar discussion in our internal group, and
someone voted for the ifdef method. However, in the end, I chose the
alternative scheme because it will not have any performance impact on
other vendor's core.

For the "#ifdef" mechanism, if we want one kernel image that can
include all vendor's errata, all CONFIG_ERRATA_XXX should be able to
enable at the same time. In this case, the code patching may become
the following pattern.

if (IS_ENABLED(CONFIG_ERRATA_XXX ) && unlikely(has_errata_xxx))
{
      vendor's errata ......
}
The has_errata_xxx is a global variable and its default value is 0. At
runtime, the customized function provided by the vendor should
properly set has_errata_xxx as 1 for the specified CPU cores. Because
the default value of has_errata_xxx for certain cores is 0, It is OK
for all vendor's to enable the CONFIG_ERRATA_XXX. However, this
implementation will cause other vendors to suffer some performance
impact. I used sifive errata cip 1200 as an example:

+        if (IS_ENABLED(CONFIG_ERRATA_SIFIVE_CIP_1200) &&
unlikely(has_errata_sifive_cip_1200)) {
+                asm("sfence.vma\n");
+        } else
+               local_flush_tlb_page(addr);

In this case, except for the particular sifive cores, all riscv cores
will execute local_flush_tlb_page(addr) instead of sfence.vma. The
corresponding assembly code is listed below.

        if (IS_ENABLED(CONFIG_ERRATA_SIFIVE_CIP_1200) &&
unlikely(has_errata_sifive_cip_1200)) {
ffffffe000007416:       012dd797                auipc   a5,0x12dd
ffffffe00000741a:       cfa7c783                lbu     a5,-774(a5) #
ffffffe0012e4110 <has_errata_sifive_cip_1200>
ffffffe00000741e:       e7e9                    bnez
a5,ffffffe0000074e8 <do_page_fault+0x33c>
local_flush_tlb_page():
/home/vincentchen/work/64bit/linux/./arch/riscv/include/asm/tlbflush.h:22
ffffffe000007420:       12098073                sfence.vma      s3

According to the objdump results, before executing
local_flush_tlb_page(), other vendors' cores need to execute three
additional instructions (from 0xffffffe000007416 to
0xffffffe00000741e) due to this errata. The performance impact from
these 3 instructions may be slight. ( 1. The branch predictor may
always do the correct prediction at 0xffffffe00000741e. 2. If this
errata is inserted into a hot spot path, has_errata_sifive_cip_1200
may be stored in the L2 cache.) However, I am still not sure whether
each vendor is willing to suffer the performance impact. Besides, I am
also worried that if we have a lot of errata, the impact on
performance will become significant. Therefore, I finally chose the
alternative scheme.

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.

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

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

[Ruinland ChuanTzu Tsai]

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


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/include/asm/assembler.h#n610

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/Kconfig#n805


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

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

[Vincent Chen]

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

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

[Vincent Chen]

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

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

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

[Palmer Dabbelt]

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

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

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

[Vincent Chen]

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

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.

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

-- 
2.7.4


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