RE: [RFC 8/9] drivers: of: call iommu_bus_add_dev after iommu_configure_ops

2016-05-25 Thread Sricharan
Hi Robin, >On 25/04/16 16:58, Sricharan R wrote: >> Now that the device's iommu ops are configured at probe time, >> the device has to be added to the iommu late. >> >> Signed-off-by: Sricharan R >> --- >> drivers/of/device.c | 4 >> 1 file changed, 4

RE: [RFC 5/9] drivers: platform: Configure dma operations at probe time

2016-05-25 Thread Sricharan
Hi Robin, >On 25/04/16 16:58, Sricharan R wrote: >> From: Laurent Pinchart >> >> Configuring DMA ops at probe time will allow deferring device probe when >> the IOMMU isn't available yet. >> >> Signed-off-by: Laurent Pinchart

Re: [PATCH 2/5] iommu: Set PCI_BUS_FLAGS_MSI_REMAP if IOMMU have capability of IRQ remapping

2016-05-25 Thread Bjorn Helgaas
On Wed, May 25, 2016 at 01:54:23PM +0800, Yongji Xie wrote: > On 2016/5/25 5:11, Bjorn Helgaas wrote: > >On Wed, Apr 27, 2016 at 08:43:27PM +0800, Yongji Xie wrote: > >>The capability of IRQ remapping is abstracted on IOMMU side on > >>some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for

Re: How to keep PCI-e endpoints and RCs in distinct IOMMU groups?

2016-05-25 Thread Alex Williamson
On Wed, 25 May 2016 17:26:15 -0700 Mitchel Humpherys wrote: > Hey there, > > We're experiencing an issue with IOMMU groups and PCI-e devices. The > system in question has a WLAN DMA master behind a PCI-e root complex > which is, in turn, behind an IOMMU. There are no

How to keep PCI-e endpoints and RCs in distinct IOMMU groups?

2016-05-25 Thread Mitchel Humpherys
Hey there, We're experiencing an issue with IOMMU groups and PCI-e devices. The system in question has a WLAN DMA master behind a PCI-e root complex which is, in turn, behind an IOMMU. There are no there devices behind the RC. This is on an ARM platform using the arm-smmu and pci-msm drivers

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

2016-05-25 Thread Wei Yang
On Wed, May 25, 2016 at 11:17:49AM +0100, Robin Murphy wrote: >On 25/05/16 00:06, Wei Yang wrote: >>Hi, Joerg >> >>Not sure whether you think this calculation is correct. >> >>If I missed something for this " + 1" in your formula, I am glad to hear your >>explanation. So that I could learn

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

2016-05-25 Thread Matt Fleming
On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote: > > I looked into this and this would be a large change also to parse tables > and build lists. It occurred to me that this could all be taken care of > if the early_memremap calls were changed to early_ioremap calls. Looking > in the git log I

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

2016-05-25 Thread Daniel Kiper
On Tue, May 24, 2016 at 09:54:31AM -0500, Tom Lendacky wrote: > On 05/12/2016 01:20 PM, Tom Lendacky wrote: > > On 05/10/2016 08:57 AM, Borislav Petkov wrote: > >> On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: > >>> Is it not possible to maintain some kind of kernel virtual address

Re: [PATCH V5 6/7] iommu/msm: Use writel_relaxed and add a barrier

2016-05-25 Thread Arnd Bergmann
On Wednesday, May 25, 2016 6:49:18 PM CEST Sricharan wrote: > Hi Arnd, > > >> Ok, so i was doing this from the idea that, other iommu drivers > >> where polling on a status bit in their sync call to ensure completion > >> of pending TLB invalidations. But in this case, there is no status bit. >

Re: [PATCH V5 6/7] iommu/msm: Use writel_relaxed and add a barrier

2016-05-25 Thread Arnd Bergmann
On Wednesday, May 25, 2016 4:15:31 PM CEST Sricharan wrote: > > > >Any operation that could trigger a DMA from a device is required > >to have a barrier preceding it (usually wmb() one implied by writel()), > >so this is clearly not about a driver that installs a DMA mapping > >before starting a

RE: [PATCH V5 6/7] iommu/msm: Use writel_relaxed and add a barrier

2016-05-25 Thread Sricharan
Hi Arnd, >> I had measured the numbers only for the full usecase path, not for the >> reset path alone. I saw improvement of about 5% on full numbers. >> As you said, the reset path would be called only less often >> and might not bring a measurable change. I did not see a difference in >>

Re: [PATCH] iommu/vt-d: reduce extra first level entry in iommu->domains

2016-05-25 Thread Robin Murphy
On 25/05/16 00:06, Wei Yang wrote: Hi, Joerg Not sure whether you think this calculation is correct. If I missed something for this " + 1" in your formula, I am glad to hear your explanation. So that I could learn something from you :-) I'm not familiar enough with this aspect of the driver

Re: [PATCH v2 4/5] iommu/mediatek: add support for mtk iommu generation one HW

