On Sat, Oct 2, 2021 at 1:36 AM Jason Gunthorpe <j...@nvidia.com> wrote: > > On Sat, Oct 02, 2021 at 01:24:54AM +1300, Barry Song wrote: > > > I assume KVA mode can avoid this iotlb flush as the device is using > > the page table of the kernel and sharing the whole kernel space. But > > will users be glad to accept this mode? > > You can avoid the lock be identity mapping the physical address space > of the kernel and maping map/unmap a NOP. > > KVA is just a different way to achive this identity map with slightly > different security properties than the normal way, but it doesn't > reach to the same security level as proper map/unmap. > > I'm not sure anyone who cares about DMA security would see value in > the slight difference between KVA and a normal identity map.
yes. This is an important question. if users want a high security level, kva might not their choice; if users don't want the security, they are using iommu passthrough. So when will users choose KVA? > > > which have been mapped in the current dma-map/unmap with IOMMU backend. > > some drivers are using bouncing buffer to overcome the performance loss of > > dma_map/unmap as copying is faster than unmapping: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=907676b130711fd1f > > It is pretty unforuntate that drivers are hard coding behaviors based > on assumptions of what the portable API is doing under the covers. not real when it has a tx_copybreak which can be set by ethtool or similar userspace tools . if users are using iommu passthrough, copying won't happen by the default tx_copybreak. if users are using restrict iommu mode, socket buffers are copied into the buffers allocated and mapped in the driver. so this won't require mapping and unmapping socket buffers frequently. > > Jason Thanks barry _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
