On 17 Oct 2026, Peter Maydell wrote: > > Does the system end up with the "msi_nonbroken" global set to > "false" or "true" ?
It ends up true. aspeed_pcie_rc_class_init() sets msi_nonbroken, and class_init runs for every class at startup, so any qemu-system-aarch64 has it set whichever machine is selected. That's why qemu-xhci ends up with MSI-X enabled and needs msix=off. thanks for the R-b -- Marcelo On Sat, Oct 17, 2026 10:24 AM, Peter Maydell <[email protected]> wrote: > 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 >
