[RESEND PATCH v8 11/11] iommu: Remove iommu group changes notifier

The iommu group changes notifer is not referenced in the tree. Remove it to avoid dead code. Suggested-by: Christoph Hellwig Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe --- include/linux/iommu.h | 23 - drivers/iommu/iommu.c | 75

[RESEND PATCH v8 10/11] vfio: Remove iommu group notifier

The iommu core and driver core have been enhanced to avoid unsafe driver binding to a live group after iommu_group_set_dma_owner(PRIVATE_USER) has been called. There's no need to register iommu group notifier. This removes the iommu group notifer which contains BUG_ON() and WARN(). Signed-off-by:

[RESEND PATCH v8 09/11] vfio: Delete the unbound_list

From: Jason Gunthorpe commit 60720a0fc646 ("vfio: Add device tracking during unbind") added the unbound list to plug a problem with KVM where KVM_DEV_VFIO_GROUP_DEL relied on vfio_group_get_external_user() succeeding to return the vfio_group from a group file descriptor. The unbound list allowed

[RESEND PATCH v8 08/11] vfio: Remove use of vfio_group_viable()

As DMA ownership is claimed for the iommu group when a VFIO group is added to a VFIO container, the VFIO group viability is guaranteed as long as group->container_users > 0. Remove those unnecessary group viability checks which are only hit when group->container_users is not zero. The only

[RESEND PATCH v8 07/11] vfio: Set DMA ownership for VFIO devices

Claim group dma ownership when an IOMMU group is set to a container, and release the dma ownership once the iommu group is unset from the container. This change disallows some unsafe bridge drivers to bind to non-ACS bridges while devices under them are assigned to user space. This is an

[RESEND PATCH v8 03/11] amba: Stop sharing platform_dma_configure()

Stop sharing platform_dma_configure() helper as they are about to have their own bus dma_configure callbacks. Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe --- include/linux/platform_device.h | 2 -- drivers/amba/bus.c | 19 ++- drivers/base/platform.c

[RESEND PATCH v8 04/11] bus: platform, amba, fsl-mc, PCI: Add device DMA ownership management

The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers with the device DMA managed by kernel drivers or user-space applications. Unfortunately, multiple devices may be placed in the same IOMMU group because they cannot be isolated from each other. The DMA on these devices must

[RESEND PATCH v8 06/11] PCI: portdrv: Set driver_managed_dma

If a switch lacks ACS P2P Request Redirect, a device below the switch can bypass the IOMMU and DMA directly to other devices below the switch, so all the downstream devices must be in the same IOMMU group as the switch itself. The existing VFIO framework allows the portdrv driver to be bound to

[RESEND PATCH v8 05/11] PCI: pci_stub: Set driver_managed_dma

The current VFIO implementation allows pci-stub driver to be bound to a PCI device with other devices in the same IOMMU group being assigned to userspace. The pci-stub driver has no dependencies on DMA or the IOVA mapping of the device, but it does prevent the user from having direct access to the

[RESEND PATCH v8 02/11] driver core: Add dma_cleanup callback in bus_type

The bus_type structure defines dma_configure() callback for bus drivers to configure DMA on the devices. This adds the paired dma_cleanup() callback and calls it during driver unbinding so that bus drivers can do some cleanup work. One use case for this paired DMA callbacks is for the bus driver

[RESEND PATCH v8 00/11] Fix BUG_ON in vfio_iommu_group_notifier()

Hi Joerg, This is a resend version of v8 posted here: https://lore.kernel.org/linux-iommu/20220308054421.847385-1-baolu...@linux.intel.com/ as we discussed in this thread: https://lore.kernel.org/linux-iommu/yk%2fq1bgn8pc5h...@8bytes.org/ All patches can be applied perfectly except this one: -

[RESEND PATCH v8 01/11] iommu: Add DMA ownership management interfaces

Multiple devices may be placed in the same IOMMU group because they cannot be isolated from each other. These devices must either be entirely under kernel control or userspace control, never a mixture. This adds dma ownership management in iommu core and exposes several interfaces for the device

Re: [PATCH 03/25] dma-direct: take dma-ranges/offsets into account in resource mapping

Hello Robin. Sorry for the delayed answer. My comments are below. On Thu, Mar 24, 2022 at 11:30:38AM +, Robin Murphy wrote: > On 2022-03-24 01:48, Serge Semin wrote: > > A basic device-specific linear memory mapping was introduced back in > > commit ("dma: Take into account dma_pfn_offset")

Re: [PATCH RFC 07/12] iommufd: Data structure to provide IOVA to PFN mapping

On 2022/4/13 22:49, Yi Liu wrote: On 2022/4/13 22:36, Jason Gunthorpe wrote: On Wed, Apr 13, 2022 at 10:02:58PM +0800, Yi Liu wrote: +/** + * iopt_unmap_iova() - Remove a range of iova + * @iopt: io_pagetable to act on + * @iova: Starting iova to unmap + * @length: Number of bytes to unmap + *

[Patch v1] iommu: arm-smmu: disable large page mappings for Nvidia arm-smmu

Tegra194 and Tegra234 SoCs have the erratum that causes walk cache entries to not be invalidated correctly. The problem is that the walk cache index generated for IOVA is not same across translation and invalidation requests. This is leading to page faults when PMD entry is released during unmap