Hi, > On 11 Aug 2022, at 16:05, Ard Biesheuvel <a...@kernel.org> wrote: > > On Thu, 11 Aug 2022 at 16:59, Bertrand Marquis <bertrand.marq...@arm.com> > wrote: >> >> Hi Leon, >> >>> On 11 Aug 2022, at 15:17, Leo Yan <leo....@linaro.org> 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.si...@arm.com> 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)
I agree with that in the long term we should find a solution to remove this system and have something more compliant with EFI/ACPI in Xen. > > 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. Currently the EFI system table is passed using a device tree generated by Xen. To add support right now we would need to make the table available to dom0 and pass its address inside this device tree. Cheers Bertrand > > -- > Ard.
