From: Baolu Lu <baolu.lu@linux.intel.com>
To: Vasant Hegde <vasant.hegde@amd.com>,
iommu@lists.linux.dev, joro@8bytes.org
Cc: baolu.lu@linux.intel.com, will@kernel.org, robin.murphy@arm.com,
suravee.suthikulpanit@amd.com, jgg@ziepe.ca, yi.l.liu@intel.com,
kevin.tian@intel.com
Subject: Re: [PATCH 1/5] iommu: Enhance domain allocation code to take additional flags
Date: Thu, 22 Aug 2024 09:38:31 +0800 [thread overview]
Message-ID: <a85e4bc3-0046-46fd-91e4-bac451574d11@linux.intel.com> (raw)
In-Reply-To: <20240821133554.7405-2-vasant.hegde@amd.com>
On 8/21/24 9:35 PM, Vasant Hegde wrote:
> From: Jason Gunthorpe<jgg@ziepe.ca>
>
> Currently drivers calls iommu_paging_domain_alloc(dev) to get an
> UNAMANAGED domain. This is not sufficient to support PASID with
> UNAMANAGED domain as some HW like AMD requires certain page table type
> to support PASIDs.
>
> Also domain_alloc_paging() passes device as param for domain
> allocation. This is not sufficient for AMD driver to decide the right
> page table.
>
> Hence add iommu_paging_domain_alloc_flags() API which takes flags as
> parameter. Also update default domain allocation path to use this new
> API whenever device is PASID capable. HW driver should implement
> domain_alloc_user() to allocate PASID capable domain.
>
> Finally introduce new flag (IOMMUFD_HWPT_ALLOC_PASID) to
> domain_alloc_users() ops. If both IOMMU and device supports PASID it
> will allocate domain. Otherwise return error.
I would suggest one patch for one thing. This will make the changes
easier to review, especially for those who don't have much context. It
might be helpful to split this into some smaller changes:
- Code refactoring with no functionality change;
- Introduce new domain allocation API;
- Introduce domain allocation flag;
- Code refactoring afterwards.
>
> Signed-off-by: Jason Gunthorpe<jgg@ziepe.ca>
> [Added __iommu_paging_domain_alloc_flags() and description - Vasant]
> Signed-off-by: Vasant Hegde<vasant.hegde@amd.com>
[...]
> ---+static struct iommu_domain *__iommu_paging_domain_alloc_flags(struct device *dev,
> + unsigned int type,
> + unsigned int flags)
> +{
> + const struct iommu_ops *ops = dev_iommu_ops(dev);
> + struct iommu_domain *domain;
> +
> + if (!dev_has_iommu(dev))
> + return ERR_PTR(-ENODEV);
This check is unnecessary as you have already called dev_iommu_ops(),
which assumes that the device is iommu probed.
If you are worrying about the caller passing a non-iommu-probed device,
you can make it like this:
const struct iommu_ops *ops;
if (!dev_has_iommu(dev))
return ERR_PTR(-ENODEV);
ops = dev_iommu_ops(dev);
> +
> + if (ops->domain_alloc_paging && !flags)
> + domain = ops->domain_alloc_paging(dev);
> + else if (ops->domain_alloc_user)
> + domain = ops->domain_alloc_user(dev, flags, NULL, NULL);
> + else if (ops->domain_alloc && !flags)
> + domain = ops->domain_alloc(IOMMU_DOMAIN_UNMANAGED);
> + else
> + return ERR_PTR(-EOPNOTSUPP);
> +
> + if (IS_ERR(domain))
> + return domain;
> + if (!domain)
> + return ERR_PTR(-ENOMEM);
> +
> + iommu_domain_init(domain, type, ops);
> + return domain;
> +}
> +
> /**
> - * iommu_paging_domain_alloc() - Allocate a paging domain
> + * iommu_paging_domain_alloc_flags() - Allocate a paging domain
> * @dev: device for which the domain is allocated
> + * @flags: Bitmap of iommufd_hwpt_alloc_flags
> *
> * Allocate a paging domain which will be managed by a kernel driver. Return
> * allocated domain if successful, or a ERR pointer for failure.
> */
> -struct iommu_domain *iommu_paging_domain_alloc(struct device *dev)
> +struct iommu_domain *iommu_paging_domain_alloc_flags(struct device *dev,
> + unsigned int flags)
> {
> - if (!dev_has_iommu(dev))
> - return ERR_PTR(-ENODEV);
> -
> - return __iommu_domain_alloc(dev_iommu_ops(dev), dev, IOMMU_DOMAIN_UNMANAGED);
> + return __iommu_paging_domain_alloc_flags(dev,
> + IOMMU_DOMAIN_UNMANAGED, flags);
> }
> -EXPORT_SYMBOL_GPL(iommu_paging_domain_alloc);
> +EXPORT_SYMBOL_GPL(iommu_paging_domain_alloc_flags);
Some external modules are still using iommu_paging_domain_alloc(). Would
it break the kernel build if you simply remove it here?
[...]
Thanks,
baolu
next prev parent reply other threads:[~2024-08-22 1:42 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-21 13:35 [PATCH 0/5] iommu: Domain allocation enhancements Vasant Hegde
2024-08-21 13:35 ` [PATCH 1/5] iommu: Enhance domain allocation code to take additional flags Vasant Hegde
2024-08-21 16:31 ` Jason Gunthorpe
2024-08-22 1:50 ` Baolu Lu
2024-08-22 12:43 ` Jason Gunthorpe
2024-08-23 2:47 ` Baolu Lu
2024-08-26 8:08 ` Tian, Kevin
2024-08-26 8:34 ` Baolu Lu
2024-08-26 8:59 ` Tian, Kevin
2024-08-26 13:51 ` Jason Gunthorpe
2024-08-26 8:47 ` Vasant Hegde
2024-08-26 13:45 ` Jason Gunthorpe
2024-08-22 11:27 ` Yi Liu
2024-08-22 12:44 ` Jason Gunthorpe
2024-08-23 8:58 ` Yi Liu
2024-08-24 14:47 ` Vasant Hegde
2024-08-28 21:52 ` Jacob Pan
2024-08-29 10:51 ` Vasant Hegde
2024-08-29 12:10 ` Jason Gunthorpe
2024-08-29 12:47 ` Vasant Hegde
2024-08-29 13:11 ` Jason Gunthorpe
2024-09-11 10:54 ` Vasant Hegde
2024-08-29 17:40 ` Jacob Pan
[not found] ` <66d0b2a1.630a0220.1dd301.daceSMTPIN_ADDED_BROKEN@mx.google.com>
2024-08-30 15:00 ` Jason Gunthorpe
2024-08-26 8:36 ` Vasant Hegde
2024-08-26 13:56 ` Jason Gunthorpe
2024-08-29 12:34 ` Vasant Hegde
2024-08-22 1:38 ` Baolu Lu [this message]
2024-08-22 12:40 ` Jason Gunthorpe
2024-08-23 2:04 ` Baolu Lu
2024-08-26 6:09 ` Vasant Hegde
2024-08-22 2:10 ` kernel test robot
2024-08-22 3:03 ` kernel test robot
2024-08-22 5:07 ` kernel test robot
2024-08-21 13:35 ` [PATCH 2/5] iommu/amd: Separate page table setup from domain allocation Vasant Hegde
2024-08-21 16:40 ` Jason Gunthorpe
2024-08-21 13:35 ` [PATCH 3/5] iommu/amd: Pass page table type to pdomain_setup_pgtable() Vasant Hegde
2024-08-21 13:35 ` [PATCH 4/5] iommu/amd: Enhance domain_alloc_user() to allocate PASID capable domain Vasant Hegde
2024-08-21 13:35 ` [PATCH 5/5] iommu/amd: Add iommu_ops->domain_alloc_paging support Vasant Hegde
2024-08-21 15:57 ` Jason Gunthorpe
2024-09-11 10:44 ` Vasant Hegde
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=a85e4bc3-0046-46fd-91e4-bac451574d11@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--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 \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox