RFC iommutests_: Testing software for everything IOMMU

Joel Granados joel.granados at kernel.org
Fri Apr 4 05:37:48 PDT 2025


On Tue, Apr 01, 2025 at 11:35:19AM +0100, Jean-Philippe Brucker wrote:
> On Fri, Mar 28, 2025 at 10:11:13AM +0100, Joel Granados wrote:
> > Custom qemu device: pci-ats-testdev
> > -------------------------------------
> > To support IOMMU testing under qemu, the pci-ats-testdev [10]
> > (different from pci-testdev [11]) was used to emulate DMA transactions.
> > It is a full fledged pci device capable of executing emulated DMA
> > accesses. It was originally intended to test Linux kernel interactions
> > with devices that had a working Address Translation Cache (ATC) but can
> > become a platform capable of testing anything PCI/IOMMU related if
> > needed.
> 
> Yes please!  Maybe "pcie-testdev" rather than "pci-ats-testdev"?  There
Definitely. If it is a more general pcie test framework, we need to
change the name to something like that; agreed.

> are other PCIe features that are poorly tested at the moment, for example
> PASID and PRI. The programming model of devices that actually implement
Actually, PRI was what we used it for. I have this as one of the
potential next steps for iommutests.

> those can get too complex so we need something simpler to precisely stress
> the IOMMU driver infrastructure. Driver unit-tests alone aren't good
> enough for exercising TLB invalidation (DMA after removing a mapping must
> crash), tricky cleanup paths (eg. killing a process bound to a device
> that's issuing page requests), runtime PM, MSIs etc. I'm guessing testing
Totally agree. PRI is tricky to test indeed.

> newer/future features like TDISP would also benefit from a simple device.
> 
> Some time back I needed a device like that to reproduce some tricky races
> but never got round to implementing extra PCIe features. Although this one
> [1] is based on virtio any programming interface should work as long as it
> can instruct the device to send precise DMA transactions, ideally many in
> parallel.
And it can be up-streamed to QEMU if it ends up being used for linux
kernel testing.

Best

-- 

Joel Granados



More information about the linux-riscv mailing list