public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Yi Liu <yi.l.liu@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>, "Tian, Kevin" <kevin.tian@intel.com>
Cc: "joro@8bytes.org" <joro@8bytes.org>,
	"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
	"Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
	"vasant.hegde@amd.com" <vasant.hegde@amd.com>
Subject: Re: [PATCH v5 08/12] iommufd: Enforce pasid compatible domain for PASID-capable device
Date: Sat, 14 Dec 2024 17:04:20 +0800	[thread overview]
Message-ID: <46b7fc65-491f-4965-9d9b-d77901e41dfc@intel.com> (raw)
In-Reply-To: <Z1wrQ+kgV53BsodW@nvidia.com>

On 2024/12/13 20:40, Jason Gunthorpe wrote:
> On Fri, Dec 13, 2024 at 07:52:40AM +0000, Tian, Kevin wrote:
> 
>> I'm not sure where that requirement comes from. Does AMD require RID
>> and PASID to use the same format when nesting is disabled? If yes, that's
>> still a driver burden to handle, not iommufd's...
> 
> Yes, ARM and AMD require this too
> 
> The point of the iommufd enforcement of ALLOC_PAGING is to try to
> discourage bad apps - ie apps that only work on Intel. We can check
> the rid attach too if it is easy to do

I have an easy way to enforce RID attach. It is:

If the device is device capable, I would enforce all domains for this
device (either RID or PASID) be flagged. The device capable info is static,
so no need to add extra lock across the RID and PASID attach paths for the
page table format alignment. This has only one drawback. If userspace is
not going to use PASID, it still needs to allocated domain with this flag.
I think AMD may need to confirm if it is acceptable.

@Kevin, I'd like to echo the prior suggestion for nested domain. It looks
hard to apply the pasid enforcement on it. So I'd like to limit the
ALLOC_PASID flag to paging domains. Also, I doubt if the uapi needs to
mandate the RID part to use this flag. It appears to me it can be done
iommu drivers. If so, no need to mandate it in uapi. So I'm considering
to do below changes to IOMMU_HWPT_ALLOC_PASID. The new definition does not
mandate the RID part of devices, and leaves it to vendors. Hence, the
iommufd only needs to ensure the paging domains used by PASID should be
flagged. e.g. Intel won't fail PASID attach even its RID is using a domain
that is not flagged (e.g. nested domain, under the new definition, nested
domain does not use this flag). While, AMD would fail it if the RID domain
is not using this flag. This has one more benefit, it leaves the
flexibility of using pasid or not to user.

