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

[Julien Grall <julien@xxxxxxx>]

Hi Ard,

On 18/08/2022 10:33, Ard Biesheuvel wrote:
> On Thu, 18 Aug 2022 at 11:15, 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?
> >
> > Seems it's broken for kdump/kexec if kernel boots with using DT?
> EFI supports both DT and ACPI boot, but only ACPI *requires* EFI.
>
> So DT boot on hardware with affected GICv3 implementations works fine
> with kdump/kexec as long as EFI is being used. Using non-EFI boot and
> kexec on such systems will likely result in a splat on the second
> kernel, unless there is another mechanism being used to reserve the
> memory in DT as well.
>
> Maybe we should wire up the EFI_PARAVIRT flag for Xen dom0 on arm64,
> so that we can filter out the call above. That would mean that
> Xen/arm64/dom0/kexec on affected hardware would result in a splat in
> the second kernel as well, but whether that matters depends on your
> support scope.
In the context of Xen, dom0 doesn't have direct access to the host ITS 
because we are emulating it. So I think it doesn't matter for us because 
we can fix our implementation if it is affected.
That said, kexec-ing dom0 (or any other domain) on Xen on Arm would 
require some work to be supported. OOI, @leo is it something you are 
investigating?
Cheers,

--
Julien Grall