Messages in this thread | | | From | Mario Limonciello <> | Subject | [PATCH 0/2] Fix issues with untrusted devices and AMD IOMMU | Date | Mon, 4 Apr 2022 11:47:05 -0500 |
| |
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
| |