search for: iommu_dma

...>> config VIRTIO_IOMMU >>>>> bool "Virtio IOMMU driver" >>>>> depends on VIRTIO=y >>>>> - depends on ARM64 >>>>> + depends on (ARM64 || X86) >>>>> select IOMMU_API >>>>> + select IOMMU_DMA >>>> >>>> Can that have an "if X86" for clarity? AIUI it's not necessary for >>>> virtio-iommu itself (and really shouldn't be), but is merely to satisfy the >>>> x86 arch code's expectation that IOMMU drivers bring their own DMA...

...>> config VIRTIO_IOMMU >>>>> bool "Virtio IOMMU driver" >>>>> depends on VIRTIO=y >>>>> - depends on ARM64 >>>>> + depends on (ARM64 || X86) >>>>> select IOMMU_API >>>>> + select IOMMU_DMA >>>> >>>> Can that have an "if X86" for clarity? AIUI it's not necessary for >>>> virtio-iommu itself (and really shouldn't be), but is merely to satisfy the >>>> x86 arch code's expectation that IOMMU drivers bring their own DMA...

...8,8 +508,9 @@ config HYPERV_IOMMU > > > config VIRTIO_IOMMU > > > bool "Virtio IOMMU driver" > > > depends on VIRTIO=y > > > - depends on ARM64 > > > + depends on (ARM64 || X86) > > > select IOMMU_API > > > + select IOMMU_DMA > > > > Can that have an "if X86" for clarity? AIUI it's not necessary for > > virtio-iommu itself (and really shouldn't be), but is merely to satisfy the > > x86 arch code's expectation that IOMMU drivers bring their own DMA ops, > > right? >...

...8,8 +508,9 @@ config HYPERV_IOMMU > > > config VIRTIO_IOMMU > > > bool "Virtio IOMMU driver" > > > depends on VIRTIO=y > > > - depends on ARM64 > > > + depends on (ARM64 || X86) > > > select IOMMU_API > > > + select IOMMU_DMA > > > > Can that have an "if X86" for clarity? AIUI it's not necessary for > > virtio-iommu itself (and really shouldn't be), but is merely to satisfy the > > x86 arch code's expectation that IOMMU drivers bring their own DMA ops, > > right? >...

...- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -508,8 +508,9 @@ config HYPERV_IOMMU > config VIRTIO_IOMMU > bool "Virtio IOMMU driver" > depends on VIRTIO=y > - depends on ARM64 > + depends on (ARM64 || X86) > select IOMMU_API > + select IOMMU_DMA Can that have an "if X86" for clarity? AIUI it's not necessary for virtio-iommu itself (and really shouldn't be), but is merely to satisfy the x86 arch code's expectation that IOMMU drivers bring their own DMA ops, right? Robin. > select INTERVAL_TREE > help...

...- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -508,8 +508,9 @@ config HYPERV_IOMMU > config VIRTIO_IOMMU > bool "Virtio IOMMU driver" > depends on VIRTIO=y > - depends on ARM64 > + depends on (ARM64 || X86) > select IOMMU_API > + select IOMMU_DMA Can that have an "if X86" for clarity? AIUI it's not necessary for virtio-iommu itself (and really shouldn't be), but is merely to satisfy the x86 arch code's expectation that IOMMU drivers bring their own DMA ops, right? Robin. > select INTERVAL_TREE > help...

...gt; > > > config VIRTIO_IOMMU > > > > bool "Virtio IOMMU driver" > > > > depends on VIRTIO=y > > > > - depends on ARM64 > > > > + depends on (ARM64 || X86) > > > > select IOMMU_API > > > > + select IOMMU_DMA > > > > > > Can that have an "if X86" for clarity? AIUI it's not necessary for > > > virtio-iommu itself (and really shouldn't be), but is merely to satisfy the > > > x86 arch code's expectation that IOMMU drivers bring their own DMA ops, &...

...t; > bool "Virtio IOMMU driver" > > > > > > depends on VIRTIO=y > > > > > > - depends on ARM64 > > > > > > + depends on (ARM64 || X86) > > > > > > select IOMMU_API > > > > > > + select IOMMU_DMA > > > > > > > > > > Can that have an "if X86" for clarity? AIUI it's not necessary for > > > > > virtio-iommu itself (and really shouldn't be), but is merely to satisfy the > > > > > x86 arch code's expectation that...

