based on the AMD IOMMU patch now applied, plus v2 of my
device_iommu_capable() series here:
https://lore.kernel.org/linux-iommu/cover.1650878781.git.robin.mur...@arm.com/
Cheers,
Robin.
Robin Murphy (14):
iommu/vt-d: Temporarily reject probing non-PCI devices
iommu: Always register bus
On 2022-04-28 02:04, Samuel Holland wrote:
So far, the driver has relied on arch/arm64/Kconfig to select IOMMU_DMA.
Unsurprisingly, this does not work on RISC-V, so the driver must select
IOMMU_DMA itself.
No, IOMMU_DMA should only be selected by the architecture code that's
also responsible f
On 2022-04-28 07:56, Krzysztof Kozlowski wrote:
On 27/04/2022 13:25, Andre Przywara wrote:
The Page Request Interface (PRI) is an optional PCIe feature. As such, a
SMMU would not need to handle it if the PCIe host bridge or the SMMU
itself do not implement it. Also an SMMU could be connected to
therwise AFAICS the last
item should stay as "- const: cmdq-sync" to preserve the existing
canonical order for the 4-item case.
Otherwise,
Reviewed-by: Robin Murphy
Cheers,
Robin.
'#iommu-cells':
const: 1
___
iommu m
On 2022-04-26 01:06, Rajat Jain via iommu wrote:
The "DmaProperty" is supported and currently documented and used by
Microsoft [link 1 below], to flag internal PCIe root ports that need
DMA protection [link 2 below]. We have discussed with them and reached
a common understanding that they shall c
er that implies that firmware is playing
the game overall, so we'll use that to assume that all Thunderbolt ports
should be correctly marked and thus will end up fully protected.
CC: Mario Limonciello
Reviewed-by: Christoph Hellwig
Acked-by: Mika Westerberg
Signed-off-by: Robin Murphy
---
-by: Christoph Hellwig
Signed-off-by: Mario Limonciello
Signed-off-by: Robin Murphy
---
v4: No change
drivers/iommu/amd/amd_iommu_types.h | 4
drivers/iommu/amd/init.c| 3 +++
drivers/iommu/amd/iommu.c | 2 ++
3 files changed, 9 insertions(+)
diff --git a/drivers
protection
Suggested-by: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Reviewed-by: Lu Baolu
Signed-off-by: Robin Murphy
---
v4: No change
drivers/iommu/intel/iommu.c | 2 ++
include/linux/iommu.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/iommu/intel/iommu.c
external users have been converted and we can reliably pass
the device pointer through the internal driver interface too.
Signed-off-by: Robin Murphy
---
v4: Hold off changing the internal callback interface for now
drivers/iommu/iommu.c | 23 +++
include/linux/iommu.h | 6
DMA remap support is enabled
Robin Murphy (3):
iommu: Introduce device_iommu_capable()
iommu: Add capability for pre-boot DMA protection
thunderbolt: Make iommu_dma_protection more accurate
drivers/iommu/amd/amd_iommu_types.h | 4 +++
drivers/iommu/amd/init.c| 3 ++
drivers
On 2022-04-25 09:24, Miles Chen via iommu wrote:
When larbdev is NULL (in the case I hit, the node is incorrectly set
iommus = <&iommu NUM>), it will cause device_link_add() fail and
kernel crashes when we try to print dev_name(larbdev).
Fix it by adding a NULL pointer check before
device_link_a
On 2022-04-23 09:01, Lu Baolu wrote:
Hi Robin,
On 2022/4/19 15:20, Robin Murphy wrote:
On 2022-04-19 00:37, Lu Baolu wrote:
On 2022/4/19 6:09, Robin Murphy wrote:
On 2022-04-16 01:04, Lu Baolu wrote:
On 2022/4/14 20:42, Robin Murphy wrote:
@@ -1883,27 +1900,12 @@ static int iommu_bus_init
On 2022-04-22 21:06, Alex Deucher wrote:
Add preliminary documentation for AMD IOMMU and combine
with the existing Intel IOMMU documentation and clean
up and modernize some of the existing documentation to
align with the current state of the kernel.
FWIW,
Reviewed-by: Robin Murphy
Signed
On 2022-04-22 18:54, Alex Deucher wrote:
[...]
+Intel Specific Notes
+
+
+Graphics Problems?
+^^
+
+If you encounter issues with graphics devices, you can try adding
+option intel_iommu=igfx_off to turn off the integrated graphics engine.
+If this fixes anythin
On 2022-04-22 19:37, Krishna Reddy wrote:
Good effort to isolate bus config from smmu drivers.
Reviewed-By: Krishna Reddy
Thanks!
I have an orthogonal question here.
Can the following code handle the case, where different buses have different
type of SMMU instances(like one bus has SMMUv2 a
The ->probe_finalize hook only runs after ->probe_device succeeds,
so we can move that over to the new dev_iommu_ops() as well.
Signed-off-by: Robin Murphy
---
Another cheeky little one which doesn't need to wait...
drivers/iommu/iommu.c | 3 ++-
1 file changed, 2 insertions(+),
On 2022-04-21 18:35, Serge Semin wrote:
On Thu, Apr 21, 2022 at 04:45:36PM +0200, Christoph Hellwig wrote:
On Wed, Apr 20, 2022 at 11:55:38AM +0300, Serge Semin wrote:
On Wed, Apr 20, 2022 at 10:47:46AM +0200, Christoph Hellwig wrote:
I can't really comment on the dma-ranges exlcusion for P2P
On 2022-04-21 18:12, Jean-Philippe Brucker wrote:
On Thu, Apr 14, 2022 at 01:42:41PM +0100, Robin Murphy wrote:
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the probe failure path accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/virtio-iommu.c
On 2022-04-21 15:43, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Steven Price [mailto:steven.pr...@arm.com]
Sent: 21 April 2022 13:59
To: Shameerali Kolothum Thodi ;
linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
iommu@lists.linux-foundation.org
Cc: Lin
On 2022-04-21 15:13, Christoph Hellwig wrote:
On Thu, Apr 21, 2022 at 12:36:56PM +0100, Robin Murphy wrote:
Hi all,
Thanks to Christoph's latest series, I'm reminded that, if we're going
to give the ARM DMA ops some cleanup this cycle, it's as good a time as
any to dust o
Tegra234 devices. This is recommended fix from Tegra hardware design
team.
Acked-by: Robin Murphy
Co-developed-by: Pritesh Raithatha
Signed-off-by: Pritesh Raithatha
Signed-off-by: Ashish Mhetre
---
Changes in v2:
- Using init_context() to override pgsize_bitmap instead of new function
Merge the coherent and non-coherent callbacks down to a single
implementation each, relying on the generic dev->dma_coherent
flag at the points where the difference matters.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c | 240 +-
1 file chan
When an IOMMU is present, we trust that it should be capable
of remapping any physical memory, and since the device masks
represent the input (virtual) addresses to the IOMMU it makes
no sense to validate them against physical PFNs anyway.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma
The dma_sync_* operations are now the only difference between the
coherent and non-coherent IOMMU ops. Some minor tweaks to make those
safe for coherent devices with minimal overhead, and we can condense
down to a single set of DMA ops.
Signed-off-by: Robin Murphy
---
arch/arm/mm/dma-mapping.c
ssume matches the
patches posted at [1].
Cheers,
Robin.
[1]
https://lore.kernel.org/linux-arm-kernel/20220421074204.1284072-1-...@lst.de/
Robin Murphy (3):
ARM/dma-mapping: Drop .dma_supported for IOMMU ops
ARM/dma-mapping: Consolidate IOMMU ops callbacks
ARM/dma-mapping: Merge IOMMU ops
On 2022-04-19 15:40, Will Deacon wrote:
On Thu, Apr 14, 2022 at 01:42:33PM +0100, Robin Murphy wrote:
Stop calling bus_set_iommu() since it's now unnecessary. With device
probes now replayed for every IOMMU instance registration, the whole
sorry ordering workaround for legacy DT bindings
On 2022-04-19 22:08, Dmitry Baryshkov wrote:
On 20/04/2022 00:04, Robin Murphy wrote:
On 2022-04-19 14:04, Dmitry Baryshkov wrote:
This reverts commit e2a88eabb02410267519b838fb9b79f5206769be. The commit
in question makes msm_use_mmu() check whether the DRM 'component master'
On 2022-04-19 22:08, Dmitry Baryshkov wrote:
On 20/04/2022 00:04, Robin Murphy wrote:
On 2022-04-19 14:04, Dmitry Baryshkov wrote:
This reverts commit e2a88eabb02410267519b838fb9b79f5206769be. The commit
in question makes msm_use_mmu() check whether the DRM 'component master'
match resulted in an incorrect calculation for size so it
failed to be page-size aligned. Further, it caused a dead loop at
"while (iova < end)" check in __arm_smmu_tlb_inv_range function.
This patch fixes the issue by doing the calculation correctly.
Reviewed-by: Robin Murphy
Fixes:
On 2022-04-19 14:04, Dmitry Baryshkov wrote:
This reverts commit e2a88eabb02410267519b838fb9b79f5206769be. The commit
in question makes msm_use_mmu() check whether the DRM 'component master'
device is translated by the IOMMU. At this moment it is the 'mdss'
device.
However on platforms using the
On 2022-04-19 14:04, Dmitry Baryshkov wrote:
This reverts commit e2a88eabb02410267519b838fb9b79f5206769be. The commit
in question makes msm_use_mmu() check whether the DRM 'component master'
device is translated by the IOMMU. At this moment it is the 'mdss'
device.
However on platforms using the
On 2022-04-17 10:04, Ashish Mhetre wrote:
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 fault
On 2022-04-19 21:05, Nicolin Chen wrote:
On Tue, Apr 19, 2022 at 05:02:33PM -0300, Jason Gunthorpe wrote:
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index d816759a6bcf..e280568bb513 100644
+++ b/drivers/iommu/arm/arm-smmu-v3/a
On 2022-04-19 00:37, Lu Baolu wrote:
On 2022/4/19 6:09, Robin Murphy wrote:
On 2022-04-16 01:04, Lu Baolu wrote:
On 2022/4/14 20:42, Robin Murphy wrote:
@@ -1883,27 +1900,12 @@ static int iommu_bus_init(struct bus_type *bus)
*/
int bus_set_iommu(struct bus_type *bus, const struct
On 2022-04-16 01:04, Lu Baolu wrote:
On 2022/4/14 20:42, Robin Murphy wrote:
@@ -1883,27 +1900,12 @@ static int iommu_bus_init(struct bus_type *bus)
*/
int bus_set_iommu(struct bus_type *bus, const struct iommu_ops *ops)
{
- int err;
-
- if (ops == NULL) {
- bus->iommu_
Clean up the remaining trivial bus_set_iommu() callsites along
with the implementation. Now drivers only have to know and care
about iommu_device instances, phew!
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 4
drivers/iommu/fsl_pamu_domain.c | 4
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the probe failure path accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/virtio-iommu.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/v
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the probe failure path accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-smmu.c | 29 ++---
1 file changed, 6 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/tegra-smm
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the init failure path accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/omap-iommu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index d9cf282
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the probe failure paths accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/mtk_iommu.c| 13 +
drivers/iommu/mtk_iommu_v1.c | 13 +
2 files changed, 2 insertions(+), 24 deletions(-)
Stop calling bus_set_iommu() since it's now unnecessary. This also
leaves the custom initcall effectively doing nothing but register
the driver, which no longer needs to happen early either, so convert
it to builtin_platform_driver().
Signed-off-by: Robin Murphy
---
drivers/iommu/ipmmu-v
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the init failure path accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/exynos-iommu.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the probe failure path accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/apple-dart.c | 30 +-
1 file changed, 1 insertion(+), 29 deletions(-)
diff --git a/drivers/iommu/apple-dar
Stop calling bus_set_iommu() since it's now unnecessary, and simplify
the probe failure path accordingly.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 53 +
1 file changed, 2 insertions(+), 51 deletions(-)
diff --git a/drivers/iommu/ar
Stop calling bus_set_iommu() since it's now unnecessary, and
garbage-collect the last remnants of amd_iommu_init_api().
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/amd_iommu.h | 1 -
drivers/iommu/amd/init.c | 9 +
drivers/iommu/amd/iommu.c | 21 ---
Stop calling bus_set_iommu() since it's now unnecessary. With device
probes now replayed for every IOMMU instance registration, the whole
sorry ordering workaround for legacy DT bindings goes too, hooray!
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu/arm-smmu.c
merely preserving the well-established existing
behaviour. This could be improved in future - probably combined with
equivalent cleanup for iommu_device_unregister() - but that isn't a
priority right now.
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c
not break the notifier call chain, so there should be no
harm in proactively registering all our bus notifiers at init time.
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 49 ---
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/driv
etty much good to go now (I'll send a slightly-tweaked
final version once the iommu/core branch is open).
Thanks,
Robin.
Robin Murphy (13):
iommu: Always register bus notifiers
iommu: Move bus setup to IOMMU device registration
iommu/amd: Clean up bus_set_iommu()
iommu/arm-smmu: Clean u
On 2022-04-13 21:19, Nicolin Chen wrote:
Hi Robin,
On Wed, Apr 13, 2022 at 02:40:31PM +0100, Robin Murphy wrote:
On 2022-04-13 05:17, Nicolin Chen wrote:
To calculate num_pages, the size should be aligned with
"page size", determined by the tg value. Otherwise, its
following &q
On 2022-04-13 05:17, Nicolin Chen wrote:
To calculate num_pages, the size should be aligned with
"page size", determined by the tg value. Otherwise, its
following "while (iova < end)" might become an infinite
loop if unaligned size is slightly greater than 1 << tg.
Hmm, how does a non-page-alig
On 2022-04-13 05:59, Christoph Hellwig wrote:
On Wed, Apr 13, 2022 at 09:02:02AM +0800, Chao Gao wrote:
dma_direct_sync_single_for_cpu() also calls arch_sync_dma_for_cpu_all()
and arch_dma_mark_clean() in some cases. if SWIOTLB does sync internally,
should these two functions be called by SWIOTL
On 12/04/2022 12:38 pm, Chao Gao wrote:
When we looked into FIO performance with swiotlb enabled in VM, we found
swiotlb_bounce() is always called one more time than expected for each DMA
read request.
It turns out that the bounce buffer is copied to original DMA buffer twice
after the completio
Even though the IOVA API never actually needed it, iova.h is still
carrying an include of dma-mapping.h, now solely for the sake of not
breaking tegra-drm. Fix that properly.
Signed-off-by: Robin Murphy
---
v2: Apparently nvdec.c needs one now too.
drivers/gpu/drm/tegra/dc.c| 1 +
drivers
Even though the IOVA API never actually needed it, iova.h is still
carrying an include of dma-mapping.h, now solely for the sake of not
breaking tegra-drm. Fix that properly.
Signed-off-by: Robin Murphy
---
v2: Apparently nvdec.c needs one now too.
drivers/gpu/drm/tegra/dc.c| 1 +
drivers
ce or not.
Signed-off-by: Robin Murphy
---
v2: Fix logic for older SoCs and clarify.
drivers/gpu/drm/tegra/drm.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 9464f522e257..4f2bdab
ce or not.
Signed-off-by: Robin Murphy
---
v2: Fix logic for older SoCs and clarify.
drivers/gpu/drm/tegra/drm.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 9464f522e257..4f2bdab
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device
we care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
v2: Rebase on habanalabs-next
drivers
On 2022-04-10 11:59, Oded Gabbay wrote:
On Tue, Apr 5, 2022 at 4:46 PM Robin Murphy wrote:
Even if an IOMMU might be present for some PCI segment in the system,
that doesn't necessarily mean it provides translation for the device
we care about. Replace iommu_present() with a more approp
On 2022-04-07 18:51, Dmitry Osipenko wrote:
On 4/6/22 21:06, Robin Murphy wrote:
On 2022-04-06 15:32, Dmitry Osipenko wrote:
On 4/5/22 17:19, Robin Murphy wrote:
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device
On 2022-04-07 18:51, Dmitry Osipenko wrote:
On 4/6/22 21:06, Robin Murphy wrote:
On 2022-04-06 15:32, Dmitry Osipenko wrote:
On 4/5/22 17:19, Robin Murphy wrote:
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device
On 2022-04-08 14:35, Jason Gunthorpe wrote:
On Fri, Apr 08, 2022 at 02:11:10PM +0100, Robin Murphy wrote:
However, this creates an oddball situation where the vfio_device and
it's struct device could become unplugged from the system while the
domain that the struct device spawned continu
On 2022-04-08 13:22, Jason Gunthorpe wrote:
On Fri, Apr 08, 2022 at 08:26:10AM +, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Thursday, April 7, 2022 11:24 PM
IOMMU_CACHE means that normal DMAs do not require any additional
coherency
mechanism and is the basic uAPI that VFIO exposes to
On 2022-04-08 13:18, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 08:27:05PM +0100, Robin Murphy wrote:
On 2022-04-07 20:08, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
On 2022-04-07 18:43, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 06:03:37PM
On 2022-04-08 10:08, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Friday, April 8, 2022 3:08 AM
On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
On 2022-04-07 18:43, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
At a glance, this all
On 2022-04-07 20:08, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 07:02:03PM +0100, Robin Murphy wrote:
On 2022-04-07 18:43, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
At a glance, this all looks about the right shape to me now, thanks!
Thanks
On 2022-04-07 18:43, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 06:03:37PM +0100, Robin Murphy wrote:
At a glance, this all looks about the right shape to me now, thanks!
Thanks!
Ideally I'd hope patch #4 could go straight to device_iommu_capable() from
my Thunderbolt series, but w
his
one too.
For the series,
Acked-by: Robin Murphy
v1:
https://lore.kernel.org/r/0-v1-ef02c60ddb76+12ca2-intel_no_snoop_...@nvidia.com
Jason Gunthorpe (4):
iommu: Introduce the domain op enforce_cache_coherency()
vfio: Move the Intel no-snoop control off of IOMMU_CACHE
iommu: Red
On 2022-04-07 14:59, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 07:18:48AM +, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Thursday, April 7, 2022 1:17 AM
On Wed, Apr 06, 2022 at 06:10:31PM +0200, Christoph Hellwig wrote:
On Wed, Apr 06, 2022 at 01:06:23PM -0300, Jason Gunthorpe wro
On 2022-04-07 14:59, Jason Gunthorpe wrote:
On Thu, Apr 07, 2022 at 07:18:48AM +, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Thursday, April 7, 2022 1:17 AM
On Wed, Apr 06, 2022 at 06:10:31PM +0200, Christoph Hellwig wrote:
On Wed, Apr 06, 2022 at 01:06:23PM -0300, Jason Gunthorpe wro
On 2022-04-07 14:28, Christoph Hellwig wrote:
+static void iort_rmr_desc_check_overlap(struct acpi_iort_rmr_desc *desc, u32
count)
Overly long line.
void iommu_dma_put_resv_regions(struct device *dev, struct list_head *list)
{
+ if (!is_of_node(dev_iommu_fwspec_get(dev)->iommu_fwno
er changes
a 32-bit device's default domain type to passthrough via sysfs, such
that it starts needing regular dma-direct bouncing.
Reviewed-by: Robin Murphy
Fixes: 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers")
Suggested-by: Christoph Hellwig
Signed-of
been allocated this is a
problem that should be made apparent to the user.
Reviewed-by: Robin Murphy
Signed-off-by: Mario Limonciello
---
v1->v2:
* Move error message into the caller
drivers/iommu/dma-iommu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/dma
On 2022-04-07 07:26, Christoph Hellwig wrote:
All drivers that implement get_resv_regions just use
generic_put_resv_regions to implement the put side. Remove the
indirections and document the allocations constraints.
Unfortunately we need to keep this one for now, as the belated IORT RMR
supp
[1]
https://lore.kernel.org/linux-iommu/f707b4248e1d33b6d2c7f1d7c94febb802cf9890.1649161199.git.robin.mur...@arm.com/
url:
https://github.com/intel-lab-lkp/linux/commits/Robin-Murphy/RDMA-usnic-Refactor-usnic_uiom_alloc_pd/20220406-133657
base: https://git.kernel.org/pub/scm/linux/kerne
On 2022-04-06 15:32, Dmitry Osipenko wrote:
On 4/5/22 17:19, Robin Murphy wrote:
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device, which at the moment
means the iommu_present() test could never fail.
Signed-off-by
On 2022-04-06 15:32, Dmitry Osipenko wrote:
On 4/5/22 17:19, Robin Murphy wrote:
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device, which at the moment
means the iommu_present() test could never fail.
Signed-off-by
On 2022-04-06 15:14, Jason Gunthorpe wrote:
On Wed, Apr 06, 2022 at 03:51:50PM +0200, Christoph Hellwig wrote:
On Wed, Apr 06, 2022 at 09:07:30AM -0300, Jason Gunthorpe wrote:
Didn't see it
I'll move dev_is_dma_coherent to device.h along with
device_iommu_mapped() and others then
No. It it
On 2022-04-06 15:14, Jason Gunthorpe wrote:
On Wed, Apr 06, 2022 at 03:51:50PM +0200, Christoph Hellwig wrote:
On Wed, Apr 06, 2022 at 09:07:30AM -0300, Jason Gunthorpe wrote:
Didn't see it
I'll move dev_is_dma_coherent to device.h along with
device_iommu_mapped() and others then
No. It it
On 2022-04-05 17:16, Jason Gunthorpe wrote:
vdpa and usnic are trying to test if IOMMU_CACHE is supported. The correct
way to do this is via dev_is_dma_coherent()
Not necessarily...
Disregarding the complete disaster of PCIe No Snoop on Arm-Based
systems, there's the more interesting effectiv
On 2022-04-05 17:16, Jason Gunthorpe wrote:
vdpa and usnic are trying to test if IOMMU_CACHE is supported. The correct
way to do this is via dev_is_dma_coherent()
Not necessarily...
Disregarding the complete disaster of PCIe No Snoop on Arm-Based
systems, there's the more interesting effectiv
On 2022-04-06 14:06, Jason Gunthorpe wrote:
On Wed, Apr 06, 2022 at 01:32:07PM +0100, Robin Murphy wrote:
a particular IOMMU instance, and potentially allocate separate domains for
separate devices to represent the same address space, much like
vfio_iommu_type1_attach_group() does.
I think
On 2022-04-06 06:58, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Wednesday, April 6, 2022 9:24 AM
On Wed, Apr 06, 2022 at 01:00:13AM +, Tian, Kevin wrote:
Because domains wrap more than just the IOPTE format, they have
additional data related to the IOMMU HW block itself. Imagine a SOC
ed-by: Robin Murphy
Signed-off-by: Sascha Hauer
---
Notes:
Changes since v8:
- new patch
drivers/clk/rockchip/clk-rk3568.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/rockchip/clk-rk3568.c
b/drivers/clk/rockchip/clk-rk3568.c
index 63dfbeeeb06d9..62694d95173ab 1
On 2022-04-06 06:28, Christoph Hellwig wrote:
On Tue, Apr 05, 2022 at 11:41:01AM +0100, Robin Murphy wrote:
iommu_capable() only really works for systems where all IOMMU instances
are completely homogeneous, and all devices are IOMMU-mapped. Implement
the new variant which can give an accurate
Rather than hard-coding pci_bus_type, pass the PF device through to
usnic_uiom_alloc_pd() and retrieve its bus there. This prepares for
iommu_domain_alloc() changing to take a device rather than a bus_type.
Signed-off-by: Robin Murphy
---
drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 3
somewhat of a logical cleanup, the main motivation is
to prepare for a change in the iommu_domain_alloc() interface.
Signed-off-by: Robin Murphy
---
Lightly tested on RK3288. This does stand to collide with the in-flight
VOP2 driver a little, if only that that will want an equivalent
somewhat of a logical cleanup, the main motivation is
to prepare for a change in the iommu_domain_alloc() interface.
Signed-off-by: Robin Murphy
---
Lightly tested on RK3288. This does stand to collide with the in-flight
VOP2 driver a little, if only that that will want an equivalent
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/nouveau/nvkm/engine/device/te
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/nouveau/nvkm/engine/device/te
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/nouveau/nvkm/engine/device/te
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device, which at the moment
means the iommu_present() test could never fail.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion
Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device, which at the moment
means the iommu_present() test could never fail.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
1
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
1
Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
1
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4
1 file changed, 4 deletions
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4
1 file changed, 4 deletions
iommu_get_domain_for_dev() is already perfectly happy to return NULL
if the given device has no IOMMU. Drop the unnecessary check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/arm/malidp_planes.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu
iommu_get_domain_for_dev() is already perfectly happy to return NULL
if the given device has no IOMMU. Drop the unnecessary check.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/arm/malidp_planes.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu
401 - 500 of 4063 matches
Mail list logo
