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

Sascha Bischoff <[email protected]>
Newsgroups dev.linux.lists.kvmarm,dev.linux.lists.sashiko-reviews,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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.