kernel/include/linux/irqchip/arm-gic-v3.h, branch linux-rolling-stable

irqchip/gic-v3-its: Limit number of per-device MSIs to the range the ITS supports

2026-03-19T15:15:15Z

commit ce9e40a9a5e5cff0b1b0d2fa582b3d71a8ce68e8 upstream. The ITS driver blindly assumes that EventIDs are in abundant supply, to the point where it never checks how many the hardware actually supports. It turns out that some pretty esoteric integrations make it so that only a few bits are available, all the way down to a single bit. Enforce the advertised limitation at the point of allocating the device structure, and hope that the endpoint driver can deal with such limitation. Fixes: 84a6a2e7fc18d ("irqchip: GICv3: ITS: device allocation and configuration") Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Reviewed-by: Robin Murphy Reviewed-by: Zenghui Yu Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260206154816.3582887-1-maz@kernel.org Signed-off-by: Greg Kroah-Hartman

irqchip/gic-v3: Make distributor priorities variables

2024-06-24T17:16:44Z

In subsequent patches the GICv3 driver will choose the regular interrupt priority at boot time. In preparation for using dynamic priorities, place the priorities in variables and update the code to pass these as parameters. Users of GICD_INT_DEF_PRI_X4 are modified to replicate the priority byte using REPEAT_BYTE_U32(). There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Cc: Alexandru Elisei Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Will Deacon Reviewed-by: Marc Zyngier Tested-by: Marc Zyngier Link: https://lore.kernel.org/r/20240617111841.2529370-4-mark.rutland@arm.com Signed-off-by: Catalin Marinas Acked-by: Thomas Gleixner

irqchip/gic-v3: Exposes bit values for GICR_CTLR.{IR, CES}

2022-05-04T13:09:52Z

As we're about to expose GICR_CTLR.{IR,CES} to guests, populate the include file with the architectural values. Signed-off-by: Marc Zyngier Reviewed-by: Oliver Upton Link: https://lore.kernel.org/r/20220405182327.205520-2-maz@kernel.org

irqchip/gic-v3-its: Limit memreserve cpuhp state lifetime

2021-12-16T13:21:12Z

The new memreserve cpuhp callback only needs to survive up until a point where every CPU in the system has booted once. Beyond that, it becomes a no-op and can be put in the bin. Signed-off-by: Valentin Schneider Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20211027151506.2085066-4-valentin.schneider@arm.com

irqchip/gic-v3-its: Postpone LPI pending table freeing and memreserve

2021-12-16T13:21:11Z

Memory used by the LPI tables have to be made persistent for kexec to have a chance to work, as explained in [1]. If they have been made persistent and we are booting into a kexec'd kernel, we also need to free the pages that were preemptively allocated by the new kernel for those tables. Both of those operations currently happen during its_cpu_init(), which happens in a _STARTING (IOW atomic) cpuhp callback for secondary CPUs. efi_mem_reserve_iomem() issues a GFP_ATOMIC allocation, which unfortunately doesn't work under PREEMPT_RT (this ends up grabbing a non-raw spinlock, which can sleep under PREEMPT_RT). Similarly, freeing the pages ends up grabbing a sleepable spinlock. Since the memreserve is only required by kexec, it doesn't have to be done so early in the secondary boot process. Issue the reservation in a new CPUHP_AP_ONLINE_DYN cpuhp callback, and piggy-back the page freeing on top of it. A CPU gets to run the body of this new callback exactly once. As kexec issues a machine_shutdown() prior to machine_kexec(), it will be serialized vs a CPU being plugged to life by the hotplug machinery - either the CPU will have been brought up and have had its redistributor's pending table memreserved, or it never went online and will have its table allocated by the new kernel. [1]: https://lore.kernel.org/lkml/20180921195954.21574-1-marc.zyngier@arm.com/ Signed-off-by: Valentin Schneider Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20211027151506.2085066-3-valentin.schneider@arm.com

irqchip/gic-v3-its: Give the percpu rdist struct its own flags field

2021-12-16T13:21:11Z

Later patches will require tracking some per-rdist status. Reuse the bytes "lost" to padding within the __percpu rdist struct as a flags field, and re-encode ->lpi_enabled within said flags. No change in functionality intended. Signed-off-by: Valentin Schneider Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20211027151506.2085066-2-valentin.schneider@arm.com

arm64: Move ICH_ sysreg bits from arm-gic-v3.h to sysreg.h

2021-04-08T11:18:41Z

These definitions are in arm-gic-v3.h for historical reasons which no longer apply. Move them to sysreg.h so the AIC driver can use them, as it needs to peek into vGIC registers to deal with the GIC maintentance interrupt. Acked-by: Marc Zyngier Acked-by: Will Deacon Signed-off-by: Hector Martin

irqchip/gic-v3: Remove unused register definition

2020-07-27T07:55:03Z

[maz: The GICv3 spec has evolved quite a bit since the draft the Linux driver was written against, and some register definitions are simply gone] As per the GICv3 specification, GIC{D,R}_SEIR are not assigned and the locations (0x0068) are actually Reserved. GICR_MOV{LPI,ALL}R are two IMP DEF registers and might be defined by some specific micro-architecture. As they're not used anywhere in the kernel, just drop all of them. Signed-off-by: Zenghui Yu [maz: added context explaination] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20200630134126.880-1-yuzenghui@huawei.com

irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling

2020-04-16T09:28:12Z

When a vPE is made resident, the GIC starts parsing the virtual pending table to deliver pending interrupts. This takes place asynchronously, and can at times take a long while. Long enough that the vcpu enters the guest and hits WFI before any interrupt has been signaled yet. The vcpu then exits, blocks, and now gets a doorbell. Rince, repeat. In order to avoid the above, a (optional on GICv4, mandatory on v4.1) feature allows the GIC to feedback to the hypervisor whether it is done parsing the VPT by clearing the GICR_VPENDBASER.Dirty bit. The hypervisor can then wait until the GIC is ready before actually running the vPE. Plug the detection code as well as polling on vPE schedule. While at it, tidy-up the kernel message that displays the GICv4 optional features. Reviewed-by: Zenghui Yu Signed-off-by: Marc Zyngier

Merge branch 'irq/gic-v4.1' into irq/irqchip-next

2020-03-24T12:43:47Z

Signed-off-by: Marc Zyngier