From: Jason Gunthorpe <jgg@nvidia.com>
To: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>
Subject: [PATCH 1/2] iommu/fsl: Do not use iommu_group_remove_device() under ops->device_group()
Date: Mon, 15 May 2023 21:27:08 -0300 [thread overview]
Message-ID: <1-v1-8fb05192ea02+e5-fsl_rm_groups_jgg@nvidia.com> (raw)
In-Reply-To: <0-v1-8fb05192ea02+e5-fsl_rm_groups_jgg@nvidia.com>
This API is expected to be used only by POWER and VFIO no-iommu that
manually manage the group lifecycle. It should not be called under
ops->device_group().
This is already buggy as is since the core code does not expect a probed
driver to loose it's iommu_group without also releasing the device.
FSL seems to be trying to block the platform_device that represents the
pci_controller, eg the thing passed to fsl_add_bridge(), from having an
iommu_group.
Instead of creating an iommu_group that we don't want and then later
removing it, just don't create it at all in the first place.
For the 'pci_endpt_partitioning' case every PCI device already gets its
own iommu_group through the standard code, so it is unclear why having a
dedicated group for the controller could be problematic.
For the other case, the controller group was being used to bizarrely
de-duplicate the group in it's hose. Instead just directly create a group
for the hose the first time we encounter it. The code already searches the
entire hose to find any iommu_group. Again, it is unclear why having the
pci_controller inside the same iommu_group as the PCI devices would be
harmful.
In any case, this is a cleaner way to not enable iommu support for the
platform_device.
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
---
drivers/iommu/fsl_pamu_domain.c | 42 ++++++++++++++++-----------------
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
index bce37229709965..bf045f58cd50ae 100644
--- a/drivers/iommu/fsl_pamu_domain.c
+++ b/drivers/iommu/fsl_pamu_domain.c
@@ -11,6 +11,7 @@
#include <linux/platform_device.h>
#include <sysdev/fsl_pci.h>
+#include <linux/pci.h>
/*
* Global spinlock that needs to be held while
@@ -379,7 +380,21 @@ static struct iommu_group *get_shared_pci_device_group(struct pci_dev *pdev)
bus = bus->parent;
}
- return NULL;
+ return iommu_group_alloc();
+}
+
+static int __is_pci_controller_parent(struct device *dev, void *data)
+{
+ struct pci_dev *pdev = to_pci_dev(dev);
+ struct pci_controller *pci_ctl = pci_bus_to_host(pdev->bus);
+
+ return dev == pci_ctl->parent;
+}
+
+static bool is_pci_controller_parent(struct device *dev)
+{
+ return bus_for_each_dev(&pci_bus_type, NULL, NULL,
+ __is_pci_controller_parent);
}
static struct iommu_group *get_pci_device_group(struct pci_dev *pdev)
@@ -393,30 +408,12 @@ static struct iommu_group *get_pci_device_group(struct pci_dev *pdev)
/* We can partition PCIe devices so assign device group to the device */
if (pci_endpt_partitioning) {
group = pci_device_group(&pdev->dev);
-
- /*
- * PCIe controller is not a paritionable entity
- * free the controller device iommu_group.
- */
- if (pci_ctl->parent->iommu_group)
- iommu_group_remove_device(pci_ctl->parent);
} else {
/*
* All devices connected to the controller will share the
- * PCI controllers device group. If this is the first
- * device to be probed for the pci controller, copy the
- * device group information from the PCI controller device
- * node and remove the PCI controller iommu group.
- * For subsequent devices, the iommu group information can
- * be obtained from sibling devices (i.e. from the bus_devices
- * link list).
+ * same device group.
*/
- if (pci_ctl->parent->iommu_group) {
- group = get_device_iommu_group(pci_ctl->parent);
- iommu_group_remove_device(pci_ctl->parent);
- } else {
- group = get_shared_pci_device_group(pdev);
- }
+ group = get_shared_pci_device_group(pdev);
}
if (!group)
@@ -436,7 +433,8 @@ static struct iommu_group *fsl_pamu_device_group(struct device *dev)
*/
if (dev_is_pci(dev))
group = get_pci_device_group(to_pci_dev(dev));
- else if (of_get_property(dev->of_node, "fsl,liodn", &len))
+ else if (of_get_property(dev->of_node, "fsl,liodn", &len) &&
+ !is_pci_controller_parent(dev))
group = get_device_iommu_group(dev);
return group;
--
2.40.1
next prev parent reply other threads:[~2023-05-16 0:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 0:27 [PATCH 0/2] Remove iommu_group_remove_device() from fsl Jason Gunthorpe
2023-05-16 0:27 ` Jason Gunthorpe [this message]
2023-05-16 15:00 ` [PATCH 1/2] iommu/fsl: Do not use iommu_group_remove_device() under ops->device_group() Robin Murphy
2023-05-16 16:09 ` Jason Gunthorpe
2023-05-16 18:24 ` Robin Murphy
2023-05-16 19:52 ` Jason Gunthorpe
2023-05-16 0:27 ` [PATCH 2/2] iommu/fsl: Always allocate a group for non-pci devices Jason Gunthorpe
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=1-v1-8fb05192ea02+e5-fsl_rm_groups_jgg@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=robin.murphy@arm.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