[PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree

[Marc Zyngier]

On Thu, 28 Oct 2021 11:27:44 +0100,
Bharat Gooty <bharat.gooty at broadcom.com> wrote:
> 
> [1  <text/plain; UTF-8 (7bit)>]
> On Thu, Oct 28, 2021 at 3:19 PM Marc Zyngier <maz at kernel.org> wrote:
> 
> > On Thu, 28 Oct 2021 10:20:53 +0100,
> > Bharat Gooty <bharat.gooty at broadcom.com> wrote:
> > >
> > > For GIC V3, once the LPI tables are programmed, we can not update it,
> > > unless we do a reset.
> >
> > Please tell me something I don't know...
> >
> > For GIC V3 , once the Locality specific peripheral interrupts (LPI) table
> is programmed and enabled, unless the GIC is reset, we can not re-program
> the LPI tables. For these reasons, reserve the memory and program the GIC
> redistributor PROPBASER and LPI_PENDBASE registers.
> If we do not program the LPI table in the bootloader, during the Linux
> boot, Linux will allocate the LPI table memory. Assume you want to boot a
> new kernel and do the kexec kernel. For the kexec kernel boot, Linux will
> again allocate the LPI table memory. But writing to the GIC registers will
> fail. As the LPI for the redistributors is already enabled by the previous
> Linux kernel, unless we do GIC reset, we can not update the LPI
> tables.

This really was a rhetorical question. I am painfully aware of most of
the GIC's "features", having dealt with it in Linux and at the
architecture level for the past 10+ years.

> 
> 
> > > For the kexec kernel, where the reboot does not happen, in this case,
> > > during the new kernel boot, the new LPI tables address will not be
> > updated.
> >
> > Since July 2018, the Linux kernel is perfectly able to deal with this
> > without any extra support. It will communicate the reservation to the
> > secondary kernel, and the secondary kernel will happily use this.
> >
> > Can you specify the kernel version and the GIC versions which were used?

Any kernel containing this commit:

commit 5e2c9f9a627772672accd80fa15359c0de6aa894
Author: Marc Zyngier <maz at kernel.org>
Date:   Fri Jul 27 16:23:18 2018 +0100

    irqchip/gic-v3-its: Allow use of LPI tables in reserved memory
    
    If the LPI tables have been reserved with the EFI reservation
    mechanism, we assume that these tables are safe to use even
    when we find the redistributors to have LPIs enabled at
    boot time, meaning that kexec can now work with GICv3.
    
    You're welcome.
    
    Tested-by: Jeremy Linton <jeremy.linton at arm.com>
    Tested-by: Bhupesh Sharma <bhsharma at redhat.com>
    Tested-by: Lei Zhang <zhang.lei at jp.fujitsu.com>
    Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>

And the version of the IP doesn't matter at all.

> 
> > > For these reasons, We allocate the LPI table memory in u-boot and
> > > reserve that memory.
> >
> > What sort of antiquated kernel are you using? And even if you are
> > running something that predates the kernel changes, reserving the
> > memory in the DT serves the same purpose. Why the custom node
> > declaring the allocation?
> >
> > Tried using LTS 5.4 and 5.9 Linux kernels. Problem is updating the GIC V3
> registers with the new LPI table memory after enabling the LPI for the
> redistributors.

Then you are doing something wrong. There are two cases that work:

(1) You are using EFI: nothing to do. The kernel will reserve the
    memory, configure the RDs, and the secondary kernel will happily
    use the same memory, as the address is conveyed in an EFI-specific
    table, without attempting to reprogram the RDs

(2) You are not using EFI, and you need to reserve the memory *using
    the appropriate DT reservation mechanism* as well as program the
    RDs. The kernel will detect the reservation, and will not attempt
    to reprogram the RDs.

If you invent your own binding, use another reservation mechanism or
otherwise, this will not work. u-boot shouldn't expose this syscon
node, because it makes no sense at all, and no upstream software knows
about it. This code must die.

	M.

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