Re: [PATCH v5 11/23] driver core: add per device iommu param

Hi, On 05/12/2018 04:54 AM, Jacob Pan wrote: > DMA faults can be detected by IOMMU at device level. Adding a pointer > to struct device allows IOMMU subsystem to report relevant faults > back to the device driver for further handling. > For direct assigned device (or user space drivers), guest OS

Re: [PATCH v5 09/23] iommu/vt-d: add svm/sva invalidate function

Hi, On 05/12/2018 04:54 AM, Jacob Pan wrote: > When Shared Virtual Address (SVA) is enabled for a guest OS via > vIOMMU, we need to provide invalidation support at IOMMU API and driver > level. This patch adds Intel VT-d specific function to implement > iommu passdown invalidate API for shared

Re: [PATCH v5 08/23] iommu/vt-d: support flushing more translation cache types

Hi, On 05/12/2018 04:54 AM, Jacob Pan wrote: > When Shared Virtual Memory is exposed to a guest via vIOMMU, extended > IOTLB invalidation may be passed down from outside IOMMU subsystems. > This patch adds invalidation functions that can be used for additional > translation cache types. > >

Re: [PATCH v5 07/23] iommu/vt-d: fix dev iotlb pfsid use

Hi, On 05/12/2018 04:53 AM, Jacob Pan wrote: > PFSID should be used in the invalidation descriptor for flushing > device IOTLBs on SRIOV VFs. This patch could be submitted separately. > > Signed-off-by: Jacob Pan > --- > drivers/iommu/dmar.c| 6 +++--- >

Re: [PATCH v5 06/23] iommu/vt-d: add definitions for PFSID

Hi, On 05/12/2018 04:53 AM, Jacob Pan wrote: > When SRIOV VF device IOTLB is invalidated, we need to provide > the PF source ID such that IOMMU hardware can gauge the depth > of invalidation queue which is shared among VFs. This is needed > when device invalidation throttle (DIT) capability is

Re: common non-cache coherent direct dma mapping ops

On 11.05.2018 09:59, Christoph Hellwig wrote: > this series continues consolidating the dma-mapping code, with a focus > on architectures that do not (always) provide cache coherence for DMA. > Three architectures (arm, mips and powerpc) are still left to be > converted later due to complexity of

Re: [PATCH v5 04/23] iommu/vt-d: add bind_pasid_table function

Hi, On 05/12/2018 04:53 AM, Jacob Pan wrote: > Add Intel VT-d ops to the generic iommu_bind_pasid_table API > functions. > > The primary use case is for direct assignment of SVM capable > device. Originated from emulated IOMMU in the guest, the request goes > through many layers (e.g. VFIO). Upon

Re: [PATCH] swiotlb: Silent unwanted warning "buffer is full"

On Sat, 12 May 2018 12:02:40 +0200, Christoph Hellwig wrote: > Thanks. > > I manually applied this for 4.17-rc, as the mail unfortunately was > garbled. Sorry about that. Because of the umlauts in the Cc list, the mail was encoded as quoted-printable instead of 7bit. I guess this is what caused

Re: [PATCH v5 03/23] iommu/vt-d: add a flag for pasid table bound status

Hi again, On 05/12/2018 04:53 AM, Jacob Pan wrote: > Adding a flag in device domain into to track whether a guest or > user PASID table is bound to a device. > > Signed-off-by: Jacob Pan > --- > include/linux/intel-iommu.h | 1 + > 1 file changed, 1 insertion(+) >

Re: [PATCH v5 03/23] iommu/vt-d: add a flag for pasid table bound status

Hi, On 05/12/2018 04:53 AM, Jacob Pan wrote: > Adding a flag in device domain into to track whether a guest or typo: ^^info Best regards, Lu Baolu > user PASID table is bound to a device. > > Signed-off-by: Jacob Pan > --- >

[GIT PULL] dma mapping fix for 4.17-rc5

Hi Linus, one trivial dma-mapping regression fix for you. Note that this has NOT been in linux-next as I didn't want to disturb the branch in there which has the 4.18 material. I've asked Stephen to add the for-linus branch in addition to for-next so that this doesn't happen again. In addition