The iopf enablement has been moved to the iommu drivers. It is unnecessary
for iommufd to handle iopf enablement. Remove the iopf enablement logic to
avoid duplication.
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
---
drivers/iommu/iommufd/device.c | 1 -
drivers/iommu/iommufd/fault.c | 111 ++++++------------------
drivers/iommu/iommufd/iommufd_private.h | 3 -
3 files changed, 28 insertions(+), 87 deletions(-)
diff --git a/drivers/iommu/iommufd/device.c b/drivers/iommu/iommufd/device.c
index dfd0898fb6c1..47e36456b438 100644
--- a/drivers/iommu/iommufd/device.c
+++ b/drivers/iommu/iommufd/device.c
@@ -215,7 +215,6 @@ struct iommufd_device *iommufd_device_bind(struct iommufd_ctx *ictx,
refcount_inc(&idev->obj.users);
/* igroup refcount moves into iommufd_device */
idev->igroup = igroup;
- mutex_init(&idev->iopf_lock);
/*
* If the caller fails after this success it must call
diff --git a/drivers/iommu/iommufd/fault.c b/drivers/iommu/iommufd/fault.c
index d9a937450e55..4776c632cff2 100644
--- a/drivers/iommu/iommufd/fault.c
+++ b/drivers/iommu/iommufd/fault.c
@@ -17,49 +17,6 @@
#include "../iommu-priv.h"
#include "iommufd_private.h"
-static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
-{
- struct device *dev = idev->dev;
- int ret;
-
- /*
- * Once we turn on PCI/PRI support for VF, the response failure code
- * should not be forwarded to the hardware due to PRI being a shared
- * resource between PF and VFs. There is no coordination for this
- * shared capability. This waits for a vPRI reset to recover.
- */
- if (dev_is_pci(dev)) {
- struct pci_dev *pdev = to_pci_dev(dev);
-
- if (pdev->is_virtfn && pci_pri_supported(pdev))
- return -EINVAL;
- }
-
- mutex_lock(&idev->iopf_lock);
- /* Device iopf has already been on. */
- if (++idev->iopf_enabled > 1) {
- mutex_unlock(&idev->iopf_lock);
- return 0;
- }
-
- ret = iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_IOPF);
- if (ret)
- --idev->iopf_enabled;
- mutex_unlock(&idev->iopf_lock);
-
- return ret;
-}
-
-static void iommufd_fault_iopf_disable(struct iommufd_device *idev)
-{
- mutex_lock(&idev->iopf_lock);
- if (!WARN_ON(idev->iopf_enabled == 0)) {
- if (--idev->iopf_enabled == 0)
- iommu_dev_disable_feature(idev->dev, IOMMU_DEV_FEAT_IOPF);
- }
- mutex_unlock(&idev->iopf_lock);
-}
-
static int __fault_domain_attach_dev(struct iommufd_hw_pagetable *hwpt,
struct iommufd_device *idev)
{
@@ -82,20 +39,23 @@ static int __fault_domain_attach_dev(struct iommufd_hw_pagetable *hwpt,
int iommufd_fault_domain_attach_dev(struct iommufd_hw_pagetable *hwpt,
struct iommufd_device *idev)
{
- int ret;
-
if (!hwpt->fault)
return -EINVAL;
- ret = iommufd_fault_iopf_enable(idev);
- if (ret)
- return ret;
+ /*
+ * Once we turn on PCI/PRI support for VF, the response failure code
+ * should not be forwarded to the hardware due to PRI being a shared
+ * resource between PF and VFs. There is no coordination for this
+ * shared capability. This waits for a vPRI reset to recover.
+ */
+ if (dev_is_pci(idev->dev)) {
+ struct pci_dev *pdev = to_pci_dev(idev->dev);
- ret = __fault_domain_attach_dev(hwpt, idev);
- if (ret)
- iommufd_fault_iopf_disable(idev);
+ if (pdev->is_virtfn && pci_pri_supported(pdev))
+ return -EINVAL;
+ }
- return ret;
+ return __fault_domain_attach_dev(hwpt, idev);
}
static void iommufd_auto_response_faults(struct iommufd_hw_pagetable *hwpt,
@@ -155,13 +115,12 @@ void iommufd_fault_domain_detach_dev(struct iommufd_hw_pagetable *hwpt,
handle = iommufd_device_get_attach_handle(idev);
iommu_detach_group_handle(hwpt->domain, idev->igroup->group);
iommufd_auto_response_faults(hwpt, handle);
- iommufd_fault_iopf_disable(idev);
kfree(handle);
}
-static int __fault_domain_replace_dev(struct iommufd_device *idev,
- struct iommufd_hw_pagetable *hwpt,
- struct iommufd_hw_pagetable *old)
+int iommufd_fault_domain_replace_dev(struct iommufd_device *idev,
+ struct iommufd_hw_pagetable *hwpt,
+ struct iommufd_hw_pagetable *old)
{
struct iommufd_attach_handle *handle, *curr = NULL;
int ret;
@@ -170,6 +129,19 @@ static int __fault_domain_replace_dev(struct iommufd_device *idev,
curr = iommufd_device_get_attach_handle(idev);
if (hwpt->fault) {
+ /*
+ * Once we turn on PCI/PRI support for VF, the response failure code
+ * should not be forwarded to the hardware due to PRI being a shared
+ * resource between PF and VFs. There is no coordination for this
+ * shared capability. This waits for a vPRI reset to recover.
+ */
+ if (dev_is_pci(idev->dev)) {
+ struct pci_dev *pdev = to_pci_dev(idev->dev);
+
+ if (pdev->is_virtfn && pci_pri_supported(pdev))
+ return -EINVAL;
+ }
+
handle = kzalloc(sizeof(*handle), GFP_KERNEL);
if (!handle)
return -ENOMEM;
@@ -190,33 +162,6 @@ static int __fault_domain_replace_dev(struct iommufd_device *idev,
return ret;
}
-int iommufd_fault_domain_replace_dev(struct iommufd_device *idev,
- struct iommufd_hw_pagetable *hwpt,
- struct iommufd_hw_pagetable *old)
-{
- bool iopf_off = !hwpt->fault && old->fault;
- bool iopf_on = hwpt->fault && !old->fault;
- int ret;
-
- if (iopf_on) {
- ret = iommufd_fault_iopf_enable(idev);
- if (ret)
- return ret;
- }
-
- ret = __fault_domain_replace_dev(idev, hwpt, old);
- if (ret) {
- if (iopf_on)
- iommufd_fault_iopf_disable(idev);
- return ret;
- }
-
- if (iopf_off)
- iommufd_fault_iopf_disable(idev);
-
- return 0;
-}
-
void iommufd_fault_destroy(struct iommufd_object *obj)
{
struct iommufd_fault *fault = container_of(obj, struct iommufd_fault, obj);
diff --git a/drivers/iommu/iommufd/iommufd_private.h b/drivers/iommu/iommufd/iommufd_private.h
index 0b1bafc7fd99..0eb3779db156 100644
--- a/drivers/iommu/iommufd/iommufd_private.h
+++ b/drivers/iommu/iommufd/iommufd_private.h
@@ -399,9 +399,6 @@ struct iommufd_device {
/* always the physical device */
struct device *dev;
bool enforce_cache_coherency;
- /* protect iopf_enabled counter */
- struct mutex iopf_lock;
- unsigned int iopf_enabled;
};
static inline struct iommufd_device *
--
2.43.0On Fri, Feb 14, 2025 at 02:11:03PM +0800, Lu Baolu wrote: > The iopf enablement has been moved to the iommu drivers. It is unnecessary > for iommufd to handle iopf enablement. Remove the iopf enablement logic to > avoid duplication. > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > --- > drivers/iommu/iommufd/device.c | 1 - > drivers/iommu/iommufd/fault.c | 111 ++++++------------------ > drivers/iommu/iommufd/iommufd_private.h | 3 - > 3 files changed, 28 insertions(+), 87 deletions(-) Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Jason
On Fri, Feb 14, 2025 at 02:11:03PM +0800, Lu Baolu wrote: > The iopf enablement has been moved to the iommu drivers. It is unnecessary > for iommufd to handle iopf enablement. Remove the iopf enablement logic to > avoid duplication. > > Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> > --- > drivers/iommu/iommufd/device.c | 1 - > drivers/iommu/iommufd/fault.c | 111 ++++++------------------ > drivers/iommu/iommufd/iommufd_private.h | 3 - > 3 files changed, 28 insertions(+), 87 deletions(-) This is in conflict with my fault patches that Jason just took a couple days ago: https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/log/?h=for-next I think it needs a rebase, perhaps on the branch mentioned here: https://lore.kernel.org/linux-iommu/20250213150836.GC3754072@nvidia.com/ Thanks Nicolin
On 2/14/25 15:06, Nicolin Chen wrote: > On Fri, Feb 14, 2025 at 02:11:03PM +0800, Lu Baolu wrote: >> The iopf enablement has been moved to the iommu drivers. It is unnecessary >> for iommufd to handle iopf enablement. Remove the iopf enablement logic to >> avoid duplication. >> >> Signed-off-by: Lu Baolu<baolu.lu@linux.intel.com> >> --- >> drivers/iommu/iommufd/device.c | 1 - >> drivers/iommu/iommufd/fault.c | 111 ++++++------------------ >> drivers/iommu/iommufd/iommufd_private.h | 3 - >> 3 files changed, 28 insertions(+), 87 deletions(-) > This is in conflict with my fault patches that Jason just took > a couple days ago: > https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/log/? > h=for-next > > I think it needs a rebase, perhaps on the branch mentioned here: > https://lore.kernel.org/linux-iommu/20250213150836.GC3754072@nvidia.com/ Yes, sure. I will rebase it in the next version to avoid the conflict. Thanks, baolu
On Sat, Feb 15, 2025 at 02:32:32PM +0800, Baolu Lu wrote: > On 2/14/25 15:06, Nicolin Chen wrote: > > On Fri, Feb 14, 2025 at 02:11:03PM +0800, Lu Baolu wrote: > > > The iopf enablement has been moved to the iommu drivers. It is unnecessary > > > for iommufd to handle iopf enablement. Remove the iopf enablement logic to > > > avoid duplication. > > > > > > Signed-off-by: Lu Baolu<baolu.lu@linux.intel.com> > > > --- > > > drivers/iommu/iommufd/device.c | 1 - > > > drivers/iommu/iommufd/fault.c | 111 ++++++------------------ > > > drivers/iommu/iommufd/iommufd_private.h | 3 - > > > 3 files changed, 28 insertions(+), 87 deletions(-) > > This is in conflict with my fault patches that Jason just took > > a couple days ago: > > https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/log/? > > h=for-next > > > > I think it needs a rebase, perhaps on the branch mentioned here: > > https://lore.kernel.org/linux-iommu/20250213150836.GC3754072@nvidia.com/ > > Yes, sure. I will rebase it in the next version to avoid the conflict. That's troublesome, I think just leave it so Joerg can pick it up. We can figure out what to do with the conflict later. Jason
On 2025/2/18 21:06, Jason Gunthorpe wrote: > On Sat, Feb 15, 2025 at 02:32:32PM +0800, Baolu Lu wrote: >> On 2/14/25 15:06, Nicolin Chen wrote: >>> On Fri, Feb 14, 2025 at 02:11:03PM +0800, Lu Baolu wrote: >>>> The iopf enablement has been moved to the iommu drivers. It is unnecessary >>>> for iommufd to handle iopf enablement. Remove the iopf enablement logic to >>>> avoid duplication. >>>> >>>> Signed-off-by: Lu Baolu<baolu.lu@linux.intel.com> >>>> --- >>>> drivers/iommu/iommufd/device.c | 1 - >>>> drivers/iommu/iommufd/fault.c | 111 ++++++------------------ >>>> drivers/iommu/iommufd/iommufd_private.h | 3 - >>>> 3 files changed, 28 insertions(+), 87 deletions(-) >>> This is in conflict with my fault patches that Jason just took >>> a couple days ago: >>> https://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd.git/log/? >>> h=for-next >>> >>> I think it needs a rebase, perhaps on the branch mentioned here: >>> https://lore.kernel.org/linux-iommu/20250213150836.GC3754072@nvidia.com/ >> Yes, sure. I will rebase it in the next version to avoid the conflict. > That's troublesome, I think just leave it so Joerg can pick it up. We > can figure out what to do with the conflict later. Okay, sure.
© 2016 - 2025 Red Hat, Inc.