Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size

On Thu, Jan 24, 2019 at 10:51:51AM +0100, Joerg Roedel wrote: > On Thu, Jan 24, 2019 at 09:42:21AM +0100, Christoph Hellwig wrote: > > Yes. But more importantly it would fix the limit for all other block > > drivers that set large segment sizes when running over swiotlb. > > True, so it would be

[PATCH AUTOSEL 4.19 129/258] iommu/arm-smmu: Add support for qcom, smmu-v2 variant

From: Vivek Gautam [ Upstream commit 89cddc563743cb1e0068867ac97013b2a5bf86aa ] qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. On msm8996, multiple cores, viz. mdss, video, etc. use this smmu. On sdm845, this smmu is used with gpu. Add bindings for the

[PATCH AUTOSEL 4.19 118/258] iommu/amd: Fix amd_iommu=force_isolation

From: Yu Zhao [ Upstream commit c12b08ebbe16f0d3a96a116d86709b04c1ee8e74 ] The parameter is still there but it's ignored. We need to check its value before deciding to go into passthrough mode for AMD IOMMU v2 capable device. We occasionally use this parameter to force v2 capable device into

[PATCH AUTOSEL 4.19 128/258] iommu/arm-smmu-v3: Avoid memory corruption from Hisilicon MSI payloads

From: Zhen Lei [ Upstream commit 84a9a75774961612d0c7dd34a1777e8f98a65abd ] The GITS_TRANSLATER MMIO doorbell register in the ITS hardware is architected to be 4 bytes in size, yet on hi1620 and earlier, Hisilicon have allocated the adjacent 4 bytes to carry some IMPDEF sideband information

[PATCH AUTOSEL 4.19 130/258] iommu/arm-smmu-v3: Use explicit mb() when moving cons pointer

From: Will Deacon [ Upstream commit a868e8530441286342f90c1fd9c5f24de3aa2880 ] After removing an entry from a queue (e.g. reading an event in arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer pointer to free the queue slot back to the SMMU. A memory barrier is required here

[PATCH AUTOSEL 4.14 075/170] iommu/amd: Fix amd_iommu=force_isolation

From: Yu Zhao [ Upstream commit c12b08ebbe16f0d3a96a116d86709b04c1ee8e74 ] The parameter is still there but it's ignored. We need to check its value before deciding to go into passthrough mode for AMD IOMMU v2 capable device. We occasionally use this parameter to force v2 capable device into

[PATCH AUTOSEL 4.14 084/170] iommu/arm-smmu: Add support for qcom, smmu-v2 variant

From: Vivek Gautam [ Upstream commit 89cddc563743cb1e0068867ac97013b2a5bf86aa ] qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. On msm8996, multiple cores, viz. mdss, video, etc. use this smmu. On sdm845, this smmu is used with gpu. Add bindings for the

[PATCH AUTOSEL 4.14 085/170] iommu/arm-smmu-v3: Use explicit mb() when moving cons pointer

From: Will Deacon [ Upstream commit a868e8530441286342f90c1fd9c5f24de3aa2880 ] After removing an entry from a queue (e.g. reading an event in arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer pointer to free the queue slot back to the SMMU. A memory barrier is required here

Re: [PATCH 1/2] iommu/io-pgtable-arm: Add support for non-coherent page tables

On Mon, Jan 21, 2019 at 6:43 PM Robin Murphy wrote: > > On 17/01/2019 09:27, Vivek Gautam wrote: > > From Robin's comment [1] about touching TCR configurations - > > > > "TBH if we're going to touch the TCR attributes at all then we should > > probably correct that sloppiness first - there's an

[PATCH AUTOSEL 4.20 139/304] iommu/amd: Fix amd_iommu=force_isolation

From: Yu Zhao [ Upstream commit c12b08ebbe16f0d3a96a116d86709b04c1ee8e74 ] The parameter is still there but it's ignored. We need to check its value before deciding to go into passthrough mode for AMD IOMMU v2 capable device. We occasionally use this parameter to force v2 capable device into

[PATCH AUTOSEL 4.20 152/304] iommu/arm-smmu-v3: Avoid memory corruption from Hisilicon MSI payloads

From: Zhen Lei [ Upstream commit 84a9a75774961612d0c7dd34a1777e8f98a65abd ] The GITS_TRANSLATER MMIO doorbell register in the ITS hardware is architected to be 4 bytes in size, yet on hi1620 and earlier, Hisilicon have allocated the adjacent 4 bytes to carry some IMPDEF sideband information

[PATCH AUTOSEL 4.20 153/304] iommu/arm-smmu: Add support for qcom, smmu-v2 variant

From: Vivek Gautam [ Upstream commit 89cddc563743cb1e0068867ac97013b2a5bf86aa ] qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. On msm8996, multiple cores, viz. mdss, video, etc. use this smmu. On sdm845, this smmu is used with gpu. Add bindings for the

[PATCH AUTOSEL 4.20 154/304] iommu/arm-smmu-v3: Use explicit mb() when moving cons pointer

From: Will Deacon [ Upstream commit a868e8530441286342f90c1fd9c5f24de3aa2880 ] After removing an entry from a queue (e.g. reading an event in arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer pointer to free the queue slot back to the SMMU. A memory barrier is required here

[PATCH AUTOSEL 4.9 048/107] iommu/arm-smmu: Add support for qcom, smmu-v2 variant

From: Vivek Gautam [ Upstream commit 89cddc563743cb1e0068867ac97013b2a5bf86aa ] qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. On msm8996, multiple cores, viz. mdss, video, etc. use this smmu. On sdm845, this smmu is used with gpu. Add bindings for the

[PATCH AUTOSEL 4.9 043/107] iommu/amd: Fix amd_iommu=force_isolation

From: Yu Zhao [ Upstream commit c12b08ebbe16f0d3a96a116d86709b04c1ee8e74 ] The parameter is still there but it's ignored. We need to check its value before deciding to go into passthrough mode for AMD IOMMU v2 capable device. We occasionally use this parameter to force v2 capable device into

Re: use generic DMA mapping code in powerpc V4

On Mon, Jan 28, 2019 at 08:04:22AM +0100, Christoph Hellwig wrote: > On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote: > > Christoph, > > > > What shall I do next? > > I'll need to figure out what went wrong with the new zone selection > on powerpc and give you another branch to

[PATCH AUTOSEL 4.9 049/107] iommu/arm-smmu-v3: Use explicit mb() when moving cons pointer

From: Will Deacon [ Upstream commit a868e8530441286342f90c1fd9c5f24de3aa2880 ] After removing an entry from a queue (e.g. reading an event in arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer pointer to free the queue slot back to the SMMU. A memory barrier is required here

Re: [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB

On Wed, Jan 23, 2019 at 04:14:53PM -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 23, 2019 at 01:51:29PM -0500, Michael S. Tsirkin wrote: > > On Wed, Jan 23, 2019 at 05:30:44PM +0100, Joerg Roedel wrote: > > > Hi, > > > > > > here is the third version of this patch-set. Previous > > > versions

[PATCH AUTOSEL 4.4 35/80] iommu/arm-smmu-v3: Use explicit mb() when moving cons pointer

From: Will Deacon [ Upstream commit a868e8530441286342f90c1fd9c5f24de3aa2880 ] After removing an entry from a queue (e.g. reading an event in arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer pointer to free the queue slot back to the SMMU. A memory barrier is required here

Re: [PATCH 0/5 v3] Fix virtio-blk issue with SWIOTLB

On Mon, Jan 28, 2019 at 10:20:05AM -0500, Michael S. Tsirkin wrote: > On Wed, Jan 23, 2019 at 04:14:53PM -0500, Konrad Rzeszutek Wilk wrote: > > On Wed, Jan 23, 2019 at 01:51:29PM -0500, Michael S. Tsirkin wrote: > > > On Wed, Jan 23, 2019 at 05:30:44PM +0100, Joerg Roedel wrote: > > > > Hi, > > >

Re: [RFC v3 02/21] iommu: Introduce cache_invalidate API

Hi Eric, On 25/01/2019 16:49, Auger Eric wrote: [...] >>> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h >>> index 7a7cf7a3de7c..4605f5cfac84 100644 >>> --- a/include/uapi/linux/iommu.h >>> +++ b/include/uapi/linux/iommu.h >>> @@ -47,4 +47,99 @@ struct

Re: [PATCH 2/5] swiotlb: Add is_swiotlb_active() function

On Thu, Jan 24, 2019 at 04:00:00PM +0100, Joerg Roedel wrote: > On Thu, Jan 24, 2019 at 09:41:07AM +0100, Christoph Hellwig wrote: > > On Thu, Jan 24, 2019 at 09:29:23AM +0100, Joerg Roedel wrote: > > > > As I've just introduced and fixed a bug in this area in the current > > > > cycle - I don't

Re: use generic DMA mapping code in powerpc V4

Thanks a lot! I will test it tomorrow. — Christian Sent from my iPhone > On 28. Jan 2019, at 17:22, Christoph Hellwig wrote: > >> On Mon, Jan 28, 2019 at 08:04:22AM +0100, Christoph Hellwig wrote: >>> On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote: >>> Christoph, >>> >>>

Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size

On Mon, Jan 28, 2019 at 09:05:26AM +0100, Christoph Hellwig wrote: > On Thu, Jan 24, 2019 at 10:51:51AM +0100, Joerg Roedel wrote: > > On Thu, Jan 24, 2019 at 09:42:21AM +0100, Christoph Hellwig wrote: > > > Yes. But more importantly it would fix the limit for all other block > > > drivers that

Re: [PATCH] dcdbas: Fix Intel-IOMMU domain allocation failure

On Fri, Jan 25, 2019 at 5:12 AM Robin Murphy wrote: > > On 25/01/2019 11:58, Andy Shevchenko wrote: > > On Fri, Jan 25, 2019 at 3:50 AM Szabolcs Fruhwald > > wrote: > > > > First of all, please do not top post! > > > >> I took a quick look at arch_setup_pdev_archdata(), overridden it in > >>

[PATCH] iommu/amd: print reason for iommu_map_page failure in map_sg

Since there are multiple possible failures in iommu_map_page it would be useful to know which case is being hit when the error message is printed in map_sg. While here, fix up checkpatch complaint about using function name in a string instead of __func__. Cc: Joerg Roedel Signed-off-by: Jerry

Re: [PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size

On Mon, Jan 28, 2019 at 12:14:33PM -0500, Michael S. Tsirkin wrote: > On Mon, Jan 28, 2019 at 09:05:26AM +0100, Christoph Hellwig wrote: > > On Thu, Jan 24, 2019 at 10:51:51AM +0100, Joerg Roedel wrote: > > > On Thu, Jan 24, 2019 at 09:42:21AM +0100, Christoph Hellwig wrote: > > > > Yes. But more

Re: [PATCH v2] iommu/vt-d: Implement dma_[un]map_resource()

Looks good: Reviewed-by: Christoph Hellwig ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 0/3] iommu/arm-smmu: Add support to use Last level cache

Hi Ard, On Thu, Jan 24, 2019 at 1:25 PM Ard Biesheuvel wrote: > > On Thu, 24 Jan 2019 at 07:58, Vivek Gautam > wrote: > > > > On Mon, Jan 21, 2019 at 7:55 PM Ard Biesheuvel > > wrote: > > > > > > On Mon, 21 Jan 2019 at 14:56, Robin Murphy wrote: > > > > > > > > On 21/01/2019 13:36, Ard

Re: [PATCH] iommu/io-pgtable-arm-v7s: only kmemleak_ignore L2 tables

On Mon, Jan 28, 2019 at 05:43:01PM +0800, Nicolas Boichat wrote: > L1 tables are allocated with __get_dma_pages, and therefore already > ignored by kmemleak. > > Without this, the kernel would print this error message on boot, > when the first L1 table is allocated: > > [2.810533] kmemleak:

[PATCH] iommu/io-pgtable-arm-v7s: only kmemleak_ignore L2 tables

L1 tables are allocated with __get_dma_pages, and therefore already ignored by kmemleak. Without this, the kernel would print this error message on boot, when the first L1 table is allocated: [2.810533] kmemleak: Trying to color unknown object at 0xffd652388000 as Black [2.818190]