RISC-V UEFI/ACPI on QEMU regression?

[Simon Glass]

Hi Ilias,

On Thu, 3 Apr 2025 at 08:27, Ilias Apalodimas
<ilias.apalodimas at linaro.org> wrote:
>
> 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.

OK, well unfortunately for now all of my patches are based on my tree.
I would love that to change, but so far it has been my only option for
landing things, like bootstd migrations, EFI-app improvements, PXE
improvements and so on.

I can manually override this for individual patches (as I did with the
TPM patch). I also make sure to put an 'efi_loader' tag on each patch
related to that area, as you requested.

> >
> > 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/

Regards,
Simon