diff --git a/include/uapi/linux/iommufd.h b/include/uapi/linux/iommufd.h
index 0e27557fb86b..a1a11041d941 100644
--- a/include/uapi/linux/iommufd.h
+++ b/include/uapi/linux/iommufd.h
@@ -387,19 +387,20 @@ struct iommu_vfio_ioas {
   *                                   enforced on device attachment
   * @IOMMU_HWPT_FAULT_ID_VALID: The fault_id field of hwpt allocation data is
   *                             valid.
- * @IOMMU_HWPT_ALLOC_PASID: Requests a domain that can be used with PASID. The
- *                          domain can be attached to any PASID on the device.
- *                          Any domain attached to the non-PASID part of the
- *                          device must also be flagged, otherwise attaching a
- *                          PASID will blocked.
- *                          If IOMMU does not support PASID it will return
- *                          error (-EOPNOTSUPP).
+ * @IOMMU_HWPT_ALLOC_PAGING_PASID: Requests a paging domain that can be used
+ *                                 with PASID. The domain can be attached to
+ *                                 any PASID on the device. Vendors may 
require
+ *                                 the non-PASID part of the device use this
+ *                                 flag as well. If yes, attaching a PASID 
will
+ *                                 blocked if non-PASID part is not using it.
+ *                                 If IOMMU does not support PASID it will
+ *                                 return error (-EOPNOTSUPP).
   */
  enum iommufd_hwpt_alloc_flags {
  	IOMMU_HWPT_ALLOC_NEST_PARENT = 1 << 0,
  	IOMMU_HWPT_ALLOC_DIRTY_TRACKING = 1 << 1,
  	IOMMU_HWPT_FAULT_ID_VALID = 1 << 2,
-	IOMMU_HWPT_ALLOC_PASID = 1 << 3,
+	IOMMU_HWPT_ALLOC_PAGING_PASID = 1 << 3,
  };

  /**
-- 
Regards,
Yi Liu

  reply	other threads:[~2024-12-14  9:00 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 13:25 [PATCH v5 00/12] iommufd support pasid attach/replace Yi Liu
2024-11-04 13:25 ` [PATCH v5 01/12] iommu: Introduce a replace API for device pasid Yi Liu
2024-11-05  3:58   ` Baolu Lu
2024-11-05  7:49     ` Yi Liu
2024-11-05  7:57       ` Baolu Lu
2024-11-05  8:10         ` Yi Liu
2024-11-05  8:14           ` Baolu Lu
2024-11-05 15:10           ` Jason Gunthorpe
2024-11-06  8:52             ` Baolu Lu
2024-11-04 13:25 ` [PATCH v5 02/12] iommufd: Refactor __fault_domain_replace_dev() to be a wrapper of iommu_replace_group_handle() Yi Liu
2024-11-05  5:06   ` Baolu Lu
2024-11-05  8:01     ` Yi Liu
2024-11-05  8:03       ` Baolu Lu
2024-11-05  8:12         ` Yi Liu
2024-11-04 13:25 ` [PATCH v5 03/12] iommufd: Move the iommufd_handle helpers to device.c Yi Liu
2024-11-05  5:21   ` Baolu Lu
2024-11-05  8:01     ` Yi Liu
2024-11-05 15:18       ` Jason Gunthorpe
2024-11-04 13:25 ` [PATCH v5 04/12] iommufd: Always pass iommu_attach_handle to iommu core Yi Liu
2024-11-04 13:25 ` [PATCH v5 05/12] iommufd: Pass pasid through the device attach/replace path Yi Liu
2024-11-04 13:25 ` [PATCH v5 06/12] iommufd: Support pasid attach/replace Yi Liu
2024-11-04 13:25 ` [PATCH v5 07/12] iommufd: Allocate auto_domain with IOMMU_HWPT_ALLOC_PASID flag if device is PASID-capable Yi Liu
2024-11-04 13:25 ` [PATCH v5 08/12] iommufd: Enforce pasid compatible domain for PASID-capable device Yi Liu
2024-12-06  7:57   ` Yi Liu
2024-12-06 17:58     ` Jason Gunthorpe
2024-12-07 10:49       ` Yi Liu
2024-12-09 14:57         ` Jason Gunthorpe
2024-12-10  3:15           ` Yi Liu
2024-12-11  8:46             ` Tian, Kevin
2024-12-12  3:15               ` Yi Liu
2024-12-12  5:51                 ` Tian, Kevin
2024-12-12  7:13                   ` Yi Liu
2024-12-13  2:43                     ` Tian, Kevin
2024-12-13  7:19                       ` Yi Liu
2024-12-13  7:52                         ` Tian, Kevin
2024-12-13  8:11                           ` Yi Liu
2024-12-13  8:12                             ` Yi Liu
2024-12-13 12:40                           ` Jason Gunthorpe
2024-12-14  9:04                             ` Yi Liu [this message]
2024-12-16  8:26                               ` Tian, Kevin
2024-12-17 13:28                                 ` Yi Liu
2024-12-11 18:06             ` Jason Gunthorpe
2024-11-04 13:25 ` [PATCH v5 09/12] iommufd/selftest: Add set_dev_pasid in mock iommu Yi Liu
2024-11-04 13:25 ` [PATCH v5 10/12] iommufd/selftest: Add a helper to get test device Yi Liu
2024-11-04 13:25 ` [PATCH v5 11/12] iommufd/selftest: Add test ops to test pasid attach/detach Yi Liu
2024-11-04 13:25 ` [PATCH v5 12/12] iommufd/selftest: Add coverage for iommufd " Yi Liu
2024-11-13  1:37 ` [PATCH v5 00/12] iommufd support pasid attach/replace Jason Gunthorpe
2024-11-13  3:01   ` Baolu Lu
2024-11-13  3:24     ` Yi Liu
2024-11-13  3:26       ` Yi Liu
2024-11-15  9:24         ` Yi Liu

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=46b7fc65-491f-4965-9d9b-d77901e41dfc@intel.com \
    --to=yi.l.liu@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=vasant.hegde@amd.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox