From: Yi Liu <yi.l.liu@intel.com>
To: Vasant Hegde <vasant.hegde@amd.com>, <iommu@lists.linux.dev>,
<joro@8bytes.org>
Cc: <will@kernel.org>, <robin.murphy@arm.com>,
<suravee.suthikulpanit@amd.com>, <jgg@ziepe.ca>,
<baolu.lu@linux.intel.com>, <kevin.tian@intel.com>,
<jacob.pan@linux.microsoft.com>
Subject: Re: [PATCH v5 03/12] iommu: Add new flag to explictly request PASID capable domain
Date: Wed, 30 Oct 2024 22:14:39 +0800 [thread overview]
Message-ID: <b2bedf29-8757-4769-b4b3-064a8157a63c@intel.com> (raw)
In-Reply-To: <20241028093810.5901-4-vasant.hegde@amd.com>
On 2024/10/28 17:38, Vasant Hegde wrote:
> @@ -359,11 +359,19 @@ 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 flaged, otherwise attaching a
> + * PASID will blocked.
> + * If IOMMU does not support PASID it will return
> + * error (-EOPNOTSUPP).
Good to see this flag got applied. As prior suggestion[1], my iommufd pasid
series [2] needs to ensure all domains attached to a pasid-capable device
be flagged with IOMMU_HWPT_ALLOC_PASID. I have three opens as below:
1) Should we allocate the auto_domains with IOMMU_HWPT_ALLOC_PASID?
Such domains are allocated when attaching RID to ioas. If we don't
do it, it means userspace is not allowed to attach RID to ioas if
the userspace wants to use pasid. If we do it, any cons from AMD p.o.v.?
2) Should the RID attach/replace path mandate pasid compatible domain
if the device is pasid capable (say dev->iommu->max_pasids > 0)?
This seems to be the only way for the RID path as iommufd cannot know
if pasid is used or not in the time of attaching RID to domains.
3) We lack of a lock across RID and PASID attach/replace path within
iommufd. So it is uneasy to sync between the two paths. e.g. we need
to check if RID is attached to a pasid compatible domain or not in the
PASID attach/replace path. Any suggestions?
Or this is over-engineering since 2) would enforce the RID
attach/replace path, so the pasid attach/replace path can rely on it
without checking the attached domain of RID? The pasid path just
needs to check if the domain to be attached is allocated with the
IOMMU_HWPT_ALLOC_PASID or not and also check if device is pasid capable.
Please feel free to correct me.
[1]
https://lore.kernel.org/linux-iommu/5a6c2676-256a-4fa5-b9a0-e433d4e933c9@intel.com/
[2]
https://lore.kernel.org/linux-iommu/20240912131255.13305-7-yi.l.liu@intel.com/
--
Regards,
Yi Liu
next prev parent reply other threads:[~2024-10-30 14:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 9:37 [PATCH v5 00/12] iommu: Domain allocation enhancements Vasant Hegde
2024-10-28 9:37 ` [PATCH v5 01/12] iommu: Refactor __iommu_domain_alloc() Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 02/12] iommu: Introduce iommu_paging_domain_alloc_flags() Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 03/12] iommu: Add new flag to explictly request PASID capable domain Vasant Hegde
2024-10-30 14:14 ` Yi Liu [this message]
2024-10-28 9:38 ` [PATCH v5 04/12] iommu/arm-smmu-v3: Enhance domain_alloc_user() to allocate " Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 05/12] iommu/amd: Add helper function to check GIOSUP/GTSUP Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 06/12] iommu/amd: Move V2 page table support check to early_amd_iommu_init() Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 07/12] iommu/amd: Separate page table setup from domain allocation Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 08/12] iommu/amd: Pass page table type as param to pdom_setup_pgtable() Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 09/12] iommu/amd: Enhance amd_iommu_domain_alloc_user() Vasant Hegde
2024-10-28 15:19 ` Jason Gunthorpe
2024-10-28 9:38 ` [PATCH v5 10/12] iommu/amd: Implement global identity domain Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 11/12] iommu: Put domain allocation in __iommu_group_alloc_blocking_domain() Vasant Hegde
2024-10-28 9:38 ` [PATCH v5 12/12] iommu: Create __iommu_alloc_identity_domain() Vasant Hegde
2024-10-29 9:38 ` Joerg Roedel
2024-10-29 10:06 ` Vasant Hegde
2024-10-29 10:11 ` Joerg Roedel
2024-10-29 11:44 ` Jason Gunthorpe
2024-10-29 16:34 ` Vasant Hegde
2024-10-29 9:09 ` [PATCH v5 00/12] iommu: Domain allocation enhancements Joerg Roedel
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=b2bedf29-8757-4769-b4b3-064a8157a63c@intel.com \
--to=yi.l.liu@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jacob.pan@linux.microsoft.com \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=robin.murphy@arm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.com \
--cc=will@kernel.org \
/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