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

[Ard Biesheuvel <ardb@xxxxxxxxxx>]

On Thu, 18 Aug 2022 at 17:49, Leo Yan <leo.yan@xxxxxxxxxx> wrote:
>
> On Thu, Aug 18, 2022 at 11:04:48AM +0100, Julien Grall wrote:
>
> [...]
>
> > > > 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?
>
>
> Now I am working on automative reference platform; the first thing for
> me is to resolve the kernel oops.
>
> For long term, I think the kexec/kdump would be important to be
> supported, to be clear, so far supporting kexec/kdump for Xen/Linux is
> not priority for my work.
>
> Also thanks a lot for Ard and Mark's replying. To be honest, I missed
> many prerequisites (e.g. redistributor configurations for GIC in
> hypervisor) and seems Xen uses a different way by emulating GICv3
> controller for guest OS.  So now I am bit puzzle what's for next step
> or just keep as it is?
>

If i understand Julien's remark correctly, the dom0 GICv3 is emulated,
and so it should not suffer from the issue that we are working around
here.

Given that this workaround is still the sole user of the MEMRESERVE
API, we would like to remain free to rip it out and replace it
completely if we need to, and so implementing it in Xen is a bad idea,
especially if the issue in question does not even exist in your case.
This means that even if you do decide to support kexec, things should
work fine in spite of this warning regarding the failure to perform
the memory reservation, as the GIC can simply be reconfigured.

So perhaps we should just [conditionally] tone down the warning?