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
