RISC-V UEFI/ACPI on QEMU regression?

[Simon Glass]

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, so I just cc
Heinrich now, unless I manually override it. 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/