...config index 068d4e0e3541..adcbda44d473 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -508,8 +508,9 @@ config HYPERV_IOMMU config VIRTIO_IOMMU bool "Virtio IOMMU driver" depends on VIRTIO=y - depends on ARM64 + depends on (ARM64 || X86) select IOMMU_API + select IOMMU_DMA select INTERVAL_TREE help Para-virtualised IOMMU driver with virtio. -- 2.25.0

...vers/iommu/Kconfig > > @@ -508,8 +508,9 @@ config HYPERV_IOMMU > > config VIRTIO_IOMMU > > bool "Virtio IOMMU driver" > > depends on VIRTIO=y > > - depends on ARM64 > > + depends on (ARM64 || X86) > > select IOMMU_API > > + select IOMMU_DMA > > Can that have an "if X86" for clarity? AIUI it's not necessary for > virtio-iommu itself (and really shouldn't be), but is merely to satisfy the > x86 arch code's expectation that IOMMU drivers bring their own DMA ops, > right? > > Robin. In fact do...

...ommu/Kconfig @@ -506,8 +506,8 @@ config HYPERV_IOMMU guests to run with x2APIC mode enabled. config VIRTIO_IOMMU - bool "Virtio IOMMU driver" - depends on VIRTIO=y + tristate "Virtio IOMMU driver" + depends on VIRTIO depends on (ARM64 || X86) select IOMMU_API select IOMMU_DMA diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c index f18ba8e22ebd..5429c12c879b 100644 --- a/drivers/iommu/virtio-iommu.c +++ b/drivers/iommu/virtio-iommu.c @@ -1084,7 +1084,6 @@ static int viommu_probe(struct virtio_device *vdev) #ifdef CONFIG_PCI if (pci_bus_type.io...

...ommu/Kconfig @@ -506,8 +506,8 @@ config HYPERV_IOMMU guests to run with x2APIC mode enabled. config VIRTIO_IOMMU - bool "Virtio IOMMU driver" - depends on VIRTIO=y + tristate "Virtio IOMMU driver" + depends on VIRTIO depends on (ARM64 || X86) select IOMMU_API select IOMMU_DMA diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c index f18ba8e22ebd..5429c12c879b 100644 --- a/drivers/iommu/virtio-iommu.c +++ b/drivers/iommu/virtio-iommu.c @@ -1084,7 +1084,6 @@ static int viommu_probe(struct virtio_device *vdev) #ifdef CONFIG_PCI if (pci_bus_type.io...

...ma-mapping.c @@ -1174,8 +1174,6 @@ static int __init dma_debug_do_init(void) } core_initcall(dma_debug_do_init); -#ifdef CONFIG_ARM_DMA_USE_IOMMU - static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs) { int prot = 0; @@ -2366,20 +2364,6 @@ static void arm_teardown_iommu_dma_ops(struct device *dev) arm_iommu_release_mapping(mapping); } -#else - -static bool arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64 size, - const struct iommu_ops *iommu) -{ - return false; -} - -static void arm_teardown_iommu_dma_ops(struct device *dev) { } - -#define arm...

Add topology description to the virtio-iommu driver and enable x86 platforms. Since the RFC [1] I've mostly given up on ACPI tables, since the internal discussions seem to have reached a dead end. The built-in topology description presented here isn't ideal, but it is simple to implement and doesn't impose a dependency on ACPI or device-tree, which can be beneficial to lightweight

From: Thierry Reding <treding at nvidia.com> Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V6: -add more details to the description of patch 001-iommu-amd-Remove-unnecessary-locking-from-AMD-iommu-.patch -rename handle_deferred_device to iommu_dma_deferred_attach -fix double tabs in 0003-iommu-dma-iommu-Handle-deferred-devices.patch V5: -Rebase on top of linux-next V4: -Rebase on top of linux-next -Split the removing of the unnecessary locking in the amd iommu driver into a seperate patch -refactor the "iommu/dma-iommu: Handle deferred...

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V4: -Rebase on top of linux-next -Split the removing of the unnecessary locking in the amd iommu driver into a seperate patch -refactor the "iommu/dma-iommu: Handle deferred devices" patch and address comments v3: -rename dma_limit to dma_mask -exit

Convert the AMD iommu driver to the dma-iommu api. Remove the iova handling and reserve region code from the AMD iommu driver. Change-log: V4: -Rebase on top of linux-next -Split the removing of the unnecessary locking in the amd iommu driver into a seperate patch -refactor the "iommu/dma-iommu: Handle deferred devices" patch and address comments v3: -rename dma_limit to dma_mask -exit

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will