search for: iommu_group_get

...to see basically > > if (fastmodel) > a pile of special work-arounds > else > not less hacky but more common virtio work-arounds > > :) > > And then I can apply whatever comes from @arm.com and not > worry about breaking actual hardware. What we could do is call iommu_group_get(&vdev->dev) for legacy devices if CONFIG_ARM64. If that returns non-NULL, then we know that the device is upstream of an SMMU, which means it must be the fastmodel. Will

...to see basically > > if (fastmodel) > a pile of special work-arounds > else > not less hacky but more common virtio work-arounds > > :) > > And then I can apply whatever comes from @arm.com and not > worry about breaking actual hardware. What we could do is call iommu_group_get(&vdev->dev) for legacy devices if CONFIG_ARM64. If that returns non-NULL, then we know that the device is upstream of an SMMU, which means it must be the fastmodel. Will

...v, NULL); + if (ret) + goto err_out; + + /* + * Try to allocate a default domain - needs support from the + * IOMMU driver. There are still some drivers which don't + * support default domains, so the return value is not yet + * checked. + */ + iommu_alloc_default_domain(dev); + + group = iommu_group_get(dev); + if (!group) + goto err_release; + + if (group->default_domain) + ret = __iommu_attach_device(group->default_domain, dev); + + iommu_group_put(group); + + if (ret) + goto err_release; + + if (ops->probe_finalize) + ops->probe_finalize(dev); + + return 0; + +err_release: + iom...

Hi Baolu, On Wed, Apr 15, 2020 at 02:10:03PM +0800, Lu Baolu wrote: > On 2020/4/14 21:15, Joerg Roedel wrote: > > > + /* Device is probed already if in a group */ > > + if (iommu_group_get(dev) != NULL) > > Same as > if (iommu_group_get(dev)) > ? > > By the way, do we need to put the group if device has already been > probed? Right, fixed both, thank you. Regards, Joerg

From: Joerg Roedel <jroedel at suse.de> Well, not really. The call to iommu_alloc_default_domain() in iommu_group_get_for_dev() has to stay around as long as there are IOMMU drivers using the add/remove_device() call-backs instead of probe/release_device(). Those drivers expect that iommu_group_get_for_dev() returns the device attached to a group and the group set up with a default domain (and the device attached...

...> >> else > >> not less hacky but more common virtio work-arounds > >> > >> :) > >> > >> And then I can apply whatever comes from @arm.com and not > >> worry about breaking actual hardware. > > > > What we could do is call iommu_group_get(&vdev->dev) for legacy > > Actually, that should be vdev->dev.parent - I'm now not sure quite what > I managed to successfully test yesterday, but apparently it wasn't this > patch :( > > > devices if CONFIG_ARM64. If that returns non-NULL, then we know that...

...> >> else > >> not less hacky but more common virtio work-arounds > >> > >> :) > >> > >> And then I can apply whatever comes from @arm.com and not > >> worry about breaking actual hardware. > > > > What we could do is call iommu_group_get(&vdev->dev) for legacy > > Actually, that should be vdev->dev.parent - I'm now not sure quite what > I managed to successfully test yesterday, but apparently it wasn't this > patch :( > > > devices if CONFIG_ARM64. If that returns non-NULL, then we know that...

...if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL) return -EINVAL; + /* + * Filter out virtio devices that do not honor the iommu, + * but only for real iommu groups. + */ + if (vfio_pci_is_virtio(pdev)) { + struct iommu_group *tmp = iommu_group_get(&pdev->dev); + + if (tmp) { + iommu_group_put(tmp); + + ret = vfio_pci_virtio_quirk(pdev); + if (ret) + return ret; + } + } + group = vfio_iommu_group_get...

...if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL) return -EINVAL; + /* + * Filter out virtio devices that do not honor the iommu, + * but only for real iommu groups. + */ + if (vfio_pci_is_virtio(pdev)) { + struct iommu_group *tmp = iommu_group_get(&pdev->dev); + + if (tmp) { + iommu_group_put(tmp); + + ret = vfio_pci_virtio_quirk(pdev); + if (ret) + return ret; + } + } + group = vfio_iommu_group_get...

...U drivers with ability to decide whether the > implicit backing for a device is appropriate? Like this: > > bool implicit_iommu_for_dma_is_allowed(struct device *dev) > { > const struct iommu_ops *ops = dev->bus->iommu_ops; > struct iommu_group *group; > > group = iommu_group_get(dev); > if (!group) > return NULL; > > iommu_group_put(group); > > if (!ops->implicit_iommu_for_dma_is_allowed) > return true; > > return ops->implicit_iommu_for_dma_is_allowed(dev); > } > > Then arch_setup_dma_ops() could have a clue whether im...

...describe HW. What about to grant IOMMU drivers with ability to decide whether the implicit backing for a device is appropriate? Like this: bool implicit_iommu_for_dma_is_allowed(struct device *dev) { const struct iommu_ops *ops = dev->bus->iommu_ops; struct iommu_group *group; group = iommu_group_get(dev); if (!group) return NULL; iommu_group_put(group); if (!ops->implicit_iommu_for_dma_is_allowed) return true; return ops->implicit_iommu_for_dma_is_allowed(dev); } Then arch_setup_dma_ops() could have a clue whether implicit IOMMU backing for a device is appropriate.

