tangtao1634 <[email protected]> writes: > From: Tao Tang <[email protected]> > > This patch series (V2) introduces several cleanups and improvements to the > smmu-testdev device. The main goals are to refactor shared code, enhance > robustness, and significantly clarify the complex page table construction > used for testing. > > Motivation > ---------- > > Currently, thoroughly testing the SMMUv3 emulation requires a significant > software stack. We need to boot a full guest operating system (like Linux) > with the appropriate drivers (e.g., IOMMUFD) and rely on firmware (e.g., > ACPI with IORT tables or Hafnium) to correctly configure the SMMU and > orchestrate DMA from a peripheral device. > > This dependency on a complex software stack presents several challenges: > > * High Barrier to Entry: Writing targeted tests for specific SMMU > features (like fault handling, specific translation regimes, etc.) > becomes cumbersome. > > * Difficult to Debug: It's hard to distinguish whether a bug originates > from the SMMU emulation itself, the guest driver, the firmware > tables, or the guest kernel's configuration. > > * Slow Iteration: The need to boot a full guest OS slows down the > development and testing cycle. > > The primary goal of this work is to create a lightweight, self-contained > testing environment that allows us to exercise the SMMU's core logic > directly at the qtest level, removing the need for any guest-side > software.
I agree, an excellent motivation. > > Our Approach: A Dedicated Test Device > ------------------------------------- > > To achieve this, we introduce two main components: > > * A new, minimal hardware device: smmu-testdev. > * A corresponding qtest that drives this device to generate SMMU-bound > traffic. > > A key question is, "Why introduce a new smmu-testdev instead of using an > existing PCIe or platform device?" I curious what the split between PCIe and platform devices that need an SMMU are. I suspect there is a strong split between the virtualisation case and the emulation case. > The answer lies in our goal to minimize complexity. Standard devices, > whether PCIe or platform, come with their own intricate initialization > protocols and often require a complex driver state machine to function. > Using them would re-introduce the very driver-level complexity we aim to > avoid. > > 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. > > The Qtest Framework > ------------------- > > The new qtest (smmu-testdev-qtest.c) serves as the "bare-metal driver" > for both the SMMU and the smmu-testdev. It manually performs all the > setup that would typically be handled by the guest kernel and firmware, > but in a completely controlled and predictable manner: > > 1. SMMU Configuration: It directly initializes the SMMU's registers to a > known state. > > 2. Translation Structure Setup: It manually constructs the necessary > translation structures in memory, including Stream Table Entries > (STEs), Context Descriptors (CDs), and Page Tables (PTEs). > > 3. DMA Trigger: It programs the smmu-testdev to initiate a DMA operation > targeting a specific IOVA. > > 4. Verification: It waits for the transaction to complete and verifies > that the memory was accessed correctly after address translation by > the SMMU. > > This framework provides a solid and extensible foundation for validating > the SMMU's core translation paths. The initial test included in this > series covers a basic DMA completion path in the Non-Secure bank, > serving as a smoke test and a proof of concept. > > It is worth noting that this series currently only includes tests for the > Non-Secure SMMU. I am aware of the ongoing discussions and RFC patches > for Secure SMMU support. To avoid a dependency on unmerged work, this > submission does not include tests for the Secure world. However, I have > already implemented these tests locally, and I am prepared to submit > them for review as soon as the core Secure SMMU support is merged > upstream. What about other IOMMU's? Are there any other bus mediating devices modelled in QEMU that could also benefit from the ability to trigger DMA transactions? > > > Changes from v1 RFC: > - Clarify Page Table Construction: > Detailed comments have been added to the page table construction logic. This > is a key improvement, as the test setup extensively re-uses the same set of > page tables for multiple translation stages and purposes (e.g., nested S1/S2 > walks, CD fetch). The new comments explain this sharing mechanism, which can > otherwise be confusing to follow. > > - Refactor Shared Helpers: > The helper functions std_space_offset and std_space_to_str are now moved to a > common header file. This allows them to be used by both the main device > implementation (hw/misc/smmu-testdev.c) and its qtest > (tests/qtest/smmu-testdev-qtest.c), improving code re-use and maintainability. > > - Enhance Robustness: > Assertions have been added to ensure the device operates only in the expected > Non-secure context. Additional conditional checks are also included to > prevent potential runtime errors and make the test device more stable. > > - Code Simplification and Cleanup: > Several functions that were redundant with existing macros for constructing > Context Descriptors (CD) and Stream Table Entries (STE) have been removed. > This simplifies the test data setup and reduces code duplication. > > Other unused code fragments have also been removed to improve overall code > clarity and hygiene. > > Tao Tang (2): > hw/misc/smmu-testdev: introduce minimal SMMUv3 test device > tests/qtest: add SMMUv3 smoke test using smmu-testdev DMA source > > docs/specs/index.rst | 1 + > docs/specs/smmu-testdev.rst | 45 ++ > hw/misc/Kconfig | 5 + > hw/misc/meson.build | 1 + > hw/misc/smmu-testdev.c | 943 +++++++++++++++++++++++++++++++ > include/hw/misc/smmu-testdev.h | 402 +++++++++++++ > tests/qtest/meson.build | 1 + > tests/qtest/smmu-testdev-qtest.c | 238 ++++++++ > 8 files changed, 1636 insertions(+) > create mode 100644 docs/specs/smmu-testdev.rst > create mode 100644 hw/misc/smmu-testdev.c > create mode 100644 include/hw/misc/smmu-testdev.h > create mode 100644 tests/qtest/smmu-testdev-qtest.c -- Alex Bennée Virtualisation Tech Lead @ Linaro
