A VFIO PCI dmabuf mapped into an IOAS gets IOMMU_MMIO only in the domains that exist when it is mapped. A domain attached afterwards, or an IOMMU_IOAS_COPY of the area, reads the PFNs back from the existing domain and maps the BAR as cacheable CPU memory. Patch 1 always takes dmabuf PFNs from the recorded phys range instead.
Sashiko first reported this on patch 6 of David Woodhouse's RFC "KVM: Allow alternative providers of guest_memfd backed by PFNMAP memory", which picks the batch kind in pfn_reader_fill_dmabuf() from the exporter's memory type. This fix does not depend on that series and combines with it: with both, a domain added later gets the kind the exporter reports. The mock page table has no memory type bits, so the existing selftests cannot see the difference. Patch 2 makes the mock record, per domain, the pages mapped with IOMMU_MMIO, adds IOMMU_TEST_OP_MD_CHECK_MMIO, and checks the domain filled later in two new tests, dmabuf_mmio_new_domain and dmabuf_mmio_copy. Tested on x86-64 under virtme-ng with CONFIG_IOMMUFD_TEST=y. Without patch 1 both new tests fail on the second domain in all three mock domain variants; in dmabuf_mmio_new_domain, a temporary print in batch_to_domain() showed that domain mapped with IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE, where the first got IOMMU_READ | IOMMU_WRITE | IOMMU_MMIO. With patch 1 the dmabuf tests pass. Not tested on hardware that uses the memory type bits (ARM SMMUv3, AMD with SME, RISC-V). Andrea Parri (2): iommufd: Keep dmabuf PFNs MMIO when filling another domain iommufd/selftest: Check dmabuf MMIO mappings filled from another domain drivers/iommu/iommufd/iommufd_test.h | 5 ++ drivers/iommu/iommufd/pages.c | 13 ++- drivers/iommu/iommufd/selftest.c | 90 +++++++++++++++++++ tools/testing/selftests/iommu/iommufd.c | 51 +++++++++++ tools/testing/selftests/iommu/iommufd_utils.h | 13 +++ 5 files changed, 168 insertions(+), 4 deletions(-) -- 2.53.0
