Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge systems

2019-12-06 Thread Christian König
Am 04.12.19 um 17:08 schrieb Deucher, Alexander: -Original Message- From: Deucher, Alexander Sent: Monday, December 2, 2019 11:37 AM To: Lucas Stach ; Kai-Heng Feng ; j...@8bytes.org; Koenig, Christian (christian.koe...@amd.com) Cc: iommu@lists.linux-foundation.org; linux-ker...@vger.ker

Re: [PATCH 2/2] dma-mapping: force unencryped devices are always addressing limited

2019-12-06 Thread Thomas Hellstrom via iommu
Hi, Christoph. On Wed, 2019-12-04 at 14:03 +0100, Christoph Hellwig wrote: > Devices that are forced to DMA through swiotlb need to be treated as > if > they are addressing limited. > > Signed-off-by: Christoph Hellwig > --- > include/linux/dma-direct.h | 1 + > kernel/dma/direct.c| 8

[Patch v3 2/3] iommu: optimize iova_magazine_free_pfns()

2019-12-06 Thread Cong Wang
If the magazine is empty, iova_magazine_free_pfns() should be a nop, however it misses the case of mag->size==0. So we should just call iova_magazine_empty(). This should reduce the contention on iovad->iova_rbtree_lock a little bit, not much at all. Cc: Joerg Roedel Cc: John Garry Signed-off-b

[Patch v3 1/3] iommu: avoid unnecessary magazine allocations

2019-12-06 Thread Cong Wang
The IOVA cache algorithm implemented in IOMMU code does not exactly match the original algorithm described in the paper "Magazines and Vmem: Extending the Slab Allocator to Many CPUs and Arbitrary Resources". Particularly, it doesn't need to free the loaded empty magazine when trying to put it bac

[Patch v3 3/3] iommu: avoid taking iova_rbtree_lock twice

2019-12-06 Thread Cong Wang
Both find_iova() and __free_iova() take iova_rbtree_lock, there is no reason to take and release it twice inside free_iova(). Fold them into one critical section by calling the unlock versions instead. Cc: Joerg Roedel Cc: John Garry Signed-off-by: Cong Wang --- drivers/iommu/iova.c | 8 +

[Patch v3 0/3] iommu: reduce spinlock contention on fast path

2019-12-06 Thread Cong Wang
This patchset contains three small optimizations for the global spinlock contention in IOVA cache. Our memcache perf test shows this reduced its p999 latency down by 45% on AMD when IOMMU is enabled. Cong Wang (3): iommu: avoid unnecessary magazine allocations iommu: optimize iova_magazine_fre

Re: [Patch v3 0/3] iommu: reduce spinlock contention on fast path

2019-12-06 Thread Qian Cai
> On Dec 6, 2019, at 4:38 PM, Cong Wang wrote: > > This patchset contains three small optimizations for the global spinlock > contention in IOVA cache. Our memcache perf test shows this reduced its > p999 latency down by 45% on AMD when IOMMU is enabled. Can you at least have a changelog comp

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

2019-12-06 Thread Lu Baolu
Hi Jerry, On 12/6/19 3:24 PM, Jerry Snitselaar wrote: On Fri Dec 06 19, Lu Baolu wrote: [snip] Can you please try below change? Let's check whether the afending address has been mapped for device 01.00.2. $ git diff diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index db7bfd4f2d20

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

2019-12-06 Thread Jerry Snitselaar
On Sat Dec 07 19, Lu Baolu wrote: Hi Jerry, On 12/6/19 3:24 PM, Jerry Snitselaar wrote: On Fri Dec 06 19, Lu Baolu wrote: [snip] Can you please try below change? Let's check whether the afending address has been mapped for device 01.00.2. $ git diff diff --git a/drivers/iommu/iommu.c b/drive

Re: dmar pte read access not set error messages on hp dl388 gen8 systems

2019-12-06 Thread Jerry Snitselaar
On Fri Dec 06 19, Jerry Snitselaar wrote: On Sat Dec 07 19, Lu Baolu wrote: Hi Jerry, On 12/6/19 3:24 PM, Jerry Snitselaar wrote: On Fri Dec 06 19, Lu Baolu wrote: [snip] Can you please try below change? Let's check whether the afending address has been mapped for device 01.00.2. $ git diff