...vers/iommu/iommu.c index 834a45da0ed0..a2ff95424044 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -1615,6 +1615,10 @@ static int probe_iommu_group(struct device *dev, void *data) if (!dev_iommu_get(dev)) return -ENOMEM; + /* Device is probed already if in a group */ + if (iommu_group_get(dev) != NULL) + return 0; + if (!try_module_get(ops->owner)) { ret = -EINVAL; goto err_free_dev_iommu; @@ -1783,7 +1787,7 @@ static int iommu_group_create_direct_mappings(struct iommu_group *group) iommu_do_create_direct_mappings); } -static int bus_iommu_probe(struct bus_typ...

...vfio.c b/drivers/vfio/vfio.c index 6fd6fa5..67db231 100644 --- a/drivers/vfio/vfio.c +++ b/drivers/vfio/vfio.c @@ -756,6 +756,7 @@ int vfio_add_group_dev(struct device *dev, struct iommu_group *iommu_group; struct vfio_group *group; struct vfio_device *device; + int noiommu; iommu_group = iommu_group_get(dev); if (!iommu_group) @@ -791,6 +792,8 @@ int vfio_add_group_dev(struct device *dev, return PTR_ERR(device); } + noiommu = group->noiommu; + /* * Drop all but the vfio_device reference. The vfio_device holds * a reference to the vfio_group, which holds a reference to the @@ -...

...el) >> a pile of special work-arounds >> else >> not less hacky but more common virtio work-arounds >> >> :) >> >> And then I can apply whatever comes from @arm.com and not >> worry about breaking actual hardware. > > What we could do is call iommu_group_get(&vdev->dev) for legacy Actually, that should be vdev->dev.parent - I'm now not sure quite what I managed to successfully test yesterday, but apparently it wasn't this patch :( > devices if CONFIG_ARM64. If that returns non-NULL, then we know that > the device is upstream o...

...ce *dev) int iommu_probe_device(struct device *dev) { const struct iommu_ops *ops = dev->bus->iommu_ops; + struct iommu_group *group; int ret; WARN_ON(dev->iommu_group); @@ -285,6 +290,10 @@ int iommu_probe_device(struct device *dev) if (ret) goto err_module_put; + group = iommu_group_get(dev); + iommu_create_device_direct_mappings(group, dev); + iommu_group_put(group); + if (ops->probe_finalize) ops->probe_finalize(dev); @@ -736,8 +745,8 @@ int iommu_group_set_name(struct iommu_group *group, const char *name) } EXPORT_SYMBOL_GPL(iommu_group_set_name); -static int i...

From: Thierry Reding <treding at nvidia.com> The nouveau_fence_get_get_driver_name() function has a redundant _get in its name. Remove it. Signed-off-by: Thierry Reding <treding at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c

...>>> not less hacky but more common virtio work-arounds >>>> >>>> :) >>>> >>>> And then I can apply whatever comes from @arm.com and not >>>> worry about breaking actual hardware. >>> >>> What we could do is call iommu_group_get(&vdev->dev) for legacy >> >> Actually, that should be vdev->dev.parent - I'm now not sure quite what >> I managed to successfully test yesterday, but apparently it wasn't this >> patch :( >> >>> devices if CONFIG_ARM64. If that returns non-NU...

...ommu/omap: Remove orphan_dev tracking iommu/omap: Convert to probe/release_device() call-backs iommu/exynos: Use first SYSMMU in controllers list for IOMMU core iommu/exynos: Convert to probe/release_device() call-backs iommu: Remove add_device()/remove_device() code-paths iommu: Unexport iommu_group_get_for_dev() Sai Praneeth Prakhya (1): iommu: Add def_domain_type() callback in iommu_ops drivers/iommu/amd_iommu.c | 97 ++++---- drivers/iommu/amd_iommu_types.h | 1 - drivers/iommu/arm-smmu-v3.c | 38 +-- drivers/iommu/arm-smmu.c | 39 ++-- drivers/iommu/exynos-iommu.c...

...ommu/omap: Remove orphan_dev tracking iommu/omap: Convert to probe/release_device() call-backs iommu/exynos: Use first SYSMMU in controllers list for IOMMU core iommu/exynos: Convert to probe/release_device() call-backs iommu: Remove add_device()/remove_device() code-paths iommu: Unexport iommu_group_get_for_dev() Sai Praneeth Prakhya (1): iommu: Add def_domain_type() callback in iommu_ops drivers/iommu/amd_iommu.c | 97 ++++---- drivers/iommu/amd_iommu_types.h | 1 - drivers/iommu/arm-smmu-v3.c | 38 +-- drivers/iommu/arm-smmu.c | 39 ++-- drivers/iommu/exynos-iommu.c...

...is appropriate? Like this: > >> > >> bool implicit_iommu_for_dma_is_allowed(struct device *dev) > >> { > >> > >> const struct iommu_ops *ops = dev->bus->iommu_ops; > >> struct iommu_group *group; > >> > >> group = iommu_group_get(dev); > >> if (!group) > >> > >> return NULL; > >> > >> iommu_group_put(group); > >> > >> if (!ops->implicit_iommu_for_dma_is_allowed) > >> > >> return true; > >> > >> return ops-...