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

[Marc Zyngier <maz@xxxxxxxxxx>]

On Thu, 18 Aug 2022 17:24:31 +0100,
Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> 
> 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.

The problem is that there is no way to distinguish a system that
suffers from GICR LPI tables being immutable from one that allows the
LPI configuration being changed (either because the HW allows it or
because the hypervisor plays other games).

Once you're in the secondary kernel with the RDs enabled, you have
already lost if there is a chance you could have reused this memory,
and that's irrespective of being a guest or bare metal (interrupt
delivery should still work during kexec).

> 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?

What we could do instead is to have some form of kexec hook that tries
to go and turn the RDs off before jumping into the secondary kernel.
If the hypervisor allows this (and honours the GICR_CTLR.EnableLPI
bit), then there won't be any screaming in the secondary kernel.

This is probably a new infrastructure though, as I don't think we have
anything of the sort at the moment.

Thanks,

        M.

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