Re: [PATCH v2 2/2] PCI: dwc: ep: Fix unmap potentially unmapping the wrong iATU

On Thu, Jul 30, 2026 at 01:51:16PM +0000, [email protected] wrote:
> New issues:
> - [High] Using `readl()` on the host's MSI target address to flush posted writes generates a dangerous PCIe Memory Read Request, causing kernel panics.

(snip)

> [Severity: High]
> Does using readl() on the host's MSI target address generate a dangerous
> non-posted PCIe Memory Read Request?
> 
> Most host interrupt controllers (like GIC ITS or APIC) do not support reads
> to their doorbell addresses and will reply with an Unsupported Request (UR).
> 
> The DWC controller translates the UR completion into an AXI Slave Error,
> which can trigger a synchronous external abort and kernel panic on the
> endpoint CPU.
> 
> This concern applies to flushing posted writes in both
> dw_pcie_ep_raise_msix_irq() and dw_pcie_ep_raise_msi_irq().
> 
> > +		dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->msi_mem_phys);
> > +		ep->msi_iatu_mapped = false;
> > +	}
> > +
> >  	msg_addr = dw_pcie_ep_align_addr(epc, msg_addr, &map_size, &offset);
> 

I don't see how this comment is valid.

I tested this patch with two Rock 5Bs, one in EP mode and one in RC mode.

The PCIe controller on the host:
https://github.com/torvalds/linux/blob/v7.2-rc5/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi#L370
is indeed using GIC ITS, and I saw no issues at all.

Additionally, we have already been doing a readl() on the MSI-X target
address, for every single MSI-X, since commit c22533c66cca ("PCI: dwc: ep:
Flush MSI-X write before unmapping its ATU entry"), first included in
v7.0-rc2, and not a single soul has complained since then.

So personally I am not too concerned.


Kind regards,
Niklas