Re: How to resolve an issue in swiotlb environment?

On Wed, 19 Jun 2019, shuah wrote: > I missed a lot of the thread info. and went looking for it and found the > following summary of the problem: > > == > The issue which prompted the commit this thread is about arose in a > situation where the block layer set up a scatterlist

Re: How to resolve an issue in swiotlb environment?

Hi Alan, On 6/18/19 9:28 AM, shuah wrote: On 6/14/19 8:44 AM, Alan Stern wrote: On Thu, 13 Jun 2019, shuah wrote: Great!  So all we have to do is fix vhci-hcd.  Then we can remove all the virt_boundary_mask stuff from usb-storage and uas entirely. (I'm assuming wireless USB isn't a genuine

Re: [PATCH v4 03/22] iommu: Introduce device fault report API

On Sun, 9 Jun 2019 06:44:03 -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 transactions are detected by IOMMU. There is no generic > reporting mechanism to report

Re: use exact allocation for dma coherent memory

On Mon, Jun 17, 2019 at 10:33:42AM +0200, Christoph Hellwig wrote: > > drivers/infiniband/hw/cxgb4/qp.c > >129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq) > >130 { > >131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev), > > sq->memsize, > >

Re: [RFC PATCH v4 20/21] iommu/vt-d: hpet: Reserve an interrupt remampping table entry for watchdog

On Tue, 18 Jun 2019 01:08:06 +0200 (CEST) Thomas Gleixner wrote: > Stephane, > > On Mon, 17 Jun 2019, Stephane Eranian wrote: > > On Mon, Jun 17, 2019 at 1:25 AM Thomas Gleixner > > wrote: > > > Great that there is no trace of any mail from Andi or Stephane > > > about this on LKML. There is

Re: [PATCH] swiotlb: fix phys_addr_t overflow warning

On Mon, Jun 17, 2019 at 09:13:16AM -0700, Stefano Stabellini wrote: > On Mon, 17 Jun 2019, Arnd Bergmann wrote: > > On architectures that have a larger dma_addr_t than phys_addr_t, > > the swiotlb_tbl_map_single() function truncates its return code > > in the failure path, making it impossible to

Re: [PATCH 1/8] iommu: Add I/O ASID allocator

On 18/06/2019 18:05, Jacob Pan wrote: > On Tue, 18 Jun 2019 15:22:20 +0100 > Jean-Philippe Brucker wrote: > >> On 11/06/2019 19:13, Jacob Pan wrote: >> +/** >> + * ioasid_find - Find IOASID data >> + * @set: the IOASID set >> + * @ioasid: the IOASID to find >> + * @getter:

Re: [PATCH v2 02/12] iommu/mediatek: Add probe_defer for smi-larb

On 10/06/2019 14:55, Yong Wu wrote: > The iommu consumer should use device_link to connect with the > smi-larb(supplier). then the smi-larb should run before the iommu > consumer. Here we delay the iommu driver until the smi driver is > ready, then all the iommu consumer always is after the smi

Re: [PATCH 3/8] iommu/arm-smmu-v3: Support platform SSID

On 18/06/2019 19:08, Will Deacon wrote: >> +/* >> + * If the SMMU doesn't support 2-stage CD, limit the linear >> + * tables to a reasonable number of contexts, let's say >> + * 64kB / sizeof(ctx_desc) = 1024 = 2^10 >> + */ >> +if (!(smmu->features &

Re: [PATCH v8 26/29] vfio-pci: Register an iommu fault handler

On 19/06/2019 01:19, Jacob Pan wrote: >>> I see this as a future extension due to limited testing, >> >> I'm wondering how we deal with: >> (1) old userspace that won't fill the new private_data field in >> page_response. A new kernel still has to support it. >> (2) old kernel that won't

Re: [PATCH v3 1/4] firmware: qcom_scm-64: Add atomic version of qcom_scm_call

On Tue, Jun 18, 2019 at 11:25 PM Will Deacon wrote: > > On Wed, Jun 12, 2019 at 12:45:51PM +0530, Vivek Gautam wrote: > > There are scnenarios where drivers are required to make a > > scm call in atomic context, such as in one of the qcom's > > arm-smmu-500 errata [1]. > > > > [1]