Re: [PATCH v2 10/16] iommu: introduce device fault report API

On Tue, 10 Oct 2017 15:40:54 +0200 Joerg Roedel wrote: > On Thu, Oct 05, 2017 at 04:03:38PM -0700, Jacob Pan wrote: > > Traditionally, device specific faults are detected and handled > > within their own device drivers. When IOMMU is enabled, faults such > > as DMA related

Re: [PATCH v8 13/14] IB/core: use MAP_DIRECT to fix / enable RDMA to DAX mappings

On Wed, Oct 11, 2017 at 4:54 AM, Joerg Roedel wrote: > On Tue, Oct 10, 2017 at 07:50:12AM -0700, Dan Williams wrote: >> +static void ib_umem_lease_break(void *__umem) >> +{ >> + struct ib_umem *umem = umem; >> + struct ib_device *idev = umem->context->device; >> +

Re: [PATCH] iommu/io-pgtable-arm: hide unused ipmmu_iotlb_sync

On Wed, Oct 11, 2017 at 4:16 PM, Robin Murphy wrote: > On 11/10/17 14:59, Arnd Bergmann wrote: > > That said, I think the third option is now viable as well, namely to > shuffle some lines and get rid of the almost-duplicated ops entirely. > I'll have a quick go at that

Re: [PATCH] iommu/io-pgtable-arm: hide unused ipmmu_iotlb_sync

On 11/10/17 14:59, Arnd Bergmann wrote: > There are two sets of iommu_ops in this driver, and only > one of them contains a reference to the ipmmu_iotlb_sync > function. This leads to a compiler warning when these > operations are not in use: > > drivers/iommu/ipmmu-vmsa.c:622:13: error:

Re: [PATCH v8 01/14] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

On Wed, Oct 11, 2017 at 12:43 AM, Jan Kara wrote: > On Tue 10-10-17 07:49:01, Dan Williams wrote: >> The mmap(2) syscall suffers from the ABI anti-pattern of not validating >> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a >> mechanism to define new behavior

[PATCH] iommu/io-pgtable-arm: hide unused ipmmu_iotlb_sync

There are two sets of iommu_ops in this driver, and only one of them contains a reference to the ipmmu_iotlb_sync function. This leads to a compiler warning when these operations are not in use: drivers/iommu/ipmmu-vmsa.c:622:13: error: 'ipmmu_iotlb_sync' defined but not used

[PATCH] xhci: Set DMA parameters appropriately

xHCI requires that data buffers do not cross 64KB boundaries (and are thus at most 64KB long as well) - whilst xhci_queue_{bulk,isoc}_tx() already split their input buffers into individual TRBs as necessary, it's still a good idea to advertise the limitations via the standard DMA API mechanism, so

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

On 11/10/17 13:15, Joerg Roedel wrote: > On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: >> I didn't quite get 'iovm' mean. Can you explain a bit about the idea? > > It's short for IO Virtual Memory, basically a replacement term for 'svm' > that is not ambiguous (afaik) and not

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: > I didn't quite get 'iovm' mean. Can you explain a bit about the idea? It's short for IO Virtual Memory, basically a replacement term for 'svm' that is not ambiguous (afaik) and not specific to Intel. Joerg

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

> On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote: > > I agree that iommu_invalidate() is too generic. Additionally, also > > better to avoid making it svm specific. > > I also don't like to name the functions after the Intel feature, but I failed > to come up > with a better

Re: [PATCH v8 13/14] IB/core: use MAP_DIRECT to fix / enable RDMA to DAX mappings

On Tue, Oct 10, 2017 at 07:50:12AM -0700, Dan Williams wrote: > +static void ib_umem_lease_break(void *__umem) > +{ > + struct ib_umem *umem = umem; > + struct ib_device *idev = umem->context->device; > + struct device *dev = idev->dma_device; > + struct scatterlist *sgl =

RE: [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

Hi Will, Any further comments on this series, please? We do have the ack from all relevant people for the "[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3" now. Really appreciate if you can take a look and let us know. Many thanks, Shameer > -Original

Re: [RFCv2 PATCH 05/36] iommu/process: Bind and unbind process to and from devices

Hi Jean-Philipe, Thanks for your patches, this is definitly a step in the right direction to get generic support for IO virtual memory into the IOMMU core code. But I see an issue with the design around task_struct, please see below. On Fri, Oct 06, 2017 at 02:31:32PM +0100, Jean-Philippe

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

On Wed, Oct 11, 2017 at 07:54:32AM +, Liu, Yi L wrote: > I agree that iommu_invalidate() is too generic. Additionally, also > better to avoid making it svm specific. I also don't like to name the functions after the Intel feature, but I failed to come up with a better alternative so far. The

Re: [PATCH v2 01/16] iommu: introduce bind_pasid_table API function

On 10/10/17 22:42, Jacob Pan wrote: [...] >>> +/** >>> + * PASID table data used to bind guest PASID table to the host >>> IOMMU. This will >>> + * enable guest managed first level page tables. >>> + * @version: for future extensions and identification of the data >>> format >>> + * @bytes: size

Re: [PATCH v8 01/14] mm: introduce MAP_SHARED_VALIDATE, a mechanism to safely define new mmap flags

On Tue 10-10-17 07:49:01, Dan Williams wrote: > The mmap(2) syscall suffers from the ABI anti-pattern of not validating > unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a > mechanism to define new behavior that is known to fail on older kernels > without the support. Define a

RE: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

> On Tue, 10 Oct 2017 15:35:42 +0200 > Joerg Roedel wrote: > > > On Thu, Oct 05, 2017 at 04:03:31PM -0700, Jacob Pan wrote: > > > +int iommu_invalidate(struct iommu_domain *domain, > > > + struct device *dev, struct tlb_invalidate_info > > > *inv_info) > > > > This name

Re: [PATCH] iommu/exynos: Remove initconst attribute to avoid potential kernel oops

On Wed, Oct 11, 2017 at 07:49:05AM +0200, Marek Szyprowski wrote: > Could you also apply it to v4.14-fixes, or is it too late for that? Well, I already pushed it out, but I guess I can still move the patch to another branch. Joerg ___ iommu