Re: [PATCH] xen/arm: acpi: Support memory reserve configuration table

[Marc Zyngier <maz@xxxxxxxxxx>]

On Thu, 18 Aug 2022 10:15:30 +0100,
Leo Yan <leo.yan@xxxxxxxxxx> wrote:
> 
> Hi Ard,
> 
> On Wed, Aug 17, 2022 at 03:49:32PM +0200, Ard Biesheuvel wrote:
> 
> [...]
> 
> > > This header holds ACPI spec defined data structures. This one looks
> > > to be a Linux one, and hence shouldn't be defined here. You use it
> > > in a single CU only, so I see no reason to define it there.
> > >
> > > Furthermore - what if Linux decided to change their structure? Or
> > > is there a guarantee that they won't?
> > 
> > No, there is not. The memreserve table is an internal interface
> > between the EFI stub loader and the Linux kernel proper.
> > 
> > As I have argued many times before, booting the arm64 kernel in
> > EFI/ACPI mode without going through the EFI stub violates the ACPI
> > spec, and relies on interfaces that were not intended for public
> > consumption.
> 
> Let me ask a question but sorry it might be off topic.
> 
> In the Linux kernel function:
> 
>   static int gic_reserve_range(phys_addr_t addr, unsigned long size)
>   {
>           if (efi_enabled(EFI_CONFIG_TABLES))
>                   return efi_mem_reserve_persistent(addr, size);
>   
>           return 0;
>   }
> 
> We can see it will reserve persistent memory region for GIC pending
> pages, so my question is if a platform is booting with DT binding
> rather than ACPI table, how the primary kernel can reserve the pages
> and pass the info to the secondary kernel?

This is a false dichotomy. DT and UEFI are not exclusive, far from
it. That's actually how most non-ACPI systems boot these days, and
they are able to use kexec out of the box, using the EFI MEMRESERVE
internal API.

The real difference is between UEFI and non-UEFI. If you're allergic
to it, you have two options:

- you delegate the redistributor configuration to your bootloader,
  mark the corresponding memory as reserved in the DT from the
  bootloader, and you're done. A bunch of embedded systems do that,
  and are able to kexec.

- you keep configuring the RDs from Linux, but you must then mark the
  regions as reserved in the DT that is passed to the secondary
  kernel. It requires some cooperation from the kexec userspace to
  parse /proc/iomem and insert the correct annotations in that DT.

> Seems it's broken for kdump/kexec if kernel boots with using DT?

You equate kexec to kdump, which is wrong. kdump does *not* reuse the
memory from the previous kernel, and thus is immune to the RD table
reallocation problem. You don't need anything for kdump, as you will
use the RD tables as configured by the initial kernel.

        M.

-- 
Without deviation from the norm, progress is not possible.