From: Jason Gunthorpe <jgg@nvidia.com>
To: Andrea Parri <parri.andrea@gmail.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Shuah Khan <shuah@kernel.org>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Nicolin Chen <nicolinc@nvidia.com>,
iommu@lists.linux.dev, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] iommufd/selftest: Check dmabuf MMIO mappings filled from another domain
Date: Wed, 14 Oct 2026 20:59:23 -0300 [thread overview]
Message-ID: <20261014235923.GZ13920@nvidia.com> (raw)
In-Reply-To: <20261014211608.291608-1-parri.andrea@gmail.com>
On Wed, Oct 14, 2026 at 11:16:07PM +0200, Andrea Parri wrote:
> On Wed, Oct 14, 2026 at 02:52:45PM -0300, Jason Gunthorpe wrote:
> > > The mock page table has no memory type bits, so a mapping made with
> > > IOMMU_MMIO cannot be told apart from one made with IOMMU_CACHE. Wrap the
> > > mock's generic_pt map_range and unmap_range ops to record, per domain,
> > > the pages mapped with IOMMU_MMIO, and add IOMMU_TEST_OP_MD_CHECK_MMIO to
> > > check that a range is recorded. The check rejects ranges that wrap or
> > > do not fit in unsigned long.
> >
> > I'm not keen on this, the special mock amd domain is just for mock
> > usage, we should probably just add a mmio bit if we want to do this
> > test.
>
> Makes sense, thanks. For v3 I have:
>
> - AMDV1PT_FMT_MOCK_MMIO (bit 52) in amdv1.h under AMDV1_IOMMUFD_SELFTEST,
> set by amdv1pt_iommu_set_prot() for IOMMU_MMIO and kept by
> amdv1pt_attr_from_entry();
>
> - pt_iommu_amdv1_mock_iova_is_mmio() in fmt/iommu_mock.c, a walk like
> iova_to_phys() that returns the bit, exported in GENERIC_PT_IOMMU for
> IOMMU_TEST_OP_MD_CHECK_MMIO to use.
>
> The op wrappers and the xarray in mock_iommu_domain are gone. Is the
> extra export from iommu_mock.c OK with you, or would you rather the
> selftest read the PTE some other way?
>
> Patch 1 is unchanged; if it looks right to you, it could go in ahead of
> the test.
Yeah I will pick up patch 1, I am just stuck on all these dirty
tracking patches right now
Jason
prev parent reply other threads:[~2026-10-14 23:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 12:52 [PATCH v2 0/2] iommufd: Keep dmabuf MMIO attributes in domains added later Andrea Parri
2026-10-08 12:52 ` [PATCH v2 1/2] iommufd: Keep dmabuf PFNs MMIO when filling another domain Andrea Parri
2026-10-08 12:52 ` [PATCH v2 2/2] iommufd/selftest: Check dmabuf MMIO mappings filled from " Andrea Parri
2026-10-14 17:52 ` Jason Gunthorpe
2026-10-14 21:16 ` Andrea Parri
2026-10-14 23:59 ` Jason Gunthorpe [this message]
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=20261014235923.GZ13920@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=parri.andrea@gmail.com \
--cc=robin.murphy@arm.com \
--cc=shuah@kernel.org \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.