[PATCH 1/2] dma-mapping: add a dma_addressing_limited helper

This helper returns if the device has issues addressing all present memory in the system. Signed-off-by: Christoph Hellwig --- include/linux/dma-mapping.h | 14 ++ 1 file changed, 14 insertions(+) diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 8d13e28a8

[PATCH 2/2] dma-direct: only limit the mapping size if swiotlb could be used

Don't just check for a swiotlb buffer, but also if buffering might be required for this particular device. Fixes: 133d624b1cee ("dma: Introduce dma_max_mapping_size()") Reported-by: Benjamin Herrenschmidt Signed-off-by: Christoph Hellwig Tested-by: Benjamin Herrenschmidt --- kernel/dma/direct.

fix nvme performance regression due to dma_max_mapping_size()

Hi all, the new dma_max_mapping_size function is a little to eager to limit the I/O size if the swiotlb buffer is present, but the device is not addressing limited. Fix this by adding an additional check. ___ iommu mailing list iommu@lists.linux-foundat

x86-64 kernel dma issue; bisected

re: the dma-direct code commit below I have bisected the kernel to isolate a PCI board problem on my AMD x86-64 ASROCK system. The board worked at (Fedora kernel) 4.18.16 but stopped when moving to (Fedora kernel) 5.0. I then used (git/torvalds/linux) 4.20-rc4 or so to locate the fault via bis

Re: [PATCH 1/2] iommu/vt-d: Don't queue_iova() if there is no flush queue

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 13cf01744608 iommu/vt-d: Make use of iova deferred flushing. The bot has tested the following trees: v5.2.1, v5.1.18, v4.19.59, v4.14.133. v5.2.1: Build OK! v5.1.18: Build OK! v4.1

[PATCH 2/2] iommu/vt-d: Check if domain->pgd was allocated

There is a couple of places where on domain_init() failure domain_exit() is called. While currently domain_init() can fail only if alloc_pgtable_page() has failed. Make domain_exit() check if domain->pgd present, before calling domain_unmap(), as it theoretically should crash on clearing pte entri

[PATCH 1/2] iommu/vt-d: Don't queue_iova() if there is no flush queue

Intel VT-d driver was reworked to use common deferred flushing implementation. Previously there was one global per-cpu flush queue, afterwards - one per domain. Before deferring a flush, the queue should be allocated and initialized. Currently only domains with IOMMU_DOMAIN_DMA type initialize th

Re: [RFC v1 3/4] vfio/type1: VFIO_IOMMU_PASID_REQUEST(alloc/free)

Hi Yi, On 7/5/19 1:06 PM, Liu, Yi L wrote: > From: Liu Yi L > > This patch adds VFIO_IOMMU_PASID_REQUEST ioctl which aims > to passdown PASID allocation/free request from the virtual > iommu. This is required to get PASID managed in system-wide. > > Cc: Kevin Tian > Signed-off-by: Liu Yi L >

Re: [PATCH v4 20/22] iommu/vt-d: Add bind guest PASID support

Hi Eric Jacob is on sabbatical, so i'll give it my best shot :-) Yi/Kevin can jump in... On Tue, Jul 16, 2019 at 06:45:51PM +0200, Auger Eric wrote: > Hi Jacob, > > On 6/9/19 3:44 PM, Jacob Pan wrote: > > When supporting guest SVA with emulated IOMMU, the guest PASID > > table is shadowed in VM

Re: [PATCH v4 20/22] iommu/vt-d: Add bind guest PASID support

Hi Jacob, On 6/9/19 3:44 PM, Jacob Pan wrote: > When supporting guest SVA with emulated IOMMU, the guest PASID > table is shadowed in VMM. Updates to guest vIOMMU PASID table > will result in PASID cache flush which will be passed down to > the host as bind guest PASID calls. > > For the SL page

Re: [PATCH v4 11/22] iommu: Introduce guest PASID bind function

Hi Jacob, On 6/9/19 3:44 PM, Jacob Pan wrote: > Guest shared virtual address (SVA) may require host to shadow guest > PASID tables. Guest PASID can also be allocated from the host via > enlightened interfaces. In this case, guest needs to bind the guest > mm, i.e. cr3 in guest physical address to

Re: cma_remap when using dma_alloc_attr :- DMA_ATTR_NO_KERNEL_MAPPING

On Tue, Jul 16, 2019 at 01:02:19PM +0100, Robin Murphy wrote: >> Lets say 4k video allocation required 300MB cma memory but not required >> virtual mapping for all the 300MB, its require only 20MB virtually mapped >> at some specific use case/point of video, and unmap virtual mapping after >> uses,

Re: cma_remap when using dma_alloc_attr :- DMA_ATTR_NO_KERNEL_MAPPING

On 12/07/2019 19:30, Pankaj Suryawanshi wrote: Hello, When we allocate cma memory using dma_alloc_attr using DMA_ATTR_NO_KERNEL_MAPPING attribute. It will return physical address without virtual mapping and thats the use case of this attribute. but lets say some vpu/gpu drivers required virtual

Re: [PATCH v4 17/22] iommu/vt-d: Avoid duplicated code for PASID setup

Hi Jacob, On 6/9/19 3:44 PM, Jacob Pan wrote: > After each setup for PASID entry, related translation caches must be flushed. > We can combine duplicated code into one function which is less error prone. > > Signed-off-by: Jacob Pan > --- > drivers/iommu/intel-pasid.c | 48 > +-

Re: [PATCH v4 16/22] iommu/vt-d: Move domain helper to header

Hi Jacob, On 6/9/19 3:44 PM, Jacob Pan wrote: > Move domainer helper to header to be used by SVA code. > > Signed-off-by: Jacob Pan > --- > drivers/iommu/intel-iommu.c | 6 -- > include/linux/intel-iommu.h | 6 ++ > 2 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drive

Re: [PATCH v4 14/22] iommu/vt-d: Add custom allocator for IOASID

Hi Jacob, On 6/9/19 3:44 PM, Jacob Pan wrote: > When VT-d driver runs in the guest, PASID allocation must be > performed via virtual command interface. This patch registers a > custom IOASID allocator which takes precedence over the default > XArray based allocator. The resulting IOASID allocation

Re: [PATCH v4 13/22] iommu/vt-d: Enlightened PASID allocation

Hi Jacob, On 6/9/19 3:44 PM, Jacob Pan wrote: > From: Lu Baolu > > If Intel IOMMU runs in caching mode, a.k.a. virtual IOMMU, the > IOMMU driver should rely on the emulation software to allocate > and free PASID IDs. The Intel vt-d spec revision 3.0 defines a > register set to support this. This