All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Pan <jacob.pan@linux.microsoft.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Alex Williamson <alex@shazbot.org>,
	Joerg Roedel <joro@8bytes.org>,
	Mostafa Saleh <smostafa@google.com>,
	David Matlack <dmatlack@google.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"skhawaja@google.com" <skhawaja@google.com>,
	"pasha.tatashin@soleen.com" <pasha.tatashin@soleen.com>,
	Will Deacon <will@kernel.org>,
	Baolu Lu <baolu.lu@linux.intel.com>,
	jacob.pan@linux.microsoft.com
Subject: Re: [PATCH V4 04/10] iommufd: Add an ioctl IOMMU_IOAS_GET_PA to query PA from IOVA
Date: Mon, 4 May 2026 16:03:45 -0700	[thread overview]
Message-ID: <20260504160345.00002589@linux.microsoft.com> (raw)
In-Reply-To: <BL1PR11MB52714A18A767F7C5C1985DF48C232@BL1PR11MB5271.namprd11.prod.outlook.com>

Hi Kevin,

On Thu, 16 Apr 2026 08:02:33 +0000
"Tian, Kevin" <kevin.tian@intel.com> wrote:

> > From: Jacob Pan <jacob.pan@linux.microsoft.com>
> > Sent: Wednesday, April 15, 2026 5:14 AM
> > 
> > To support no-IOMMU mode where userspace drivers perform unsafe DMA
> > using physical addresses, introduce a new API to retrieve the
> > physical address of a user-allocated DMA buffer that has been
> > mapped to an IOVA via IOAS. The mapping is backed by mock I/O page
> > tables maintained
> > by generic IOMMUPT framework.
> > 
> > Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> > Signed-off-by: Jacob Pan <jacob.pan@linux.microsoft.com>
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>  
> 
> Your s-o-b should be the last 
will do.

> 
> > +	/*
> > +	 * Scan the domain for the contiguous physical address
> > length so that
> > +	 * userspace search can be optimized for fewer ioctls.
> > +	 */
> > +	while (iova < iopt_area_last_iova(area)) {
> > +		unsigned long next_iova;
> > +		u64 next_paddr;
> > +
> > +		if (check_add_overflow(iova, PAGE_SIZE,
> > &next_iova))
> > +			break;
> > +
> > +		next_paddr =
> > iommu_iova_to_phys(area->storage_domain, next_iova);
> > +
> > +		if (!next_paddr || next_paddr != tmp_paddr +
> > PAGE_SIZE)
> > +			break;  
> 
> the 2nd condition should be WARN_ON? 
I don't think it should be a WARN_ON since PA non-contiguity is one of
the normal exit conditions.

> 
> > @@ -432,6 +432,7 @@ union ucmd_buffer {
> >  	struct iommu_veventq_alloc veventq;
> >  	struct iommu_vfio_ioas vfio_ioas;
> >  	struct iommu_viommu_alloc viommu;
> > +	struct iommu_ioas_get_pa get_pa;  
> 
> alphabetic order
> 
will do.

> >  #ifdef CONFIG_IOMMUFD_TEST
> >  	struct iommu_test_cmd test;
> >  #endif
> > @@ -484,6 +485,8 @@ static const struct iommufd_ioctl_op
> > iommufd_ioctl_ops[] = {
> >  		 struct iommu_ioas_map_file, iova),
> >  	IOCTL_OP(IOMMU_IOAS_UNMAP, iommufd_ioas_unmap, struct
> > iommu_ioas_unmap,
> >  		 length),
> > +	IOCTL_OP(IOMMU_IOAS_GET_PA, iommufd_ioas_get_pa, struct
> > iommu_ioas_get_pa,
> > +		 out_phys),  
> 
> ditto
will do

> > 
> > +/**
> > + * struct iommu_ioas_get_pa - ioctl(IOMMU_IOAS_GET_PA)
> > + * @size: sizeof(struct iommu_ioas_get_pa)
> > + * @flags: Reserved, must be 0 for now
> > + * @ioas_id: IOAS ID to query IOVA to PA mapping from
> > + * @__reserved: Must be 0
> > + * @iova: IOVA to query
> > + * @out_length: Number of bytes contiguous physical address
> > starting from phys
> > + * @out_phys: Output physical address the IOVA maps to
> > + *
> > + * Query the physical address backing an IOVA range. The entire
> > range must be
> > + * mapped already. For noiommu devices doing unsafe DMA only.
> > + */
> > +struct iommu_ioas_get_pa {
> > +	__u32 size;
> > +	__u32 flags;
> > +	__u32 ioas_id;
> > +	__u32 __reserved;
> > +	__aligned_u64 iova;
> > +	__aligned_u64 out_length;
> > +	__aligned_u64 out_phys;
> > +};
> > +#define IOMMU_IOAS_GET_PA _IO(IOMMUFD_TYPE,
> > IOMMUFD_CMD_IOAS_GET_PA)
> > +  
> 
> Based on its purpose let's make the restriction in the name, e.g.
> 
> IOMMUFD_CMD_IOAS_NOIOMMU_GET_PA

yeah, make sense. will rename all the function names as well.

  reply	other threads:[~2026-05-04 23:03 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 21:14 [PATCH V4 00/10] iommufd: Enable noiommu mode for cdev Jacob Pan
2026-04-14 21:14 ` [PATCH V4 01/10] iommufd: Support a HWPT without an iommu driver for noiommu Jacob Pan
2026-04-16  7:25   ` Tian, Kevin
2026-04-17 21:59     ` Jacob Pan
2026-04-22  8:12       ` Tian, Kevin
2026-04-22 16:03         ` Jason Gunthorpe
2026-04-23  7:26           ` Tian, Kevin
2026-04-23 14:51             ` Jason Gunthorpe
2026-04-24  6:31               ` Tian, Kevin
2026-04-28  7:45   ` Yi Liu
2026-04-28 16:42     ` Jacob Pan
2026-04-14 21:14 ` [PATCH V4 02/10] iommufd: Move igroup allocation to a function Jacob Pan
2026-04-16  7:48   ` Tian, Kevin
2026-05-05 21:32     ` Jacob Pan
2026-04-28  7:45   ` Yi Liu
2026-04-14 21:14 ` [PATCH V4 03/10] iommufd: Allow binding to a noiommu device Jacob Pan
2026-04-16  7:56   ` Tian, Kevin
2026-05-05 23:04     ` Jacob Pan
2026-04-28  7:45   ` Yi Liu
2026-05-06 18:51     ` Jacob Pan
2026-04-14 21:14 ` [PATCH V4 04/10] iommufd: Add an ioctl IOMMU_IOAS_GET_PA to query PA from IOVA Jacob Pan
2026-04-16  8:02   ` Tian, Kevin
2026-05-04 23:03     ` Jacob Pan [this message]
2026-04-16 19:32   ` Alex Williamson
2026-05-04 22:30     ` Jacob Pan
2026-04-14 21:14 ` [PATCH V4 05/10] vfio: Allow null group for noiommu without containers Jacob Pan
2026-04-16  8:13   ` Tian, Kevin
2026-04-16 21:33     ` Jacob Pan
2026-04-16 20:06   ` Alex Williamson
2026-04-17 17:06     ` Jacob Pan
2026-04-17 23:04       ` Alex Williamson
2026-04-14 21:14 ` [PATCH V4 06/10] vfio: Introduce and set noiommu flag on vfio_device Jacob Pan
2026-04-14 21:14 ` [PATCH V4 07/10] vfio: Enable cdev noiommu mode under iommufd Jacob Pan
2026-04-16 20:49   ` Alex Williamson
2026-04-30 23:31     ` Jacob Pan
2026-04-14 21:14 ` [PATCH V4 08/10] vfio:selftest: Handle VFIO noiommu cdev Jacob Pan
2026-04-14 21:14 ` [PATCH V4 09/10] selftests/vfio: Add iommufd noiommu mode selftest for cdev Jacob Pan
2026-04-14 21:14 ` [PATCH V4 10/10] Documentation: Update VFIO NOIOMMU mode Jacob Pan
2026-04-28  7:46   ` Yi Liu
2026-04-30 23:41     ` Jacob Pan

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=20260504160345.00002589@linux.microsoft.com \
    --to=jacob.pan@linux.microsoft.com \
    --cc=alex@shazbot.org \
    --cc=baolu.lu@linux.intel.com \
    --cc=dmatlack@google.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.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=smostafa@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 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.