Hi Alex, Peter, Pierrick:
Thank you all again for the outstanding feedback.
As Peter said in mail
[1](https://lore.kernel.org/qemu-devel/cafeaca92dtdn+zf-gzvv9zq3_mwjhzy5hrkdgrrye7xuio4...@mail.gmail.com/):
On 2025/10/27 21:58, Peter Maydell wrote:
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
And Alex's guidance in another
mail [2](https://lore.kernel.org/qemu-devel/[email protected]/):
Yes - generally I think having a single test device that can be used to
test multiple models will be useful. I guess each qtest will be very
tied to the SMMU it is modelling as it needs to program both sides but
if we take care to encapsulate the programming of the test device and
verification of the results we should be able to ensure good code
re-use.
I'll admit this is an area I haven't looked into. I'm very
open to ideas—do you or others have suggestions on how this
test-device pattern could be generalized or what would be needed to
make it useful across different architectures?
My only initial thought is the device might be better called
iommu-testdev (as in a device to test IOMMUs, of which the SMMU is one).
You nailed the core problem. I hadn't properly thought through the
separation of concerns, leading to a device that was doing work it
shouldn't. As Alex pointed out in [2], this architectural refactoring
allows us to build a generic iommu-testdev to ensure good code re-use.
This elevates the work from a single-purpose tool into a framework that
can benefit all IOMMU implementations, which I understand is a far more
valuable contribution.
Furthermore, Pierrick's comment in mail
[3](https://lore.kernel.org/qemu-devel/[email protected]/):
We have to start somewhere, so something simple and not trying to
solve all use cases is the right approach. It can even just be
read/write config/registers before trying to add any DMA scenario.
Also as Alex said in mail
[4](https://lore.kernel.org/qemu-devel/[email protected]/):
We should be thinking of targeted unit tests. The difference between
this and a full OS is we don't need to manage multiple shifting memory
maps over time. Setup a page (or two) with the permissions you expect
and check that works.
The goal is to avoid "accidentally rewriting a driver." Instead, we
should start simple and provide "targeted unit tests." The idea of
setting up a simple, static state ("a page or two") to verify atomic
features and edge cases that are hard to trigger in a dynamic OS is
exactly the right philosophy for this framework.
Based on this, my plan for V3 maybe now much clearer:
- Refactor the device: It will be renamed iommu-testdev and become a
"dumb," generic DMA engine. All architecture-specific logic, including
the construction of page tables and other structures, will be moved into
the qtest.
- Abstract for reuse: Following Peter's and Alex's advice, the
table-building logic will be abstracted into reusable helper functions
within the libqos/ library.
- Limit the initial scope: As you all suggested, the first set of tests
will be simple unit tests, focusing on the core paths like different
security states and translation stages
One final question to manage the scope of this large refactoring: my
plan is to implement the generic iommu-testdev framework in V3, but
provide only the SMMUv3-specific qtest helpers and tests for now. We can
leave the implementation for other architectures (like VT-d) to future
work. Does this seem like a reasonable approach?
Thanks again for helping to shape this work.
Best regards,
Tao
[1]
(https://lore.kernel.org/qemu-devel/cafeaca92dtdn+zf-gzvv9zq3_mwjhzy5hrkdgrrye7xuio4...@mail.gmail.com/)
[2] (https://lore.kernel.org/qemu-devel/[email protected]/)
[3]
(https://lore.kernel.org/qemu-devel/[email protected]/)
[4] (https://lore.kernel.org/qemu-devel/[email protected]/)
