[PATCH v2 1/1] riscv: restore global data pointer in trap handler

[Bin Meng]

Hi Heinrich,

On Sun, Sep 27, 2020 at 4:46 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 9/27/20 10:40 AM, Bin Meng wrote:
> > On Sun, Sep 27, 2020 at 4:24 PM Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >> The gp register is used to store U-Boot's global data pointer. We should
> >> not assume that an UEFI application leaves the gp register unchanged as
> >> the UEFI specifications does not define who is the owner of the gp and tp
> >> registers.
> >>
> >> So the following sequence should be followed in the trap handler:
> >>
> >> * save the caller's gp register
> >> * restore the global data pointer
> >> * serve interrupts or print crash dump and reset
> >> * restore the caller's gp register
> >>
> >> Cc: Abner Chang <abner.chang at hpe.com>
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> >> ---
> >> v2:
> >>         Saving and restoring the caller's x3 is already handled in mtrap.S.
> >>         efi_loader.h provides an empty fallback efi_restore_gd() function
> >>         if CONFIG_EFI_LOADER=n.
> >> ---
> >>  arch/riscv/lib/interrupts.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
> >> index cd47e64487..8ff40f0f36 100644
> >> --- a/arch/riscv/lib/interrupts.c
> >> +++ b/arch/riscv/lib/interrupts.c
> >> @@ -111,6 +111,9 @@ ulong handle_trap(ulong cause, ulong epc, ulong tval, struct pt_regs *regs)
> >>  {
> >>         ulong is_irq, irq;
> >>
> >> +       /* An UEFI application may have changed gd. Restore U-Boot's gd. */
> >> +       efi_restore_gd();
> >> +
> >>         is_irq = (cause & MCAUSE_INT);
> >>         irq = (cause & ~MCAUSE_INT);
> >>
> >
> > Reviewed-by: Bin Meng <bin.meng at windriver.com>
> >
> > Does other arch suffer the same issue?
> >
>
> Hello Bin,
>
> x86 does not use a register of gd.

x86 uses fs segment register to point to gd. Does UEFI not use fs?

> arm has this statement already.
> No further architectures support UEFI.
>

Regards,
Bin