From: "Alex Bennée" <alex.bennee@linaro.org>
To: Tao Tang <tangtao1634@phytium.com.cn>
Cc: "CLEMENT MATHIEU--DRIF" <clement.mathieu--drif@eviden.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Fabiano Rosas" <farosas@suse.de>,
"Laurent Vivier" <lvivier@redhat.com>,
"Eric Auger" <eric.auger@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"Chen Baozi" <chenbaozi@phytium.com.cn>,
"Pierrick Bouvier" <pierrick.bouvier@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Jean-Philippe Brucker" <jean-philippe@linaro.org>,
"Mostafa Saleh" <smostafa@google.com>
Subject: Re: [RFC v3 1/3] hw/misc: introduce iommu-testdev for bare-metal IOMMU testing
Date: Mon, 17 Nov 2025 21:39:51 +0000 [thread overview]
Message-ID: <875xb8l4ns.fsf@draig.linaro.org> (raw)
In-Reply-To: <7f38ee63-eb24-460c-b8b3-51f3402c4d69@phytium.com.cn> (Tao Tang's message of "Mon, 17 Nov 2025 21:56:28 +0800")
Tao Tang <tangtao1634@phytium.com.cn> writes:
> Hi Clement,
>
> On 2025/11/13 15:02, CLEMENT MATHIEU--DRIF wrote:
>> Hi Tao,
>>
>> On Thu, 2025-11-13 at 00:21 +0800, Tao Tang wrote:
>>> Add a minimal PCI test device designed to exercise IOMMU translation
>>> (such as ARM SMMUv3) without requiring guest firmware or OS. The device
>>> provides MMIO registers to configure and trigger DMA operations with
>>> controllable attributes (security state, address space), enabling
>>> deterministic IOMMU testing.
>>>
>>> Key features:
>>> - Bare-metal IOMMU testing via simple MMIO interface
>>> - Configurable DMA attributes for security states and address spaces
>>> - Write-then-read verification pattern with automatic result checking
>>>
>>> The device performs a deterministic DMA test pattern: write a known
>>> value(0x88888888) to a configured IOVA, read it back, and verify data
>>> integrity. Results are reported through a dedicated result register,
>>> eliminating the need for complex interrupt handling or driver
>>> infrastructure in tests.
>>>
>>> This is purely a test device and not intended for production use or
>>> machine realism. It complements existing test infrastructure like
>>> pci-testdev but focuses specifically on IOMMU translation path
>>> validation.
>>>
>>> Signed-off-by: Tao Tang <[tangtao1634@phytium.com.cn](mailto:tangtao1634@phytium.com.cn)>
>>> ---
>>> docs/specs/index.rst | 1 +
>>> docs/specs/iommu-testdev.rst | 96 +++++++++++
>>> hw/misc/Kconfig | 5 +
>>> hw/misc/iommu-testdev.c | 292 ++++++++++++++++++++++++++++++++
>>> hw/misc/meson.build | 1 +
>>> hw/misc/trace-events | 10 ++
>>> include/hw/misc/iommu-testdev.h | 78 +++++++++
>>> 7 files changed, 483 insertions(+)
>>> create mode 100644 docs/specs/iommu-testdev.rst
>>> create mode 100644 hw/misc/iommu-testdev.c
>>> create mode 100644 include/hw/misc/iommu-testdev.h
>>>
>>> ------------------------------<snip>------------------------------
>>>
>>>
>>>
>>> ------------------------------<snip>------------------------------
>>> +
>>> +static void iommu_testdev_maybe_run_dma(IOMMUTestDevState *s)
>>> +{
>>> + int i, j, remaining_bytes;
>> I think i and j could be declared in their respective loop
>
>
> Thanks a lot for taking the time to review the patch. All your
> suggestions are excellent and make a lot of sense.
>
>
> Move the i and j loop variable declarations into their respective for
> loops sounds a good idea. But I wasn't entirely sure if QEMU had a
> strict code style requirement for this, such as mandating all
> variables be defined at the start of the function before any
> executable code (C89 style), so I appreciate the clarification.
>
<snip>
We have a special exemption, from style.rst:
Mixed declarations (interleaving statements and declarations within
blocks) are generally not allowed; declarations should be at the beginning
of blocks. To avoid accidental re-use it is permissible to declare
loop variables inside for loops:
.. code-block:: c
for (int i = 0; i < ARRAY_SIZE(thing); i++) {
/* do something loopy */
}
Every now and then, an exception is made for declarations inside a
#ifdef or #ifndef block: if the code looks nicer, such declarations can
be placed at the top of the block even if there are statements above.
On the other hand, however, it's often best to move that #ifdef/#ifndef
block to a separate function altogether.
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2025-11-17 21:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 16:21 [RFC v3 0/3] hw/misc: Introduce a generalized IOMMU test framework Tao Tang
2025-11-12 16:21 ` [RFC v3 1/3] hw/misc: introduce iommu-testdev for bare-metal IOMMU testing Tao Tang
2025-11-13 7:02 ` CLEMENT MATHIEU--DRIF
2025-11-17 13:56 ` Tao Tang
2025-11-17 21:39 ` Alex Bennée [this message]
2025-11-18 3:24 ` Tao Tang
2025-11-12 16:21 ` [RFC v3 2/3] tests/qtest: add libqos SMMUv3 helper library Tao Tang
2025-11-18 11:32 ` Alex Bennée
2025-11-18 15:45 ` Tao Tang
2025-11-12 16:21 ` [RFC v3 3/3] tests/qtest: add SMMUv3 bare-metal test using iommu-testdev Tao Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875xb8l4ns.fsf@draig.linaro.org \
--to=alex.bennee@linaro.org \
--cc=chenbaozi@phytium.com.cn \
--cc=clement.mathieu--drif@eviden.com \
--cc=eric.auger@redhat.com \
--cc=farosas@suse.de \
--cc=jean-philippe@linaro.org \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=pierrick.bouvier@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=smostafa@google.com \
--cc=tangtao1634@phytium.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).