All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Yi Liu <yi.l.liu@intel.com>
Cc: <alex.williamson@redhat.com>, <kevin.tian@intel.com>,
	<jgg@nvidia.com>, <eric.auger@redhat.com>, <kvm@vger.kernel.org>,
	<chao.p.peng@linux.intel.com>, <zhenzhong.duan@intel.com>,
	<willy@infradead.org>, <zhangfei.gao@linaro.org>,
	<vasant.hegde@amd.com>
Subject: Re: [PATCH v8 4/5] iommufd: Extend IOMMU_GET_HW_INFO to report PASID capability
Date: Thu, 20 Mar 2025 09:47:32 -0700	[thread overview]
Message-ID: <Z9xGpLRE8wPHlUAV@Asurada-Nvidia> (raw)
In-Reply-To: <444284f3-2dae-4aa9-a897-78a36e1be3ca@intel.com>

On Thu, Mar 20, 2025 at 08:48:49PM +0800, Yi Liu wrote:
> On 2025/3/20 01:58, Nicolin Chen wrote:
> > On Thu, Mar 13, 2025 at 05:47:52AM -0700, Yi Liu wrote:
> > > PASID usage requires PASID support in both device and IOMMU. Since the
> > > iommu drivers always enable the PASID capability for the device if it
> > > is supported, this extends the IOMMU_GET_HW_INFO to report the PASID
> > > capability to userspace. Also, enhances the selftest accordingly.
> > 
> > Overall, I am a bit confused by the out_capabilities field in the
> > IOMMU_GET_HW_INFO. Why these capabilities cannot be reported via
> > the driver specific data structure?
> > 
> > E.g. we don't report the "NESTING" capability in out_capabilities
> > at all and that works fine since the iommu driver would reject if
> > it doesn't support.
> 
> NESTING is a bit different. Userspace needs to know underlying PASID
> cap and further expose it to guest if it wants. While NESTING is not
> from this angle. It's just for the use of userspace. So a try and fail
> is ok.

Hmm, would you please elaborate the difference more?

Also, what's that "further expose"?

> > Mind elaborate the reason for these two new capabilities? What is
> > the benefit from keeping them in the core v.s. driver level?
> 
> I view the PASID cap is generic just like the DIRTY_TRACKING cap.

Well, I actually don't get the DIRTY_TRACKING cap either. Based on
what I see from Zhenzhong's implementation in the QEMU, it totally
could be a vendor-specific cap: we can just add another PCIIOMMUOps
op for QEMU core to ask the IOMMU device model to get hw_info and
allocate a DIRTY_TRACKING-enabled HWPT to return that to the core,
instead of core detecting the out_capabilities in the common path.

In that regard, honestly, I don't quite get this out_capabilities.

> Reporting them in the driver-specific part is fine, but I doubt
> if it is better since PASID cap is generic to all vendors.

The argument could be that NESTING is generic to all vendors too,
yet we don't have that in out_capabilities :-/

Thanks
Nicolin

  reply	other threads:[~2025-03-20 16:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 12:47 [PATCH v8 0/5] vfio-pci support pasid attach/detach Yi Liu
2025-03-13 12:47 ` [PATCH v8 1/5] ida: Add ida_find_first_range() Yi Liu
2025-03-13 12:47 ` [PATCH v8 2/5] vfio-iommufd: Support pasid [at|de]tach for physical VFIO devices Yi Liu
2025-03-13 12:47 ` [PATCH v8 3/5] vfio: VFIO_DEVICE_[AT|DE]TACH_IOMMUFD_PT support pasid Yi Liu
2025-03-19 17:41   ` Nicolin Chen
2025-03-20 12:37     ` Yi Liu
2025-03-13 12:47 ` [PATCH v8 4/5] iommufd: Extend IOMMU_GET_HW_INFO to report PASID capability Yi Liu
2025-03-17  7:18   ` Yi Liu
2025-03-19 17:58   ` Nicolin Chen
2025-03-20 12:48     ` Yi Liu
2025-03-20 16:47       ` Nicolin Chen [this message]
2025-03-20 18:57         ` Jason Gunthorpe
2025-03-20 20:02           ` Nicolin Chen
2025-03-20 23:40             ` Jason Gunthorpe
2025-03-20 23:48               ` Nicolin Chen
2025-03-21  4:27                 ` Nicolin Chen
2025-03-21 17:37                   ` Yi Liu
2025-03-21 18:29                     ` Nicolin Chen
2025-03-21 18:42                       ` Jason Gunthorpe
2025-03-21 19:00                         ` Nicolin Chen
2025-03-13 12:47 ` [PATCH v8 5/5] iommufd/selftest: Add coverage for reporting max_pasid_log2 via IOMMU_HW_INFO Yi Liu
2025-03-19 18:12   ` Nicolin Chen
2025-03-14 14:48 ` [PATCH v8 0/5] vfio-pci support pasid attach/detach Alex Williamson
2025-03-17  7:25   ` Yi Liu
2025-03-17 19:28     ` Jason Gunthorpe

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=Z9xGpLRE8wPHlUAV@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=eric.auger@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=vasant.hegde@amd.com \
    --cc=willy@infradead.org \
    --cc=yi.l.liu@intel.com \
    --cc=zhangfei.gao@linaro.org \
    --cc=zhenzhong.duan@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.