Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

2019-10-23 Thread h...@lst.de
On Wed, Oct 23, 2019 at 11:53:41AM +, Laurentiu Tudor wrote: > We had an internal discussion over these points you are raising and > Madalin (cc-ed) came up with another idea: instead of adding this prone > to misuse api how about experimenting with a new dma unmap and dma sync > variants

Re: [PATCH v6 02/10] iommu/vt-d: Add custom allocator for IOASID

2019-10-23 Thread Jacob Pan
On Tue, 22 Oct 2019 21:04:00 -0700 Jacob Pan wrote: > > > + if (cap_caching_mode(iommu->cap) && > > > sm_supported(iommu)) { > > > > do you need to check against cap_caching_mode() or ecap_vcmd? > > > I guess ecap_vcmd() will suffice. Kind of redundant. Actually, we can check

Re: [PATCH v6 02/10] iommu/vt-d: Add custom allocator for IOASID

2019-10-23 Thread Jacob Pan
On Wed, 23 Oct 2019 10:21:51 +0800 Lu Baolu wrote: > >> +#ifdef CONFIG_INTEL_IOMMU_SVM > > > > Maybe move them to intel-svm.c instead? that's where the bulk > > of the svm support is? > > I think this is a generic PASID allocator for guest IOMMU although > vSVA is currently the only

Re: [PATCH v6 01/10] iommu/vt-d: Enlightened PASID allocation

2019-10-23 Thread Jacob Pan
On Wed, 23 Oct 2019 10:55:23 -0700 Jacob Pan wrote: > > > Do you have to check this everytime? every dmar_readq is going to > > > trap to the other side ... > > > > Yes. We don't need to check it every time. Check once and save the > > result during boot is enough. > > > > How about below

Re: [PATCH v6 01/10] iommu/vt-d: Enlightened PASID allocation

2019-10-23 Thread Jacob Pan
On Wed, 23 Oct 2019 09:53:04 +0800 Lu Baolu wrote: > Hi Ashok, > > Thanks for reviewing the patch. > > On 10/23/19 8:45 AM, Raj, Ashok wrote: > > On Tue, Oct 22, 2019 at 04:53:14PM -0700, Jacob Pan wrote: > >> From: Lu Baolu > >> > >> If Intel IOMMU runs in caching mode, a.k.a. virtual

Re: [PATCH v4 3/7] iommu/mediatek: Use gather to achieve the tlb range flush

2019-10-23 Thread Will Deacon
On Wed, Oct 16, 2019 at 11:33:08AM +0800, Yong Wu wrote: > Use the iommu_gather mechanism to achieve the tlb range flush. > Gather the iova range in the "tlb_add_page", then flush the merged iova > range in iotlb_sync. > > Suggested-by: Tomasz Figa > Signed-off-by: Yong Wu > --- >

RE: [PATCH v3 0/7] Nvidia Arm SMMUv2 Implementation

2019-10-23 Thread Krishna Reddy
>>https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/updates Thanks Will! Let me rebase my patches on top of this branch and send it out. -KR ___ iommu mailing list iommu@lists.linux-foundation.org

Re: [PATCH v4 2/7] iommu/mediatek: Add a new tlb_lock for tlb_flush

2019-10-23 Thread Will Deacon
On Wed, Oct 16, 2019 at 11:33:07AM +0800, Yong Wu wrote: > The commit 4d689b619445 ("iommu/io-pgtable-arm-v7s: Convert to IOMMU API > TLB sync") help move the tlb_sync of unmap from v7s into the iommu > framework. It helps add a new function "mtk_iommu_iotlb_sync", But it > lacked the lock, then

Re: [PATCH v3 0/7] Nvidia Arm SMMUv2 Implementation

2019-10-23 Thread Will Deacon
On Tue, Oct 22, 2019 at 11:48:55PM +, Krishna Reddy wrote: > >>Apologies for crossed wires, but I had a series getting rid of > >>arm_smmu_flush_ops which was also meant to end up making things a bit > >>easier for you: > > I was looking to rebase on top of your changes first. Then I read

Re: [PATCH -next] iommu/ipmmu-vmsa: Remove dev_err() on platform_get_irq() failure

2019-10-23 Thread Geert Uytterhoeven
On Wed, Oct 23, 2019 at 4:01 PM YueHaibing wrote: > platform_get_irq() will call dev_err() itself on failure, > so there is no need for the driver to also do this. > This is detected by coccinelle. > > Signed-off-by: YueHaibing Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s,

[PATCH -next] iommu/ipmmu-vmsa: Remove dev_err() on platform_get_irq() failure

2019-10-23 Thread YueHaibing
platform_get_irq() will call dev_err() itself on failure, so there is no need for the driver to also do this. This is detected by coccinelle. Signed-off-by: YueHaibing --- drivers/iommu/ipmmu-vmsa.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

Re: [PATCH v6 00/10] Nested Shared Virtual Address (SVA) VT-d support

2019-10-23 Thread Jacob Pan
On Tue, 22 Oct 2019 17:27:51 -0700 "Raj, Ashok" wrote: > Hi Jacob > > On Tue, Oct 22, 2019 at 04:53:13PM -0700, Jacob Pan wrote: > > Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on > > Intel platforms allow address space sharing between device DMA and > > applications. SVA

Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

2019-10-23 Thread Laurentiu Tudor
Hi Robin, On 22.10.2019 16:25, Robin Murphy wrote: > On 22/10/2019 13:55, Laurentiu Tudor wrote: >> From: Laurentiu Tudor >> >> Introduce a new dma map op called dma_addr_to_phys_addr() that converts >> a dma address to the physical address backing it up and add wrapper for >> it. > > I'd

Re: [PATCH] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.

2019-10-23 Thread h...@lst.de
> + select DMA_CMA Thіs needs to be select DMA_CMA if HAVE_DMA_CONTIGUOUS > +#include > + /* Allocate from CMA */ > + // request_pages = (request_size >> PAGE_SHIFT) + 1; > + request_pages = (round_up(request_size, PAGE_SIZE) >> PAGE_SHIFT); > + page =