Comment 37 for bug 1810239

ZhenHua, can you elaborate on this? Do you mean a device accessed the MMIO space used to program the IOMMU itself? If so, how did you conclude that? I doubt the IOMMU space is at address 0xfff00000.

Based on the following data:

  Paweł:
    DMAR:[DMA Read] Request device [0b:00.1] fault addr fff00000
    DMAR:[fault reason 02] Present bit in context entry is clear
    0b:00.0 [0106]: Marvell [1b4b:9123]
  Korneliusz:
    DMAR:[DMA Read] Request device [03:00.1] fault addr fffc0000
    DMAR:[fault reason 02] Present bit in context entry is clear
    03:00.0 [0106]: Marvell 88SE9123 SATA [1b4b:9123]
  Daniel:
    IOMMU identity map errors (assuming unrelated for now)
    DMAR:[DMA Read] Request device [01:00.1] fault addr fff00000
    DMAR:[fault reason 02] Present bit in context entry is clear
    01:00.0 [0106]: Marvell 88SE9123 SATA [1b4b:9123]
  Stijn:
    dmar: DMAR:[DMA Read] Request device [07:00.1] fault addr fff00000
    DMAR:[fault reason 02] Present bit in context entry is clear
    07:00.0 0106: 1b4b:9130 (rev 11) (prog-if 01 [AHCI 1.0])

in each case the IOMMU saw a DMA read to an address that wasn't mapped for the requesting device. In each case, the requester is function .1, the kernel doesn't know about a .1 function, and there is a Marvell 912x SATA control at the corresponding .0 function.

Andrew's Phantom Function theory seems like a good direction to explore. Maybe these devices incorrectly report Phantom Function support in the Device Capability & Control, and we just need some sort of quirk to work around that.

It would be interesting to know whether the .0 Marvell function has valid IOMMU mappings for the fault addresses (0xfff00000 or 0xfffc0000), or whether there is really anything at those addresses. They seem like dubious targets for DMA.