2016-05-25 Thread Honghui Zhang
On Tue, 2016-05-24 at 16:36 +0100, Robin Murphy wrote: > On 24/05/16 10:57, Honghui Zhang wrote: > [...] > >>> @@ -48,6 +48,9 @@ struct mtk_iommu_domain { > >>> struct io_pgtable_ops *iop; > >>> > >>> struct iommu_domain domain; > >>> + void

Re: [Patch v4 0/9] *** Fix kdump failure in system with amd iommu***

2016-05-25 Thread Baoquan He
Sorry, log of 'lspci -vvv' is not attatched correclty. Re-attach it here. 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Root Complex Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 30h-3fh) Processor Root Complex

Re: [PATCH 3/5] PCI: Set PCI_BUS_FLAGS_MSI_REMAP if MSI controller supports IRQ remapping

2016-05-25 Thread Yongji Xie
On 2016/5/25 5:04, Bjorn Helgaas wrote: On Wed, Apr 27, 2016 at 08:43:28PM +0800, Yongji Xie wrote: On ARM HW the capability of IRQ remapping is abstracted on MSI controller side. MSI_FLAG_IRQ_REMAPPING is used to advertise this [1]. To have a universal flag to test this capability for

Re: [Patch v4 0/9] *** Fix kdump failure in system with amd iommu***

2016-05-25 Thread Baoquan He
Hi Joerg, Attachments are console log of normal kernel and kdump kernel on a test machine at my hand, and the related information of lspci -vt and lspci -vvv. Before I tried to defer the calling of set_dte_entry() until the device driver try to call __map_single() to really allocate coherent

[Patch v4 9/9] iommu/amd: Check the validation of irq table and domain id

2016-05-25 Thread Baoquan He
From: Baoquan HE If not valid just skip reserving the old domain id. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 4 drivers/iommu/amd_iommu_init.c | 5 +++-- drivers/iommu/amd_iommu_types.h | 5 + 3 files changed,

[Patch v4 4/9] iommu/amd: add early_enable_iommu() helper function

2016-05-25 Thread Baoquan He
From: Baoquan HE This can make later kdump change easier. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git

[Patch v4 7/9] iommu/amd: copy old trans table from old kernel

2016-05-25 Thread Baoquan He
From: Baoquan HE Here several things need be done: 1) Initialize amd_iommu_dev_table because it was set several times since kdump kernel reboot. We don't need the set because we will copy the content from old kernel. 2) Re-enable event/cmd buffer 3) Install

[Patch v4 6/9] iommu/amd: Add function copy_dev_tables

2016-05-25 Thread Baoquan He
Add function copy_dev_tables to copy old DTE of the 1st kernel to the new DTE table. Since all iommu share the same DTE table the copy only need be done once as long as the physical address of old DTE table is retrieved from iommu reg. Besides the old domain id occupied in 1st kernel need be

[Patch v4 8/9] iommu/amd: Do not initialize dev tables again in kdump

2016-05-25 Thread Baoquan He
From: Baoquan HE The init should have been done in normal kernel, skip it in kdump kernel. And clean up the function comments. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 9 ++--- 1 file changed, 6 insertions(+), 3

[Patch v4 5/9] iommu/amd: Define bit fields for DTE particularly

2016-05-25 Thread Baoquan He
In amd-vi spec several bits of IO PTE fields and DTE fields are similar so that both of them can share the same MACRO definition. However defining their respecitve bit fields can make code more read-able. So do it in this patch. Signed-off-by: Baoquan He ---

[Patch v4 3/9] iommu/amd: Detect pre enabled translation

2016-05-25 Thread Baoquan He
Add functions to check whether translation is already enabled in IOMMU. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu_init.c | 25 + drivers/iommu/amd_iommu_types.h | 4 2 files changed, 29 insertions(+) diff --git

[Patch v4 2/9] iommu/amd: Use standard bitmap operation to set bitmap

2016-05-25 Thread Baoquan He
It will be more readable then the old setting. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 2 +- drivers/iommu/amd_iommu_init.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c

[Patch v4 0/9] *** Fix kdump failure in system with amd iommu***

2016-05-25 Thread Baoquan He
Hi Joerg, Recently I have time to continue the work of fixing AMD IOMMU faults in kdump kernel. The situation is I tried to make change at the time point as Intel iommu has done, but still Ethernet NIC will trigger the printing of IO_PAGE_FAULT. I got 2 machines with AMD IOMMU v1 and v2

[Patch v4 1/9] iommu/amd: clean up the cmpxchg64 invocation

2016-05-25 Thread Baoquan He
Change it as it's designed for and keep it consistent with other places. Signed-off-by: Baoquan He --- drivers/iommu/amd_iommu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c index 5efadad..9ec7cad

Re: [PATCH 1/5] PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag

2016-05-25 Thread Yongji Xie
On 2016/5/25 4:55, Bjorn Helgaas wrote: On Wed, Apr 27, 2016 at 08:43:26PM +0800, Yongji Xie wrote: We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP which indicates all devices on the bus are protected by the hardware which supports IRQ remapping(intel naming). This changelog is