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

28 Oct 2021


      On Thu, Oct 28, 2021 at 3:19 PM Marc Zyngier maz@kernel.org wrote:
...
On Thu, 28 Oct 2021 10:20:53 +0100,
Bharat Gooty bharat.gooty@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.
...
...
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?
...
...
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.
And since your kernel is able to kexec, it obviously knows about the
...
reservation/pre-programming trick. This hardly makes any sense.
    M.


--
Without deviation from the norm, progress is not possible.
-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.