RISC-V UEFI/ACPI on QEMU regression?

[Ilias Apalodimas]

On Wed, 2 Apr 2025 at 22:19, Simon Glass <sjg at chromium.org> wrote:
>
> Hi,
>
> On Thu, 3 Apr 2025 at 03:36, Ilias Apalodimas
> <ilias.apalodimas at linaro.org> wrote:
> >
> > On Wed, 2 Apr 2025 at 17:26, Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> > >
> > > Hey Bjorn
> > >
> > > Long time, hope all is well!
> > >
> > > On Wed, 2 Apr 2025 at 16:22, Björn Töpel <bjorn at kernel.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > I think I got a regression from commit 53d5a221632e ("emulation: Use
> > > > bloblist to hold tables"), and v2024.10 for
> > > > qemu-riscv64_smode_defconfig + acpi.config booting Linux with UEFI.
> > > >
> > > > TL;DR: It seems like the RSDP is placed in the wrong EFI memory map
> > > > type (it should be "ACPI Reclaim").
> > > >
> > > > I might also be misunderstanding what config fragments should be
> > > > used -- I'm out in the weeds here! ;-)
> > > >
> > > > When I was using v2024.10, ACPI RSDP was in ACPI Reclaim memory. All
> > > > good, and e.g. a kexec would properly work. However, when using u-boot
> > > > with commit 53d5a221632e ("emulation: Use bloblist to hold tables") I
> > > > get the following when booting, and then kexec:
> > > >
> > > > First kernel:
> > > > [    0.000000] ACPI: Early table checksum verification disabled
> > > >                                                   [    0.000000] ACPI:
> > > > RSDP 0x000000047EED3000 000024 (v02 BOCHS )
> > > > Kexec kernel:
> > > > [    0.000000] ACPI: Early table checksum verification disabled
> > > > [    0.000000] ACPI:      0x000000047EED3000 000000 (v00
> > > >   00000000      00000000)
> > > > [    0.000000] Oops - load access fault [#1]
> > > >
> > > > RSDP reside in:
> > > > [    0.000000] efi:   0x00047ded1000-0x00047eee3fff [Boot Code   |   |
> > > >  |  |  |  |  |  |  |  |  |   |WB|  |  |  ]
> > > >
> > > > (Boot Code vs ACPI Reclaimed)
> > > >
> > > > Now to get qemu-riscv64_smode_defconfig + acpi.config to build
> > > > post-2024.10, I needed to add the following fragments:
> > > >
> > > >   CONFIG_BLOBLIST=y
> > > >   CONFIG_BLOBLIST_ALLOC=y
> > > >   CONFIG_BLOBLIST_SIZE_RELOC=0x20000
> > > >
> > > > which is really just a "make the build not complain", guessing game
> > > > from my side.
> > > >
> > > > My guess would be that it's related to the change in
> > > > evt_write_acpi_tables(), where:
> > > >
> > > > -    ptr = memalign(SZ_4K, SZ_64K);
> > > > +    ptr = bloblist_add(BLOBLISTT_ACPI_TABLES, SZ_64K, 12);
> > > >
> > > > is done.
> > > >
> > > > Is my config fragment broken, or is this a proper regression?
> > >
> > > I think it's a regression and I think what breaks it is commit cfb4aa2a754ed1
>
> Yes, that's right. It was reported by Patrick Rudolph in mid-Feb and I
> sent a patch about a month ago [1]
>
> It seems to be in Heinrich's queue in patchwork.
>
> > >
> > > Can you apply the diff below and see if it fixes it for you?
> > >
> > > diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c
> > > index 4422b31ac6a7..afa5eee85484 100644
> > > --- a/lib/efi_loader/efi_acpi.c
> > > +++ b/lib/efi_loader/efi_acpi.c
> > > @@ -34,8 +34,8 @@ efi_status_t efi_acpi_register(void)
> > >          * add_u_boot_and_runtime(). At some point that function could create a
> > >          * more detailed map.
> > >          */
> > > -       if (IS_ENABLED(CONFIG_BLOBLIST_TABLES))
> > > -               return EFI_SUCCESS;
> > > +       //if (IS_ENABLED(CONFIG_BLOBLIST_TABLES))
> > > +               ////return EFI_SUCCESS;
> > >
> > >         /* Mark space used for tables */
> > >         start = ALIGN_DOWN(gd->arch.table_start, EFI_PAGE_MASK);
> > >
> > > Simon, why that PR got sent with no ACKs from any of the EFI maintainers?
>
> I didn't send a PR, but it's not clear that anyone would have spotted
> this bug as it is pretty subtle. It would be good to have testing for
> this case. We can actually do that by expanding the bootflow_efi()
> test.
>
> >
> > And please fix whatever tooling you use to CC the proper maintainers
> > next time [0] as I don't see my name in the CC list
>
> You had asked not to be cc'd on my patches anymore,

Are you sure?

> so I just cc
> Heinrich now, unless I manually override it.

I asked not to be cc'ed on patches that don't apply to -master or
-next and are for your tree. I obviously want to be CC'ed for anything
related to subsystems I help maintain.

Thanks
/Ilias

>  Let me know what you'd
> like me to do.
>
> Regards,
> Simon
>
> >
> > [0] https://lore.kernel.org/u-boot/20250111000029.245022-27-sjg@chromium.org/
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20250306143134.2549815-1-sjg@chromium.org/