Re: [PATCH v4 03/48] irqchip/gic-v5: Set up gic_kvm_info on ACPI hosts

Sascha Bischoff <[email protected]> Fri, 31 Jul 2026 07:18:28 +0000
Newsgroups dev.linux.lists.sashiko-reviews,dev.linux.lists.kvmarm,org.kernel.vger.kvm
Message-ID <[email protected]>
On Sat, 2026-07-25 at 11:08 +0100, Marc Zyngier wrote:
> On Fri, 24 Jul 2026 12:19:20 +0100,
> [email protected] wrote:
> > 
> > Thank you for your contribution! Sashiko AI review found 1
> > potential issue(s) to consider:
> > - [High] Failed ACPI GSI registration for maintenance IRQ due to
> > missing GICv5 hardware IRQ type encoding.
> > --
> 
> [...]
> 
> > [Severity: High]
> > Does this fail to register the maintenance IRQ?
> > 
> > acpi_register_gsi() passes the raw maint_irq directly into
> > fwspec.param[0].
> > However, the GICv5 PPI domain select function expects the hardware
> > IRQ type to
> > be encoded in the upper bits:
> > 
> > drivers/irqchip/irq-gic-v5.c:gicv5_irq_ppi_domain_select() {
> >     ...
> >     if (is_fwnode_irqchip(fwspec->fwnode))
> >         hwirq_type = FIELD_GET(GICV5_HWIRQ_TYPE, fwspec->param[0]);
> > 
> >     if (hwirq_type != GICV5_HWIRQ_TYPE_PPI)
> >         return 0;
> >     ...
> > }
> > 
> > Because the raw MADT value doesn't have the GICV5_HWIRQ_TYPE_PPI
> > bits set, the
> > mapping will be rejected. Should the GSI be encoded with the PPI
> > type before
> > calling acpi_register_gsi()?
> 
> Where is this coming from? I can't even find any public documentation
> for ACPI GICv5 support...

And nor can Sashiko, so it is very much falling back on what it would
expect for older GICs with range-based interrupts, like GICv3.

My changes are based on (and have been tested against) the GICv5 ACPI
support being added to EDK2 which can be found at
https://github.com/tianocore/edk2/pull/11998 and
https://github.com/tianocore/edk2-platforms/pull/931

In v2, I'd explicitly re-encoded the GSI as a GICv5 PPI, but dropped
that in response to a comment from (and offline discussion with
Lorenzo) - the GSI should already be encoded as a GICv5 PPI, i.e. with
the upper Type bits set appropriately. See
https://lore.kernel.org/all/ahfraE2vVsZL2xcs@lpieralisi/ It wouldn't
have been wrong with that re-encoding present but it was superfluous,
and hence I dropped it. 

FWIW, the edk2-platforms GICv5 support for the FVP explicitly encodes
the VGIC_IRQ (so MI) as:

#define FVP_GICV5_VGIC_IRQ                    (GICV5_INTERRUPT_TYPE_PPI | 0x19)

See [1] for the full diff, if interested.

> 
> Sascha?
> 
> 	M.
> 

Thanks,
Sascha

[1]
https://github.com/tianocore/edk2-platforms/pull/931/files#diff-8684c9dce4102bc04796f786c5672915935c9853905c25de589ed8d810cd512fR112