Re: [PATCH v4 05/22] iommu: introduce iommu invalidate API function

Hi Jacob, On Mon, Apr 16, 2018 at 10:48:54PM +0100, Jacob Pan wrote: [...] > +/** > + * enum iommu_inv_granularity - Generic invalidation granularity > + * > + * When an invalidation request is sent to IOMMU to flush translation caches, > + * it may carry different granularity. These granularity

Re: [PATCH 09/12] PCI: remove CONFIG_PCI_BUS_ADDR_T_64BIT

On Sun, Apr 15, 2018 at 04:59:44PM +0200, Christoph Hellwig wrote: > This symbol is now always identical to CONFIG_ARCH_DMA_ADDR_T_64BIT, so > remove it. > > Signed-off-by: Christoph Hellwig Acked-by: Bjorn Helgaas Please merge this along with the rest of the

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: [...] > > + /* Assign guest PASID table pointer and size order */ > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > > + (pasidt_binfo->pasid_bits - MIN_NR_PASID_BITS); > > Where does this IOMMU API interface

Re: [PATCH v4 09/22] iommu/vt-d: add svm/sva invalidate function

On Tue, 17 Apr 2018 13:10:45 -0600 Alex Williamson wrote: > On Mon, 16 Apr 2018 14:48:58 -0700 > Jacob Pan wrote: > > > When Shared Virtual Address (SVA) is enabled for a guest OS via > > vIOMMU, we need to provide invalidation support

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

On Fri, 20 Apr 2018 19:25:34 +0100 Jean-Philippe Brucker wrote: > On Tue, Apr 17, 2018 at 08:10:47PM +0100, Alex Williamson wrote: > [...] > > > + /* Assign guest PASID table pointer and size order */ > > > + ctx_lo = (pasidt_binfo->base_ptr & VTD_PAGE_MASK) | > >

Re: [PATCH v4 04/22] iommu/vt-d: add bind_pasid_table function

On Tue, 17 Apr 2018 13:10:47 -0600 Alex Williamson wrote: > On Mon, 16 Apr 2018 14:48:53 -0700 > Jacob Pan wrote: > > > Add Intel VT-d ops to the generic iommu_bind_pasid_table API > > functions. > > > > The primary use case is for

Re: [PATCH] iommu/amd: fix unused-variable warning

On 2018-04-20 11:28:36 [+0200], Tobias Regnery wrote: > The iommu_table_lock is only used by code inside an ifdef CONFIG_IRQ_REMAP > block. This leads to the following warning with CONFIG_IRQ_REMAP=n: > > amd_iommu.c:86:24: warning: 'iommu_table_lock' defined but not used > [-Wunused-variable] >

Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible

On Mon, Apr 16, 2018 at 05:18:19PM +0200, Takashi Iwai wrote: > As the recent swiotlb bug revealed, we seem to have given up the > direct DMA allocation too early and felt back to swiotlb allocation. > The reason is that swiotlb allocator expected that dma_direct_alloc() > would try harder to get

[PATCH] iommu/vt-d: fix shift-out-of-bounds in bug checking

From: Changbin Du It allows to flush more than 4GB of device TLBs. So the mask should be 64bit wide. UBSAN captured this fault as below. [3.760024] [3.768440] UBSAN: Undefined

[PATCH] iommu/amd: fix unused-variable warning

The iommu_table_lock is only used by code inside an ifdef CONFIG_IRQ_REMAP block. This leads to the following warning with CONFIG_IRQ_REMAP=n: amd_iommu.c:86:24: warning: 'iommu_table_lock' defined but not used [-Wunused-variable] Guard the spinlock definition with the same ifdef. Fixes:

Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible

On Fri, 20 Apr 2018 11:47:02 +0200, Christoph Hellwig wrote: > > On Mon, Apr 16, 2018 at 05:18:19PM +0200, Takashi Iwai wrote: > > As the recent swiotlb bug revealed, we seem to have given up the > > direct DMA allocation too early and felt back to swiotlb allocation. > > The reason is that

Re: [PATCH RFC] dma-direct: Try reallocation with GFP_DMA32 if possible

On Fri, Apr 20, 2018 at 11:58:58AM +0200, Takashi Iwai wrote: > It's because it's written on the tree with another fix patch I sent > beforehand ("[PATCH 1/2] dma-direct: Don't repeat allocation for no-op > GFP_DMA"). > > Could you check that one at first? I'm fine to rebase and resubmit > this