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