Re: Question: Enable LINUX_EFI_MEMRESERVE_TABLE_GUID in EFI

[Ard Biesheuvel <ardb@xxxxxxxxxx>]

On Thu, 11 Aug 2022 at 16:59, Bertrand Marquis <Bertrand.Marquis@xxxxxxx> wrote:
>
> Hi Leon,
>
> > On 11 Aug 2022, at 15:17, Leo Yan <leo.yan@xxxxxxxxxx> wrote:
> >
> > Hi Bertrand, Rahul,
> >
> > On Fri, Aug 05, 2022 at 12:05:23PM +0000, Bertrand Marquis wrote:
> >>> On 5 Aug 2022, at 12:44, Rahul Singh <Rahul.Singh@xxxxxxx> wrote:
> >
> > [...]
> >
> >>>> Looked into the code, the GICv3 driver tries to create persistent
> >>>> reservations for pending pages, and the persistent reservation table
> >>>> can be used by kexec/kdump.  For the persistent reservations, it
> >>>> relies on MEMRESERVE EFI configuration table, but this table is not
> >>>> supported by xen.efi, I think this is the reason for the above oops.
> >>>
> >>> Yes, you are right above warning is observed because Xen does not support
> >>> memreserve efi table. I also observed a similar warning on the N1SDP 
> >>> board.
> >>>>
> >>>> I checked that if I boot a host Linux (without Xen), then the EFI has
> >>>> provided MEMRESERVE configuration table, I can get below log:
> >>>>
> >>>> #  dmesg | grep MEMRESERVE
> >>>> [    0.000000] efi: TPMFinalLog=0x807f9ef0000 ACPI 2.0=0x807fa0d0018 ... 
> >>>> MEMRESERVE=0x807f8141e98
> >>>>
> >>>> Just want to confirm, is anyone working on enabling MEMRESERVE EFI
> >>>> configuration table for Xen?  And welcome any comments and
> >>>> suggestions!
> >>>>
> >>
> >> No I do not think anybody is working on this at the moment.
> >> If you want to work on adding support for this in Xen, we can provide 
> >> support
> >> and help on reviewing and testing as we have several targets on which we
> >> observe this (N1SDP and Ava).
> >
> > Thanks for your quick response.
> >
> > I took time to look into the code, below are my conclusions.
> >
> > For a normal UEFI boot flow, UEFI will invoke Linux kernel's EFI stub,
> > and the EFI stub will install MEMRESERVE EFI configuration table.
> > This is accomplished in the Linux function install_memreserve_table().
> >
> > Secondly, Xen passes DT to kernel, it synthesizes ACPI compatible
> > nodes in the device tree and finally kernel parses DT and create the
> > ACPI table.  In this case, Xen doesn't invoke Linux EFI stub.
> >
> > To be honest, I have very less knowledge for Xen and APCI; just based on
> > reading code, I think it's hard for Xen to invoke Linux kernel's EFI
> > stub, this is because Xen needs to provide the EFI runtime services, and
> > I don't think it's feasible for Xen to pass through UEFI's runtime
> > service to Linux kernel.  If we implement the EFI runtime services for
> > Xen, then this would introduce a big implementation.
> >
> > So another option is we simply add MEMRESERVE EFI configuration table
> > into device tree, just like Xen does for other ACPI tables (e.g.
> > RSDP?).  And then in Linux kernel, we need to parse the DT binding and
> > initialize the corresponding variables in kernel, so we need to add
> > support in the Linux source drivers/firmware/efi/fdtparams.c.
> >
> > Before I proceed, just want to check which option would be the right
> > way to move forward?  And I am open for any other solution and welcome
> > suggestions.
>
> When Xen is started using EFI, Linux is then started purely using device tree
> there is a standard way to define reserved memory to linux using the device
> tree and Xen should decode the Memreserve entry from EFI and add the
> corresponding entry in the device tree that we give to linux.
>

This is not what MEMRESERVE is used for. Specifying reservations for
the current boot is straight-forward. What MEMRESERVE does is specify
a reservation that survives kexec and is passed on to the next
kernel(s), as the table is anchored in a structure that is created by
the EFI stub on the first boot. This is needed for the GICv3 on some
platforms, as memory that Linux reserves for its interrupt tables can
never be released again, even across kexec, which means that the GICv3
will be DMA'ing into that memory if the kexec kernel wants it or not)

I'd strongly recommend against doing any of the things Xen does for
ACPI boot today: both the ACPI spec and the kernel documentation about
ACPI support in the arm64 port is 100% clear that EFI boot is the only
supported boot method. Issues like this one would have never popped up
if those rules were adhered to. (/pedantic mode off)

In your case, this is a matter of allocating a structure of the right
type and size, and making it available via the configuration table
array in the EFI system table that the dom0 kernel receives from Xen
at boot.

Please don't add DT entries for this - we should be able to cover this
using the existing pseudo-EFI boot flow that Xen uses today.

-- 
Ard.