[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250422210705.GA382841@bhelgaas>
Date: Tue, 22 Apr 2025 16:07:05 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Jiri Slaby <jirislaby@...nel.org>, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org
Subject: IRQ domain logging?
Hi Thomas,
IRQ domains and IRQs are critical infrastructure, but we don't really
log anything when we discover controllers or set them up. Do you
think there would be any value in exposing some of this structure in
dmesg to help people (like me!) understand how these are connected to
devices and drivers?
For example, in a simple qemu system:
IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI: Interrupt link LNKA configured for IRQ 10
ACPI: PCI: Interrupt link GSIA configured for IRQ 16
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
ACPI: \_SB_.GSIA: Enabled at IRQ 16
pcieport 0000:00:1c.0: PME: Signaling with IRQ 24
00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
ata1: SATA max UDMA/133 abar m4096@...eadb000 port 0xfeadb100 irq 28 lpm-pol 0
I think these are all wired interrupts, and maybe IRQ==GSI (?), and I
think the ACPI link devices are configurable connections between an
INTx and the IOAPIC, but it's kind of hard to connect them all
together.
This from an arm64 system is even more obscure to me:
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
GICv3: 256 SPIs implemented
Root IRQ handler: gic_handle_irq
GICv3: GICv3 features: 16 PPIs
kvm [1]: vgic interrupt IRQ18
xhci-hcd xhci-hcd.0.auto: irq 67, io mem 0xfe800000
I have no clue where irq 67 goes.
Maybe there's no useful way to log anything here, I dunno; it just
occurred to me when looking at Jiri's series to reduce the number of
irqdomain interfaces. PCI controller drivers do a lot of interrupt
domain setup, and if that were more visible/concrete in dmesg, I think
I might understand it better.
Bjorn
Powered by blists - more mailing lists