Re: [PATCH] LoongArch: Add efistub booting support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 17 Aug 2022 at 09:17, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
>
> Hi, Ard,
>
> On Wed, Aug 17, 2022 at 3:00 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> >
> > On Wed, 17 Aug 2022 at 08:43, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> > >
> > > Hi, Ard,
> > >
> > > On Tue, Aug 16, 2022 at 11:32 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > > >
> > > > On Tue, 16 Aug 2022 at 17:23, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> > > > >
> > ...
> > > > >
> > > >
> > > > No that makes no difference. The point is that the EFI stub and the
> > > > core kernel are the same image, so when the stub runs, the core
> > > > kernel's screen_info already exists in memory - the only thing you
> > > > need to do is make it accessible by adding it to image-vars.h
> > > Emm,  in ARM64,
> > > #define alloc_screen_info(x...)         &screen_info
> > >
> > > So screen_info is a global variable in the core kernel. For the zboot
> > > case (our own implementation, not sure about the proposing new
> > > method), efistub may be able to fill this info, but while
> > > decompressing, screen_info will be overwritten. I think.
> > >
> >
> > Right. So you can drop it then.
> OK, then can we rename LINUX_EFI_ARM_SCREEN_INFO_TABLE_GUID to
> LINUX_EFI_SCREEN_INFO_TABLE_GUID and avoid define a dedicated GUID for
> each arch?
>

If you use the arm64 approach, you don't need a GUID at all.

...

> > > > > > This code is not checking a platform feature so it does not belong here.
> > > > > >
> > > > > > The EFI stub code is an ordinary EFI app, and it runs in the execution
> > > > > > context provided by EFI. So why is this needed so early? Can you move
> > > > > > it into the kernel entry routine instead?
> > > > > This is useful once we use our own zboot implementation, maybe we
> > > > > don't need it with the new method you are proposing.
> > > > >
> > > >
> > > > If this is part of your zboot implementation, please drop it for now.
> > > > Let's try using the generic EFI zboot instead - if we need to, we can
> > > > find a way to add it there.
> > > >
> > > > But out of curiosity, why is this needed at all?
> > > My mistake, the real reason of configuring DMW in stub is that the
> > > address of real_kernel_entry() is a kernel va, not a efi va (which is
> > > the same as pa).
> > >
> >
> > That means you can move this code to efi_enter_kernel(), no?
> Yes, we can move to efi_enter_kernel(), thank you.
>

OK



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux