Linux IOMMU Development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Shuai Xue <xueshuai@linux.alibaba.com>
Cc: iommu@lists.linux.dev, kevin.tian@intel.com, joro@8bytes.org,
	will@kernel.org, robin.murphy@arm.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu: iommufd: Explicitly check for VM_PFNMAP in iommufd_ioas_map
Date: Wed, 29 Oct 2025 11:49:16 -0300	[thread overview]
Message-ID: <20251029144916.GO760669@ziepe.ca> (raw)
In-Reply-To: <a63db6a8-e9d8-4f79-8212-8710ce2e60f4@linux.alibaba.com>

On Wed, Oct 29, 2025 at 10:44:31PM +0800, Shuai Xue wrote:

> We run different VMMs (QEMU, Kata Containers) to meet diverse business
> requirements, while our production environment deploys various evolving
> kernel versions. Additionally, we are migrating from VFIO Type 1 to
> IOMMUFD. Although IOMMUFD claims to provide compatible
> iommufd_vfio_ioctl APIs, these APIs are not fully compatible in
> practice. 

Well, it aims to, but we are not there yet. Hopefully in the coming
months the MMIO to VFIO will be supported in type 1 emulation as well.

But broadly the EFAULT return here always means the underlying VMA is
incompatible with IOMMUFD, I'm not sure there is that much value in
further determining why exactly it is incompatible.

> Aha, I see. Thank you for pointing out this issue. The check indeed
> needs to be more comprehensive. Do you mind use pin_user_pages() as a
> precheck?

I mean we already call pin_user_pages deep inside the mapping code and
propogate whatever error code it gives back up to userspace. If it
gives a more specific code then it will be returned naturally, no need
to change iommufd at all.

Jason

      reply	other threads:[~2025-10-29 14:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 12:52 [PATCH] iommu: iommufd: Explicitly check for VM_PFNMAP in iommufd_ioas_map Shuai Xue
2025-10-29 13:34 ` Jason Gunthorpe
2025-10-29 14:44   ` Shuai Xue
2025-10-29 14:49     ` 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=20251029144916.GO760669@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --cc=xueshuai@linux.alibaba.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