On Sat, 17 Oct 2026 at 14:31, Marcelo Manzo <[email protected]> wrote: > > On 17 Oct 2026, Peter Maydell wrote: > > > > Do you know what's missing for the MSI support to work? > > I think it's the controller's built-in MSI receiver, which we don't > model. > > From the Linux driver (drivers/pci/controller/pcie-brcmstb.c): the guest > programs an MSI target address into PCIE_MISC_MSI_BAR_CONFIG_LO/HI > (0x4044/0x4048, bit 0 = enable) and the message data into > PCIE_MISC_MSI_DATA_CONFIG (0x404c). A device's MSI write then goes to > that target address (0xfffffffc, or 0xffffffffc if the inbound window > extends above 4GB) with data 0x6540 | vector. The controller is supposed > to catch that write, set bit <vector> in its MSI_INTR2 block at 0x4500 > (STATUS 0x4500, CLR 0x4508, MASK_SET 0x4510, MASK_CLR 0x4514), and > assert the second interrupt of the pcie DT node ("msi") towards the GIC. > > Right now none of that exists: the MSI_INTR2 registers are plain backing > bytes in regs[] with no status/clear/mask behaviour, nothing in the PCI > bus address space claims the target address so the device's write goes > nowhere, and the "msi" interrupt isn't wired to the GIC. > > I think it needs a small doorbell MemoryRegion in the PCI address space > at the target address, the INTR2 register semantics, and one more SPI -- > on the order of 100-150 lines. I left it out of this series since INTx > covers what I've needed, but I'm happy to do it as a follow-up if you'd > like.
So if I understand right this is because the SoC doesn't implement MSI interrupts by having a GICv3 ITS or a GICv2m, but it does it in the PCIe controller ? Let's get the base support in before we think about implementing that. (The aspeed pcie controller also handles MSI interrupts, so we have some existing code models to look at if necessary.) Does the system end up with the "msi_nonbroken" global set to "false" or "true" ? I think since we don't have a gicv3 or gicv2m we ought to have it still at its default "false" value, but if it's false I'm not sure why we need to explicitly turn off MSIs with msi=off,msix=off. (This isn't worth spending too much time investigating, though.) Anyway for this patch Reviewed-by: Peter Maydell <[email protected]> thanks -- PMM
