Re: [PATCH] LoongArch: Add efistub booting support

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

 



Hi, Ard,

On Wed, Aug 17, 2022 at 3:18 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>
> 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.
Oh, I misunderstood.
OK, I will use the arm64 approach now, my problem only exists when the
order is "stub, decompression, core-kernel". If the new zboot way is
"decompression, stub, core-kernel", then there is no problem.

Huacai
>
> ...
>
> > > > > > > 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 ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux