[PATCH] riscv: xip: support runtime trap patching

[Palmer Dabbelt]

On Fri, 04 Jun 2021 02:52:40 PDT (-0700), vitaly.wool at konsulko.com wrote:
> Hi Alex,
>
> On Fri, Jun 4, 2021 at 11:35 AM Alex Ghiti <alex at ghiti.fr> wrote:
>>
>> Le 31/05/2021 à 17:17, Alex Ghiti a écrit :
>> > Hi Vitaly,
>> >
>> > Le 31/05/2021 à 10:53, Vitaly Wool a écrit :
>> >> RISCV_ERRATA_ALTERNATIVE patches text at runtime which is currently
>> >> not possible when the kernel is executed from the flash in XIP mode.
>> >> Since runtime patching concerns only traps at the moment, let's just
>> >> have all the traps reside in RAM anyway if RISCV_ERRATA_ALTERNATIVE
>> >> is set. Thus, these functions will be patch-able even when the .text
>> >> section is in flash.
>> >>
>> >
>> > This sounds like a good fix for sifive platforms to work with XIP kernel
>> > in 5.13: did you test that it actually works on HW?
>> >
>> >> Signed-off-by: Vitaly Wool <vitaly.wool at konsulko.com>
>> >> ---
>> >>   arch/riscv/kernel/traps.c           | 13 +++++++++----
>> >>   arch/riscv/kernel/vmlinux-xip.lds.S | 15 ++++++++++++++-
>> >>   2 files changed, 23 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
>> >> index 0721b9798595..7bc88d8aab97 100644
>> >> --- a/arch/riscv/kernel/traps.c
>> >> +++ b/arch/riscv/kernel/traps.c
>> >> @@ -86,8 +86,13 @@ static void do_trap_error(struct pt_regs *regs, int
>> >> signo, int code,
>> >>       }
>> >>   }
>> >> +#if defined (CONFIG_XIP_KERNEL) && defined
>> >> (CONFIG_RISCV_ERRATA_ALTERNATIVE)
>> >> +#define __trap_section        __section(".xip.traps")
>> >> +#else
>> >> +#define __trap_section
>> >> +#endif
>> >
>> > Maybe we could do something more generic. At the moment, only traps are
>> > subject to alternatives but that will likely expand: what about rather
>> > defining a section called __alternative_section?
>>
>> Any thoughts about that?
>
> Oh sorry, I have overlooked this. I do agree this is the way to go
> long term, I just wanted to do a reasonably good quick fix since the
> default SiFive configuration won't even build with CONFIG_XIP enabled.
> So I would probably just suggest to take the existing solution and
> then think over the details (e. g. should we just use one "alternative
> section" for both the functions and the table or have separate ones?)
> for the generic solution.

I've taken this on fixes.  It's fixing a bug and should be pretty safe, 
since it only has any effect on XIP kernels.