lkml.org 
[lkml]   [2022]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH 0/2] Fix issues with untrusted devices and AMD IOMMU
Date
It's been observed that plugging in a TBT3 NVME device to a port marked
with ExternalFacingPort that some DMA transactions occur that are not a
full page and so the DMA API attempts to use software bounce buffers
instead of relying upon the IOMMU translation.

This doesn't work and leads to messaging like:

swiotlb buffer is full (sz: 4096 bytes), total 0 (slots), used 0 (slots)

The bounce buffers were originally set up, but torn down during
the boot process.
* This happens because as part of IOMMU initialization
`amd_iommu_init_dma_ops` gets called and resets the global swiotlb to 0.
* When late_init gets called `pci_swiotlb_late_init` `swiotlb_exit` is
called and the buffers are torn down.

This can be observed in the logs:
```
[ 0.407286] AMD-Vi: Extended features (0x246577efa2254afa): PPR NX GT [5] IA GA PC GA_vAPIC
[ 0.407291] AMD-Vi: Interrupt remapping enabled
[ 0.407292] AMD-Vi: Virtual APIC enabled
[ 0.407872] software IO TLB: tearing down default memory pool
```

This series adds some better messaging in case something like this comes
up again and also adds checks that swiotlb really is active before
trying to use it.

Mario Limonciello (2):
swiotlb: Check that slabs have been allocated when requested
iommu: Don't use swiotlb unless it's active

drivers/iommu/dma-iommu.c | 3 ++-
kernel/dma/swiotlb.c | 5 +++++
2 files changed, 7 insertions(+), 1 deletion(-)

--
2.34.1

\
 
 \ /
  Last update: 2022-04-05 00:31    [W:0.339 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site