On Fri, Apr 10, 2020 at 9:22 AM Lu Baolu <baolu.lu@xxxxxxxxxxxxxxx> wrote: > This is caused by the fragile private domain implementation. We are in > process of removing it by enhancing the iommu subsystem with per-group > default domain. > > https://www.spinics.net/lists/iommu/msg42976.html > > So ultimately VMD subdevices should have their own per-device iommu data > and support per-device dma ops. Interesting. There's also this patchset you posted: [PATCH 00/19] [PULL REQUEST] iommu/vt-d: patches for v5.7 https://lists.linuxfoundation.org/pipermail/iommu/2020-April/042967.html (to be pushed out to 5.8) In there you have: > iommu/vt-d: Don't force 32bit devices to uses DMA domain which seems to clash with the approach being explored in this thread. And: > iommu/vt-d: Apply per-device dma_ops This effectively solves the trip point that caused me to open these discussions, where intel_map_page() -> iommu_need_mapping() would incorrectly determine that a intel-iommu DMA mapping was needed for a PCI subdevice running in identity mode. After this patch, a PCI subdevice in identity mode uses the default system dma_ops and completely avoids intel-iommu. So that solves the issues I was looking at. Jon, you might want to check if the problems you see are likewise solved for you by these patches. I didn't try Joerg's iommu group rework yet as it conflicts with those patches above. Daniel
