On Fri, 8 Mar 2024 at 08:10, yunhui cui <cuiyunhui@xxxxxxxxxxxxx> wrote: > > Hi Ard, > > On Fri, Mar 8, 2024 at 12:49 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Thu, 7 Mar 2024 at 04:19, yunhui cui <cuiyunhui@xxxxxxxxxxxxx> wrote: > > > ... > > > > > > From the logic of binutils, if "__global_pointer$" exists, it is > > > possible to use GP for optimization. For RISC-V, "__global_pointer$" > > > was introduced in commit "fbe934d69eb7e". Therefore, for the system as > > > a whole, we should keep using GP uniformly. > > > > There is no 'system as a whole' that can use GP 'uniformly' > > > > The EFI stub is a separate executable that runs from a different > > mapping of memory, in an execution context managed by the firmware. It > > happens to be linked into the same executable as the vmlinux kernel. > > > > > The root cause of this > > > problem is that GP is not loaded, rather than "On RISC-V, we also > > > avoid GP based relocations..." as commit "d2baf8cc82c17" said. > > > > GP is not loaded because in the EFI firmware context, there is no safe > > way to rely on it. > > > > > We need > > > to address problems head-on, rather than avoid them. > > > > > > > So what solution are you proposing for the potential GP conflicts > > between the boot loader, the Linux EFI stub and the firmware? > > > The GP register values are now loaded in the arch/riscv/kernel/head.S > and arch/riscv/kernel/suspend_entry.S files. > > Let's think about EFI runtimeservice. If the EFI firmware code uses GP > registers but the compiler does not avoid GP, and kernel uses the > callback function provided by EFI, is there a problem? Is it possible > to solve the problem only by making the firmware code not use GP at > all and compiling options to avoid using GP? > EFI runtime services do not use callbacks, and execute in a context that is entirely owned by the OS. So this is one place where EFI firmware cannot use GP at all even if the UEFI spec permitted it. > The same goes for efistub. > Not really. The UEFI spec seems to suggest that *system* firmware should not touch GP or make any assumptions about its value, but it doesn't say anything about EFI applications such as the EFI stub or GRUB. > So the way to solve this problem is that the firmware does not use GP > optimization. Does this allow efistub to load the GP register? > What about GRUB or other bootloaders that are loaded before the kernel, but are still active while the EFI stub is executing? Who gets to own GP in this scenario?
