Re: [RFC] virtio-iommu version 0.5

2017-10-23 Thread Linu Cherian
Hi Jean, On Mon Oct 23, 2017 at 10:32:41AM +0100, Jean-Philippe Brucker wrote: > This is version 0.5 of the virtio-iommu specification, the paravirtualized > IOMMU. This version addresses feedback from v0.4 and adds an event virtqueue. > Please find the specification, LaTeX sources and pdf, at: >

Re: AMD Ryzen KVM/NPT/IOMMU issue

2017-10-23 Thread geoff--- via iommu
Further to this I have verified that IOMMU is working fine, traces and additional printk's added to the kernel module were used to check. All accesses are successful and hit the correct addresses. However profiling under Windows shows there might be an issue with IRQs not reaching the guest. When

AMD Ryzen KVM/NPT/IOMMU issue

2017-10-23 Thread geoff--- via iommu
Hi, I realize this is an older thread but I have spent much of today trying to diagnose the problem. I have discovered how to reliably reproduce the problem with very little effort. It seems that reproducing the issue has been hit and miss for people as it seems to primarily affect games/pr

RE: [PATCH v4 12/12] intel-ipu3: imgu top level pci device

2017-10-23 Thread Zhi, Yong
Hi, Sakari, > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Sakari Ailus > Sent: Friday, October 20, 2017 4:15 AM > To: Zhi, Yong > Cc: linux-me...@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian > Xu ; M

RE: [PATCH v4 00/12] Intel IPU3 ImgU patchset

2017-10-23 Thread Zhi, Yong
Hi, Sakari, > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Sakari Ailus > Sent: Friday, October 20, 2017 2:10 AM > To: Zhi, Yong > Cc: linux-me...@vger.kernel.org; sakari.ai...@linux.intel.com; Zheng, Jian > Xu ; M

Re: [PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

2017-10-23 Thread Jerome Glisse
On Sat, Oct 21, 2017 at 11:47:03AM -0400, Jerome Glisse wrote: > On Sat, Oct 21, 2017 at 04:54:40PM +1100, Balbir Singh wrote: > > On Thu, 2017-10-19 at 12:58 -0400, Jerome Glisse wrote: > > > On Thu, Oct 19, 2017 at 09:53:11PM +1100, Balbir Singh wrote: > > > > On Thu, Oct 19, 2017 at 2:28 PM, Jer

Re: [RFCv2 PATCH 00/36] Process management for IOMMU + SVM for SMMUv3

2017-10-23 Thread Jean-Philippe Brucker
Hi Jordan, [Lots of IOMMU people have been dropped from Cc, I've tried to add them back] On 12/10/17 16:28, Jordan Crouse wrote: > On Thu, Oct 12, 2017 at 01:55:32PM +0100, Jean-Philippe Brucker wrote: >> On 12/10/17 13:05, Yisheng Xie wrote: >> [...] >> * An iommu_process can be bound to mul

Re: [RFCv2 PATCH 01/36] iommu: Keep track of processes and PASIDs

2017-10-23 Thread Jean-Philippe Brucker
On 23/10/17 12:04, Liu, Yi L wrote: >> +idr_preload(GFP_KERNEL); >> +spin_lock(&iommu_process_lock); >> +pasid = idr_alloc_cyclic(&iommu_process_idr, process, domain->min_pasid, >> + domain->max_pasid + 1, GFP_ATOMIC); >> +process->pasid = pasid; > > [Li

RE: [RFCv2 PATCH 01/36] iommu: Keep track of processes and PASIDs

2017-10-23 Thread Liu, Yi L
Hi Jean, > -Original Message- > From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Friday, October 6, 2017 9:31 PM > To: linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux- > a...@vger.kernel.org; devicet...@vger.kernel.org; iommu@lists.linux- >

[RFC] virtio-iommu version 0.5

2017-10-23 Thread Jean-Philippe Brucker
This is version 0.5 of the virtio-iommu specification, the paravirtualized IOMMU. This version addresses feedback from v0.4 and adds an event virtqueue. Please find the specification, LaTeX sources and pdf, at: git://linux-arm.org/virtio-iommu.git viommu/v0.5 http://linux-arm.org/git?p=virtio-iommu

RE: [PATCH 5/9] PCI: host: brcmstb: add dma-ranges for inbound traffic

2017-10-23 Thread David Laight
From: Jim Quinlan > Sent: 20 October 2017 16:28 > On Fri, Oct 20, 2017 at 10:57 AM, Christoph Hellwig wrote: > > On Fri, Oct 20, 2017 at 10:41:56AM -0400, Jim Quinlan wrote: > >> I am not sure I understand your comment -- the size of the request > >> shouldn't be a factor. Let's look at your exam