Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

On 2017/3/23 21:01, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Reserve the first granule size memory(start at start_pfn) as boundary >> iova, to make sure that iovad->cached32_node can not be NULL in future. >> Meanwhile, changed the assignment of iovad->cached32_node from

Re: [PATCH 3/9] Docs: dt: document qcom iommu bindings

On Thu, Mar 23, 2017 at 6:21 PM, Rob Herring wrote: > On Tue, Mar 14, 2017 at 11:18:05AM -0400, Rob Clark wrote: >> Cc: devicet...@vger.kernel.org >> Signed-off-by: Rob Clark >> --- >> .../devicetree/bindings/iommu/qcom,iommu.txt | 113 >>

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

On 2017/3/23 19:42, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Keep these four variables type consistent with the paramters of function >> __alloc_and_insert_iova_range and the members of struct iova: >> >> 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,

Re: [PATCH 3/9] Docs: dt: document qcom iommu bindings

On Tue, Mar 14, 2017 at 11:18:05AM -0400, Rob Clark wrote: > Cc: devicet...@vger.kernel.org > Signed-off-by: Rob Clark > --- > .../devicetree/bindings/iommu/qcom,iommu.txt | 113 > + > 1 file changed, 113 insertions(+) > create mode 100644

Re: [RFC PATCH v4 15/28] Add support to access persistent memory in the clear

On 3/17/2017 5:58 PM, Elliott, Robert (Persistent Memory) wrote: -Original Message- From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- ow...@vger.kernel.org] On Behalf Of Tom Lendacky Sent: Thursday, February 16, 2017 9:45 AM Subject: [RFC PATCH v4 15/28] Add support to

[PATCH 5/4] iommu/arm-smmu: Poll for TLB sync completion more effectively

On relatively slow development platforms and software models, the inefficiency of our TLB sync loop tends not to show up - for instance on a Juno r1 board I typically see the TLBI has completed of its own accord by the time we get to the sync, such that the latter finishes instantly. However, on

Re: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task

On 23/03/17 16:52, Joerg Roedel wrote: > On Thu, Mar 23, 2017 at 03:52:14PM +, Jean-Philippe Brucker wrote: >> On 23/03/17 14:30, Joerg Roedel wrote: >>> Are you sure about the meaning of the stop-marker? Can you point me to >>> where it is specified? >> >> The concept is introduced in the PCI

Re: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task

On Thu, Mar 23, 2017 at 03:52:14PM +, Jean-Philippe Brucker wrote: > On 23/03/17 14:30, Joerg Roedel wrote: > > Are you sure about the meaning of the stop-marker? Can you point me to > > where it is specified? > > The concept is introduced in the PCI ECN that adds PASIDs to the ATS >

Re: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task

On 23/03/17 14:30, Joerg Roedel wrote: > On Thu, Mar 23, 2017 at 01:37:41PM +, Jean-Philippe Brucker wrote: >> On 22/03/17 22:53, Joerg Roedel wrote: >>> That can't happen, when the device driver does its job right. It has to >>> shut down the context which causes the PPR requests for the

Re: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task

On Thu, Mar 23, 2017 at 01:37:41PM +, Jean-Philippe Brucker wrote: > On 22/03/17 22:53, Joerg Roedel wrote: > > That can't happen, when the device driver does its job right. It has to > > shut down the context which causes the PPR requests for the PASID on the > > device. This includes

Re: [RFC PATCH 24/30] iommu: Specify PASID state when unbinding a task

On 22/03/17 22:53, Joerg Roedel wrote: > On Wed, Mar 22, 2017 at 06:31:01PM +, Jean-Philippe Brucker wrote: >> The problem might be too tied to the specifics of the SMMU. As implemented >> in this series, the normal flow for a PPR with the SMMU is the following: >> >> (1) PCI device issues a

[PATCH] iommu: use sg_phys()

Use sg_phys() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/iommu/intel-iommu.c | 2 +- drivers/iommu/iommu.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

On 22/03/17 06:27, Zhen Lei wrote: > Reserve the first granule size memory(start at start_pfn) as boundary > iova, to make sure that iovad->cached32_node can not be NULL in future. > Meanwhile, changed the assignment of iovad->cached32_node from rb_next to > rb_prev of >node in function

Re: [PATCH 2/7] iommu/iova: cut down judgement times

On 22/03/17 06:27, Zhen Lei wrote: > Below judgement can only be satisfied at the last time, which produced 2N > judgements(suppose N times failed, 0 or 1 time successed) in vain. > > if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) { > return iova; > } For me, GCC (6.2.1 AArch64) seems

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

On 22/03/17 06:27, Zhen Lei wrote: > Keep these four variables type consistent with the paramters of function > __alloc_and_insert_iova_range and the members of struct iova: > > 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad, > unsigned long size, unsigned

Re: [PATCH v2 5/5] iommu: Allow default domain type to be set on the kernel command line

Hi, Replying again, as there was some issue with mailer last time. On 3/21/2017 11:47 PM, Will Deacon wrote: On Tue, Mar 21, 2017 at 05:46:29PM +, Robin Murphy wrote: On 21/03/17 17:21, Will Deacon wrote: On Tue, Mar 21, 2017 at 04:45:27PM +0100, Joerg Roedel wrote: On Fri, Mar 10, 2017

RE: [RFC PATCH 29/30] vfio: Add support for Shared Virtual Memory

Hi Jean, Thx for the excellent ideas. Pls refer to comments inline. [...] > > Hi Jean, > > > > I'm working on virtual SVM, and have some comments on the VFIO channel > > definition. > > Thanks a lot for the comments, this is quite interesting to me. I just have > some > concerns about