From: Jason Gunthorpe <jgg@nvidia.com>
To: Samiullah Khawaja <skhawaja@google.com>
Cc: Jacob Pan <jacob.pan@linux.microsoft.com>,
linux-kernel@vger.kernel.org,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
Alex Williamson <alex@shazbot.org>,
Joerg Roedel <joro@8bytes.org>,
David Matlack <dmatlack@google.com>,
Robin Murphy <robin.murphy@arm.com>,
Nicolin Chen <nicolinc@nvidia.com>,
"Tian, Kevin" <kevin.tian@intel.com>, Yi Liu <yi.l.liu@intel.com>,
pasha.tatashin@soleen.com, Will Deacon <will@kernel.org>,
Baolu Lu <baolu.lu@linux.intel.com>
Subject: Re: [PATCH V2 01/11] iommufd: Support a HWPT without an iommu driver for noiommu
Date: Mon, 23 Mar 2026 10:17:14 -0300 [thread overview]
Message-ID: <20260323131714.GG7340@nvidia.com> (raw)
In-Reply-To: <abrvYSZ425p6a17D@google.com>
On Wed, Mar 18, 2026 at 06:38:14PM +0000, Samiullah Khawaja wrote:
> > +static const struct iommu_domain_ops noiommu_amdv1_ops = {
> > + IOMMU_PT_DOMAIN_OPS(amdv1),
>
> I understand that this fits in really well into the iommufd/hwpt
> construction, but do we need page tables for this as all the
> iova-to-phys information should be available in the IOPT in IOAS?
Yes we do! That is the whole point.
In iommufd once you pin the memory the phys is stored in only two
possible ways:
1) Inside an xarray if an access is used
2) Inside at least one iommu_domain
That's it. So to fit noiommu into this scheme, and have it rely on the
existing pinning, we either have to make it use an access or make it
use an iommu_domain -> a real one that can store phys.
Maybe a comment is helpful, but using the domain like this to store
the pinned phys has been the vfio design from day 1..
> get_pa() function introduced in the later patch is only used for noiommu
> use-cases, it can use the IOPT to get the physical addresses?
No.
Jason
next prev parent reply other threads:[~2026-03-23 13:17 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 15:56 [PATCH V2 00/11] iommufd: Enable noiommu mode for cdev Jacob Pan
2026-03-12 15:56 ` [PATCH V2 01/11] iommufd: Support a HWPT without an iommu driver for noiommu Jacob Pan
2026-03-18 18:38 ` Samiullah Khawaja
2026-03-23 13:17 ` Jason Gunthorpe [this message]
2026-03-24 17:42 ` Samiullah Khawaja
2026-03-22 9:24 ` Mostafa Saleh
2026-03-23 21:11 ` Jacob Pan
2026-03-23 22:10 ` Jason Gunthorpe
2026-03-12 15:56 ` [PATCH V2 02/11] iommufd: Move igroup allocation to a function Jacob Pan
2026-03-18 18:39 ` Samiullah Khawaja
2026-03-22 9:41 ` Mostafa Saleh
2026-03-23 22:51 ` Jacob Pan
2026-03-23 16:46 ` Samiullah Khawaja
2026-03-12 15:56 ` [PATCH V2 03/11] iommufd: Allow binding to a noiommu device Jacob Pan
2026-03-22 9:54 ` Mostafa Saleh
2026-03-23 13:20 ` Jason Gunthorpe
2026-03-24 19:13 ` Jacob Pan
2026-03-12 15:56 ` [PATCH V2 04/11] iommufd: Add an ioctl IOMMU_IOAS_GET_PA to query PA from IOVA Jacob Pan
2026-03-12 15:56 ` [PATCH V2 05/11] vfio: Allow null group for noiommu without containers Jacob Pan
2026-03-22 9:59 ` Mostafa Saleh
2026-03-23 13:21 ` Jason Gunthorpe
2026-03-12 15:56 ` [PATCH V2 06/11] vfio: Introduce and set noiommu flag on vfio_device Jacob Pan
2026-03-22 10:02 ` Mostafa Saleh
2026-03-12 15:56 ` [PATCH V2 07/11] vfio: Update noiommu device detection logic for cdev Jacob Pan
2026-03-22 10:04 ` Mostafa Saleh
2026-03-12 15:56 ` [PATCH V2 08/11] vfio: Enable cdev noiommu mode under iommufd Jacob Pan
2026-03-14 8:09 ` kernel test robot
2026-03-12 15:56 ` [PATCH V2 09/11] vfio:selftest: Handle VFIO noiommu cdev Jacob Pan
2026-03-12 15:56 ` [PATCH V2 10/11] selftests/vfio: Add iommufd noiommu mode selftest for cdev Jacob Pan
2026-03-12 15:56 ` [PATCH V2 11/11] Doc: Update VFIO NOIOMMU mode Jacob Pan
2026-03-13 17:48 ` kernel test robot
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=20260323131714.GG7340@nvidia.com \
--to=jgg@nvidia.com \
--cc=alex@shazbot.org \
--cc=baolu.lu@linux.intel.com \
--cc=dmatlack@google.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.pan@linux.microsoft.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=pasha.tatashin@soleen.com \
--cc=robin.murphy@arm.com \
--cc=skhawaja@google.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
/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