From: Jason Gunthorpe <jgg@ziepe.ca>
To: Baolu Lu <baolu.lu@linux.intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
Nicolin Chen <nicolinc@nvidia.com>, Yi Liu <yi.l.liu@intel.com>,
Jacob Pan <jacob.jun.pan@linux.intel.com>,
Joel Granados <j.granados@samsung.com>,
iommu@lists.linux.dev, virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/8] iommu/sva: Use iopf domain attach/detach interface
Date: Fri, 22 Mar 2024 13:59:27 -0300 [thread overview]
Message-ID: <20240322165927.GG66976@ziepe.ca> (raw)
In-Reply-To: <b33bf29b-2fe5-4a2a-a2ce-9fd8d67c5f6f@linux.intel.com>
On Thu, Mar 14, 2024 at 03:41:23PM +0800, Baolu Lu wrote:
> The whole cookie mechanism aims to address two things:
>
> - Extend the domain lifetime until all pending page faults are
> resolved.
Like you answered, I think the flush is a simpler scheme..
> - Associate information about the iommu device with each attachment of
> the domain so that the iommufd device object ID could be quickly
> retrieved in the fault delivering path.
> > I see we also need to stick a pointer in the domain for iommufd to get
> > back to the hwpt, but that doesn't seem to need such a big system to
> > accomplish - just add a void *. It would make sense for the domain to
> > have some optional pointer to a struct for all the fault related data
> > that becomes allocated when a PRI domain is created..
>
> It's not getting back hwpt from domain, just getting the iommufd_device
> in the fault delivering path. The iommufd_device is not per-domain, but
> per-domain-attachment.
It does make sense you'd need that, but I think something like this is
a more direct way to get it. Caller allocates the handle struct. The
iopf will provide the handle from the XA to the
callback. container_of() not void * is used to in the caller's API.
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 68e648b5576706..0d29d8f0847cd9 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -46,6 +46,8 @@ static unsigned int iommu_def_domain_type __read_mostly;
static bool iommu_dma_strict __read_mostly = IS_ENABLED(CONFIG_IOMMU_DEFAULT_DMA_STRICT);
static u32 iommu_cmd_line __read_mostly;
+enum { IOMMU_PASID_ARRAY_DOMAIN, IOMMU_PASID_ARRAY_HANDLE };
+
struct iommu_group {
struct kobject kobj;
struct kobject *devices_kobj;
@@ -3516,18 +3518,20 @@ static void __iommu_remove_group_pasid(struct iommu_group *group,
}
/*
- * iommu_attach_device_pasid() - Attach a domain to pasid of device
+ * __iommu_attach_device_pasid() - Attach a domain to pasid of device
* @domain: the iommu domain.
* @dev: the attached device.
* @pasid: the pasid of the device.
*
* Return: 0 on success, or an error.
*/
-int iommu_attach_device_pasid(struct iommu_domain *domain,
- struct device *dev, ioasid_t pasid)
+int __iommu_attach_device_pasid(struct iommu_domain *domain, struct device *dev,
+ ioasid_t pasid,
+ struct iommu_pasid_handle *handle)
{
/* Caller must be a probed driver on dev */
struct iommu_group *group = dev->iommu_group;
+ void *xa_entry;
void *curr;
int ret;
@@ -3541,9 +3545,14 @@ int iommu_attach_device_pasid(struct iommu_domain *domain,
return -EINVAL;
mutex_lock(&group->mutex);
- curr = xa_cmpxchg(&group->pasid_array, pasid, NULL, domain, GFP_KERNEL);
+ if (handle)
+ xa_entry = xa_tag_pointer(handle, IOMMU_PASID_ARRAY_HANDLE);
+ else
+ xa_entry = xa_tag_pointer(domain, IOMMU_PASID_ARRAY_DOMAIN);
+ curr = xa_cmpxchg(&group->pasid_array, pasid, NULL, xa_entry,
+ GFP_KERNEL);
if (curr) {
- ret = xa_err(curr) ? : -EBUSY;
+ ret = xa_err(curr) ?: -EBUSY;
goto out_unlock;
}
@@ -3556,7 +3565,7 @@ int iommu_attach_device_pasid(struct iommu_domain *domain,
mutex_unlock(&group->mutex);
return ret;
}
-EXPORT_SYMBOL_GPL(iommu_attach_device_pasid);
+EXPORT_SYMBOL_GPL(__iommu_attach_device_pasid);
/*
* iommu_detach_device_pasid() - Detach the domain from pasid of device
@@ -3600,13 +3609,23 @@ struct iommu_domain *iommu_get_domain_for_dev_pasid(struct device *dev,
{
/* Caller must be a probed driver on dev */
struct iommu_group *group = dev->iommu_group;
+ struct iommu_pasid_handle *handle;
struct iommu_domain *domain;
+ void *xa_entry;
if (!group)
return NULL;
xa_lock(&group->pasid_array);
- domain = xa_load(&group->pasid_array, pasid);
+ xa_entry = xa_load(&group->pasid_array, pasid);
+ if (xa_pointer_tag(xa_entry) == IOMMU_PASID_ARRAY_HANDLE) {
+ handle = xa_untag_pointer(xa_entry);
+ domain = handle->domain;
+ } else if (xa_pointer_tag(xa_entry) == IOMMU_PASID_ARRAY_DOMAIN) {
+ domain = xa_untag_pointer(xa_entry);
+ } else {
+ domain = NULL;
+ }
if (type && domain && domain->type != type)
domain = ERR_PTR(-EBUSY);
xa_unlock(&group->pasid_array);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 1ea2a820e1eb03..47c121d4e13f65 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -947,8 +947,27 @@ void iommu_device_release_dma_owner(struct device *dev);
struct iommu_domain *iommu_sva_domain_alloc(struct device *dev,
struct mm_struct *mm);
-int iommu_attach_device_pasid(struct iommu_domain *domain,
- struct device *dev, ioasid_t pasid);
+
+struct iommu_pasid_handle {
+ struct iommu_domain *domain;
+};
+
+int __iommu_attach_device_pasid(struct iommu_domain *domain, struct device *dev,
+ ioasid_t pasid,
+ struct iommu_pasid_handle *handle);
+
+static inline int iommu_attach_device_pasid(struct iommu_domain *domain,
+ struct device *dev, ioasid_t pasid)
+{
+ return __iommu_attach_device_pasid(domain, dev, pasid, NULL);
+}
+static inline int
+iommu_attach_device_pasid_handle(struct iommu_pasid_handle *handle,
+ struct device *dev, ioasid_t pasid)
+{
+ return __iommu_attach_device_pasid(handle->domain, dev, pasid, handle);
+}
+
void iommu_detach_device_pasid(struct iommu_domain *domain,
struct device *dev, ioasid_t pasid);
struct iommu_domain *
next prev parent reply other threads:[~2024-03-22 16:59 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 7:38 [PATCH v3 0/8] IOMMUFD: Deliver IO page faults to user space Lu Baolu
2024-01-22 7:38 ` [PATCH v3 1/8] iommu: Add iopf domain attach/detach/replace interface Lu Baolu
2024-02-07 8:11 ` Tian, Kevin
2024-02-21 5:52 ` Baolu Lu
2024-02-21 6:49 ` Tian, Kevin
2024-02-21 7:21 ` Baolu Lu
2024-02-21 7:22 ` Tian, Kevin
2024-01-22 7:38 ` [PATCH v3 2/8] iommu/sva: Use iopf domain attach/detach interface Lu Baolu
2024-03-08 17:46 ` Jason Gunthorpe
2024-03-14 7:41 ` Baolu Lu
2024-03-22 16:59 ` Jason Gunthorpe [this message]
2024-03-25 3:52 ` Baolu Lu
2024-01-22 7:38 ` [PATCH v3 3/8] iommufd: Add fault and response message definitions Lu Baolu
2024-03-08 17:50 ` Jason Gunthorpe
2024-03-14 13:41 ` Baolu Lu
2024-03-22 17:04 ` Jason Gunthorpe
2024-03-25 3:57 ` Baolu Lu
2024-01-22 7:38 ` [PATCH v3 4/8] iommufd: Add iommufd fault object Lu Baolu
2024-03-08 18:03 ` Jason Gunthorpe
2024-03-15 1:46 ` Baolu Lu
2024-03-22 17:09 ` Jason Gunthorpe
2024-03-25 5:01 ` Baolu Lu
2024-03-20 16:18 ` Shameerali Kolothum Thodi
2024-03-22 17:22 ` Jason Gunthorpe
2024-03-25 3:26 ` Baolu Lu
2024-03-25 4:02 ` Baolu Lu
2024-01-22 7:39 ` [PATCH v3 5/8] iommufd: Associate fault object with iommufd_hw_pgtable Lu Baolu
2024-02-07 8:14 ` Tian, Kevin
2024-02-21 6:06 ` Baolu Lu
2024-03-02 2:36 ` Zhangfei Gao
2024-03-06 15:15 ` Zhangfei Gao
2024-03-06 16:01 ` Jason Gunthorpe
2024-03-07 1:54 ` Baolu Lu
2024-03-08 17:19 ` Jason Gunthorpe
2024-03-08 19:05 ` Jason Gunthorpe
2024-03-15 1:16 ` Baolu Lu
2024-03-22 17:06 ` Jason Gunthorpe
2024-03-25 4:59 ` Baolu Lu
2024-01-22 7:39 ` [PATCH v3 6/8] iommufd: IOPF-capable hw page table attach/detach/replace Lu Baolu
2024-02-20 13:57 ` Joel Granados
2024-02-21 6:15 ` Baolu Lu
2024-01-22 7:39 ` [PATCH v3 7/8] iommufd/selftest: Add IOPF support for mock device Lu Baolu
2024-01-22 7:39 ` [PATCH v3 8/8] iommufd/selftest: Add coverage for IOPF test Lu Baolu
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=20240322165927.GG66976@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=j.granados@samsung.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robin.murphy@arm.com \
--cc=virtualization@lists.linux-foundation.org \
--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.