[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

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

Thanks,
Leo



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.