On Tue, 30 Sept 2025 at 17:53, tangtao1634 <[email protected]> wrote: > The smmu-testdev is intentionally not a conformant, general-purpose PCIe > or platform device. It is a purpose-built, highly simplified "DMA engine." > I've designed it to be analogous to a minimal PCIe Root Complex that > bypasses the full, realistic topology (Host Bridges, Switches, Endpoints) > to provide a direct, programmable path for a DMA request to reach the SMMU. > Its sole purpose is to trigger a DMA transaction when its registers are > written to, making it perfectly suited for direct control from a test > environment like qtest.
This makes sense to me. But looking at the code it looks like the device itself has a lot of code for setting up IOMMU page tables in guest memory when the test code writes to its registers. That surprised me, as I was expecting the test device to essentially be "do DMA on command". Is there a reason why we can't have the test code do the setting up of the IOMMU page tables itself using the qtest functions for writing guest memory? (Obviously you'd abstract this out into functions for the purpose in libqos/ somewhere.) If we did it that way, we could use the same test device as part of non-SMMUv3 iommu emulation tests too -- the qtest test case code would just set up the different IOMMU in the way that IOMMU expects before triggering DMA. thanks -- PMM
