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

[Leo Yan <leo.yan@xxxxxxxxxx>]

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?

Thanks,
Leo