From: Vasant Hegde <vasant.hegde@amd.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Baolu Lu <baolu.lu@linux.intel.com>,
iommu@lists.linux.dev, joro@8bytes.org, will@kernel.org,
robin.murphy@arm.com, suravee.suthikulpanit@amd.com,
yi.l.liu@intel.com, Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [PATCH RFCv2] iommu: Add domain type and flag to domain_alloc_paging()
Date: Wed, 7 Aug 2024 22:22:00 +0530 [thread overview]
Message-ID: <e5da0709-86d3-4b45-82cc-d995a2686afa@amd.com> (raw)
In-Reply-To: <20240807135915.GF8473@ziepe.ca>
Jason,
On 8/7/2024 7:29 PM, Jason Gunthorpe wrote:
> On Wed, Aug 07, 2024 at 03:00:50PM +0530, Vasant Hegde wrote:
>>
>> commit 312c2a99897937834f6a679b6f9956288e8c93de
>> Author: Vasant Hegde <vasant.hegde@amd.com>
>> Date: Wed Aug 7 14:42:24 2024 +0530
>>
>> vfio: User iommu_ops->domain_alloc_user() to allocate IOMMU domain
>>
>> - Include uapi/linux/iommufd.h in vfio_iommu_type1.c so that we can use
>> HWPT flags.
>> - Move dev_iommu_ops() from iommu-priv.h to linux/iommu.h
>>
>> Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
>
> Yeah, this seems like a good start
>
>> @@ -2134,8 +2135,14 @@ static void vfio_iommu_iova_insert_copy(struct vfio_iommu
>> *iommu,
>> static int vfio_iommu_domain_alloc(struct device *dev, void *data)
>> {
>> struct iommu_domain **domain = data;
>> + const struct iommu_ops *ops = dev_iommu_ops(dev);
>> + u32 flags = 0;
>> +
>> + if (ops->domain_alloc_user)
>> + *domain = ops->domain_alloc_user(dev, flags, NULL, NULL);
>> + else
>> + *domain = iommu_paging_domain_alloc(dev);
>
> I suggest to wrapper this in a EXPORT_SYMBOL rather than expose
> dev_iommu_ops ?
Sure. We can do that.
>
>> @@ -359,11 +359,14 @@ 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 : If set, allocate a HWPT that support PASID
>> + *
>> */
>
> Needs more words, maybe even two flags?
>
> @IOMMU_HWPT_ALLOC_DEV_PASID: When the domain is used on a device,
> with no PASID, the device will support later attaching a PASID as
> well. Some HW requires a specific domain format on the device to
> allow PASID to work.
I will add this.
>
> @IOMMU_HWPT_ALLOC_PASID: The domain can be used as a PASID. The
> domain attached to the device must have also been allocated with
> IOMMU_HWPT_ALLOC_DEV_PASID.
Why do we need this flag? Previous one is already allocated PASID capable
domain. Is this similar to SVA domain?
>
> And then we'd want to enforce this rule in iommufd to force userspace
> to use the flags properly. Otherwise AMD will be permanently broken :\
>
> I'm guessing that userspace will never want to share a PASID domain
> and a device domain, and current iommu HW will treat both flags as the
> same functionality (use the AMD v2 domain)
>
> Yi will need to accomodate these flags in his series..
>
> SMMUv3 support would look like this:
Thanks! I will put it as part of this series.
@Baolu, Do we need to make any changes to intel driver?
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 9bc50bded5af72..c2e46a352d6b09 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3052,7 +3052,9 @@ arm_smmu_domain_alloc_user(struct device *dev, u32 flags,
> const struct iommu_user_data *user_data)
> {
> struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> - const u32 PAGING_FLAGS = IOMMU_HWPT_ALLOC_DIRTY_TRACKING;
> + const u32 PAGING_FLAGS = IOMMU_HWPT_ALLOC_DIRTY_TRACKING |
> + IOMMU_HWPT_ALLOC_DEV_PASID |
> + IOMMU_HWPT_ALLOC_PASID;
> struct arm_smmu_domain *smmu_domain;
> int ret;
>
> @@ -3065,6 +3067,14 @@ arm_smmu_domain_alloc_user(struct device *dev, u32 flags,
> if (!smmu_domain)
> return ERR_PTR(-ENOMEM);
>
> + if (flags & (IOMMU_HWPT_ALLOC_DEV_PASID | IOMMU_HWPT_ALLOC_PASID)) {
> + if (!(master->smmu->features & ARM_SMMU_FEAT_TRANS_S1)) {
> + ret = -EOPNOTSUPP;
> + goto err_free;
> + }
> + smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
> + }
> +
> smmu_domain->domain.type = IOMMU_DOMAIN_UNMANAGED;
> smmu_domain->domain.ops = arm_smmu_ops.default_domain_ops;
> ret = arm_smmu_domain_finalise(smmu_domain, master->smmu, flags);
>
> (though this will clash with the nesting series I just sent)
If your series goes first then I can rebase it. Lets see.
-Vasant
next prev parent reply other threads:[~2024-08-07 16:52 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 14:45 [PATCH RFCv2] iommu: Add domain type and flag to domain_alloc_paging() Vasant Hegde
2024-08-02 0:44 ` Baolu Lu
2024-08-02 5:53 ` Vasant Hegde
2024-08-06 12:34 ` Jason Gunthorpe
2024-08-06 14:41 ` Vasant Hegde
2024-08-06 17:32 ` Jason Gunthorpe
2024-08-07 5:49 ` Baolu Lu
2024-08-07 9:32 ` Vasant Hegde
2024-08-07 12:33 ` Jason Gunthorpe
2024-08-07 9:30 ` Vasant Hegde
2024-08-07 13:59 ` Jason Gunthorpe
2024-08-07 16:52 ` Vasant Hegde [this message]
2024-08-07 18:29 ` Jason Gunthorpe
2024-08-08 1:16 ` Jason Gunthorpe
2024-08-08 13:08 ` Jason Gunthorpe
2024-08-09 6:43 ` Vasant Hegde
2024-08-09 13:44 ` Jason Gunthorpe
2024-08-12 9:21 ` Vasant Hegde
2024-08-13 16:22 ` Jason Gunthorpe
2024-08-14 10:54 ` Vasant Hegde
2024-08-09 5:36 ` Vasant Hegde
2024-08-12 12:07 ` Yi Liu
2024-08-13 9:40 ` Tian, Kevin
2024-08-13 16:20 ` Jason Gunthorpe
2024-08-14 2:38 ` Tian, Kevin
2024-08-14 22:40 ` Jason Gunthorpe
2024-08-15 3:28 ` Vasant Hegde
2024-08-15 4:58 ` Yi Liu
2024-08-15 13:06 ` Jason Gunthorpe
2024-08-16 11:59 ` Yi Liu
2024-08-15 4:59 ` Baolu Lu
2024-08-15 13:47 ` Jason Gunthorpe
2024-08-16 8:17 ` Vasant Hegde
2024-08-16 12:01 ` Yi Liu
2024-08-16 18:37 ` Jason Gunthorpe
2024-08-19 8:27 ` Vasant Hegde
2024-08-19 17:52 ` Jason Gunthorpe
2024-08-20 8:18 ` Vasant Hegde
2024-08-15 13:05 ` Jason Gunthorpe
2024-08-12 12:01 ` 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=e5da0709-86d3-4b45-82cc-d995a2686afa@amd.com \
--to=vasant.hegde@amd.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=robin.murphy@arm.com \
--cc=suravee.suthikulpanit@amd.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.