Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote: > On 04/05/17 19:41, Oza Oza wrote: > [...] 5) leaves scope of adding PCI flag handling for inbound memory by the new function. >>> >>> Which flags would ever actually matter? DMA windows aren't going to be >>> to

Re: [PATCH v3 1/7] iommu/arm-smmu-v3: Introduce SMMU option PAGE0_REGS_ONLY for ThunderX2 errata #74

On 05.05.17 17:38:05, Geetha sowjanya wrote: > From: Linu Cherian > > Cavium ThunderX2 SMMU implementation doesn't support page 1 register space > and PAGE0_REGS_ONLY option will be enabled as an errata workaround. > > This option when turned on, replaces all page 1

Re: [PATCH v3 1/7] iommu/arm-smmu-v3: Introduce SMMU option PAGE0_REGS_ONLY for ThunderX2 errata #74

On 05.05.17 17:38:05, Geetha sowjanya wrote: > From: Linu Cherian > > Cavium ThunderX2 SMMU implementation doesn't support page 1 register space > and PAGE0_REGS_ONLY option will be enabled as an errata workaround. > > This option when turned on, replaces all page 1

Re: [PATCH v3 0/7] Cavium ThunderX2 SMMUv3 errata workarounds

On 05.05.17 17:38:04, Geetha sowjanya wrote: > From: Linu Cherian > > Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas. > 1. Errata ID #74 >SMMU register alias Page 1 is not implemented > 2. Errata ID #126 >SMMU doesnt support unique IRQ lines and

Re: [PATCH v3 5/7] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model

On 05.05.17 17:38:09, Geetha sowjanya wrote: > From: Linu Cherian > > Cavium ThunderX2 implementation doesn't support second page in SMMU > register space. Hence, resource size is set as 64k for this model. > > Signed-off-by: Linu Cherian >

Re: [PATCH v3 2/7] iommu/arm-smmu-v3: Do resource size checks based on SMMU

On 05.05.17 17:38:06, Geetha sowjanya wrote: > From: Linu Cherian > > With implementations supporting only page 0 register space, > resource size can be 64k as well and hence perform size checks > based on SMMU option PAGE0_REGS_ONLY. > > For this,

Re: [PATCH] iommu: add qcom_iommu

On Fri, May 5, 2017 at 3:50 PM, Rob Herring wrote: > On Fri, May 5, 2017 at 2:37 PM, Rob Clark wrote: >> On Fri, May 5, 2017 at 3:04 PM, Rob Herring wrote: >>> On Fri, May 5, 2017 at 1:21 PM, Rob Clark wrote: An

Re: [PATCH] iommu: fix device remove

On Fri, May 5, 2017 at 3:58 PM, Greg KH wrote: > On Fri, May 05, 2017 at 02:56:00PM -0400, Rob Clark wrote: >> On Fri, May 5, 2017 at 2:24 PM, Greg KH wrote: >> > On Fri, May 05, 2017 at 02:08:37PM -0400, Rob Clark wrote: >> >> It looks

Re: [PATCH] iommu: intel: Flush the IOTLB to get rid of the initial kdump mappings

On Fri, 2017-05-05 at 11:39 -0700, KarimAllah Ahmed wrote: > Ever since commit 091d42e43d ("iommu/vt-d: Copy translation tables from > old kernel") the kdump kernel copies the IOMMU context tables from the > previous kernel. Each device mappings will be destroyed once the driver > for the

[PATCH] iommu: intel: Flush the IOTLB to get rid of the initial kdump mappings

Ever since commit 091d42e43d ("iommu/vt-d: Copy translation tables from old kernel") the kdump kernel copies the IOMMU context tables from the previous kernel. Each device mappings will be destroyed once the driver for the respective device takes over. This unfortunately breaks the workflow of

Re: [PATCH] iommu: fix device remove

On Fri, May 5, 2017 at 2:24 PM, Greg KH wrote: > On Fri, May 05, 2017 at 02:08:37PM -0400, Rob Clark wrote: >> It looks like it *used* to make sense to free the device. But now it is >> embedded in 'struct iommu' (which is allocated or embedded in something >> that

[PATCH] iommu: add qcom_iommu

An iommu driver for Qualcomm "B" family devices which do not completely implement the ARM SMMU spec. These devices have context-bank register layout that is similar to ARM SMMU, but no global register space (or at least not one that is accessible). Signed-off-by: Rob Clark

[PATCH] iommu: fix device remove

It looks like it *used* to make sense to free the device. But now it is embedded in 'struct iommu' (which is allocated or embedded in something that the device allocated). Spotted when testing qcom_iommu with CONFIG_DEBUG_TEST_DRIVER_REMOVE. Fixes: 39ab955 ("iommu: Add sysfs bindings for struct

Re: AMD Ryzen KVM/NPT/IOMMU issue

On Wed, 3 May 2017 12:28:35 -0400 Nick Sarnie wrote: > On Wed, May 3, 2017 at 10:37 AM, Matthias Ehrenfeuchter > wrote: > > Hi, > > > > There are a lot of messages/threads out there about bad performance while > > using AMDs Ryzen with KVM GPU

Re: [PATCH v5 13/32] x86/boot/e820: Add support to determine the E820 type of an address

On Tue, Apr 18, 2017 at 04:18:31PM -0500, Tom Lendacky wrote: > Add a function that will return the E820 type associated with an address > range. ... > @@ -110,9 +111,28 @@ bool __init e820__mapped_all(u64 start, u64 end, enum > e820_type type) >* coverage of the desired range

Re: [PATCH 2/3] iommu/pci: reserve iova for PCI masters

On 04/05/17 19:52, Oza Oza wrote: > On Thu, May 4, 2017 at 11:50 PM, Robin Murphy wrote: >> On 03/05/17 05:46, Oza Pawandeep wrote: >>> this patch reserves the iova for PCI masters. >>> ARM64 based SOCs may have scattered memory banks. >>> such as iproc based SOC has >>> >>>

Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

On 05/05/2017 10:58 AM, Will Deacon wrote: > On Fri, May 05, 2017 at 07:56:17AM -0700, David Daney wrote: >> On 05/05/2017 06:53 AM, Hanjun Guo wrote: >>> On 2017/5/5 20:08, Geetha sowjanya wrote: From: Linu Cherian +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

On 04/05/17 19:41, Oza Oza wrote: [...] >>> 5) leaves scope of adding PCI flag handling for inbound memory >>> by the new function. >> >> Which flags would ever actually matter? DMA windows aren't going to be >> to config or I/O space, so the memory type can be assumed, and the >> 32/64-bit

Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

On Fri, May 05, 2017 at 07:56:17AM -0700, David Daney wrote: > On 05/05/2017 06:53 AM, Hanjun Guo wrote: > >On 2017/5/5 20:08, Geetha sowjanya wrote: > >>From: Linu Cherian > >> > >>Add SMMUv3 model definition for ThunderX2. > >> > >>Signed-off-by: Linu Cherian

Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

On 05/05/2017 06:53 AM, Hanjun Guo wrote: On 2017/5/5 20:08, Geetha sowjanya wrote: From: Linu Cherian Add SMMUv3 model definition for ThunderX2. Signed-off-by: Linu Cherian Signed-off-by: Geetha Sowjanya

[PATCH v5 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v5 2/3] iommu/pci: reserve IOVA for PCI masters

this patch reserves the IOVA for PCI masters. ARM64 based SOCs may have scattered memory banks. such as iproc based SOC has <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */ <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */ <0x0090 0x 0x4 0x>, /* 16G @ 576G */

[PATCH v5 0/3] OF/PCI address PCI inbound memory limitations

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU)

[PATCH v5 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

On 2017/5/5 20:08, Geetha sowjanya wrote: From: Linu Cherian Add SMMUv3 model definition for ThunderX2. Signed-off-by: Linu Cherian Signed-off-by: Geetha Sowjanya --- include/acpi/actbl2.h | 2 ++ 1 file

[PATCH v4 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v4 2/3] iommu/pci: reserve IOVA for PCI masters

this patch reserves the IOVA for PCI masters. ARM64 based SOCs may have scattered memory banks. such as iproc based SOC has <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */ <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */ <0x0090 0x 0x4 0x>, /* 16G @ 576G */

[PATCH v4 0/3] OF/PCI address PCI inbound memory limitations

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU)

[PATCH v4 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

Hi Sricharan, Robin, On Wed, May 3, 2017 at 12:24 PM, Sricharan R wrote: > On 5/3/2017 3:24 PM, Robin Murphy wrote: >> On 02/05/17 19:35, Geert Uytterhoeven wrote: >>> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R >>> wrote: From: Laurent

Re: [PATCH 3/4] iommu: add qcom_iommu

< snip ..> >> + >> +static struct platform_driver qcom_iommu_driver = { >> + .driver = { >> + .name = "qcom-iommu", >> + .of_match_table = of_match_ptr(qcom_iommu_of_match), >> + .pm = _iommu_pm_ops, >> + }, >> +

[PATCH v3 7/7] arm64: Documentation: Add Cavium ThunderX2 SMMUv3 erratas

From: Linu Cherian Add Cavium ThunderX2 SMMUv3 erratas to the errata list. Signed-off-by: Linu Cherian Signed-off-by: Geetha Sowjanya --- Documentation/arm64/silicon-errata.txt | 2 ++ 1 file changed, 2

[PATCH v3 6/7] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #126

From: Geetha Sowjanya Cavium ThunderX2 SMMU doesn't support MSI and also doesn't have unique irq lines for gerror, eventq and cmdq-sync. This patch addresses the issue by checking if any interrupt sources are using same irq number, then they are registered as

[PATCH v3 5/7] ACPI/IORT: Fixup SMMUv3 resource size for Cavium ThunderX2 SMMUv3 model

From: Linu Cherian Cavium ThunderX2 implementation doesn't support second page in SMMU register space. Hence, resource size is set as 64k for this model. Signed-off-by: Linu Cherian Signed-off-by: Geetha Sowjanya

[PATCH v3 4/7] iommu/arm-smmu-v3: For ACPI based device probing, set PAGE0_REGS_ONLY option for ThunderX2 SMMUv3 implementation.

From: Linu Cherian Enable PAGE0_REGS_ONLY option for Cavium ThunderX2 SMMUv3 model. Signed-off-by: Linu Cherian Signed-off-by: Geetha Sowjanya --- drivers/iommu/arm-smmu-v3.c | 10 ++ 1 file changed,

[PATCH v3 2/7] iommu/arm-smmu-v3: Do resource size checks based on SMMU

From: Linu Cherian With implementations supporting only page 0 register space, resource size can be 64k as well and hence perform size checks based on SMMU option PAGE0_REGS_ONLY. For this, arm_smmu_device_dt_probe/acpi_probe has been moved before platform_get_resource

[PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

From: Linu Cherian Add SMMUv3 model definition for ThunderX2. Signed-off-by: Linu Cherian Signed-off-by: Geetha Sowjanya --- include/acpi/actbl2.h | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH v3 1/7] iommu/arm-smmu-v3: Introduce SMMU option PAGE0_REGS_ONLY for ThunderX2 errata #74

From: Linu Cherian Cavium ThunderX2 SMMU implementation doesn't support page 1 register space and PAGE0_REGS_ONLY option will be enabled as an errata workaround. This option when turned on, replaces all page 1 offsets used for EVTQ_PROD/CONS, PRIQ_PROD/CONS register

[PATCH v3 0/7] Cavium ThunderX2 SMMUv3 errata workarounds

From: Linu Cherian Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas. 1. Errata ID #74 SMMU register alias Page 1 is not implemented 2. Errata ID #126 SMMU doesnt support unique IRQ lines and also MSI for gerror, eventq and cmdq-sync The following

Re: [PATCH 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

Hi Jon, Charles Garcia-Tobin has confirmed that the new IORT spec includes Cavium ThunderX model number. I have resubmitted patches based on IORT model number. https://www.spinics.net/lists/arm-kernel/msg579511.html Thank you, Geetha. On Fri, May 5, 2017 at 5:06 AM, Jon Masters

Re: AMD Ryzen KVM/NPT/IOMMU issue

I recognized (with npt disabled) the VM is getting slower over time, like in Windows the system process is taking more and more CPU usage. A soft restart does help makeing it "usable" again. Also wondering if this is an hardware related issue in Ryzen, so the upcoming Naples does have it too?

[PATCH v3 0/3] OF/PCI address PCI inbound memory limitations

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU)

[PATCH v2 0/3] OF/PCI address PCI inbound memory limitations

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU)

[PATCH v3 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v3 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v2] iommu/arm-smmu-v3: Increase CMDQ drain timeout value

From: Sunil Goutham Processing queue full of TLB invalidation commands might take more time on some platforms than current timeout of 100us. So increased drain timeout value. Also now udelay time is increased exponentially for each poll. Signed-off-by: Sunil Goutham

[PATCH] iommu/dma: Don't touch invalid iova_domain members

When __iommu_dma_map() and iommu_dma_free_iova() are called from iommu_dma_get_msi_page(), various iova_*() helpers are still invoked in the process, whcih is unwise since they access a different member of the union (the iova_domain) from that which was last written, and there's no guarantee that

Re: [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 5, 2017 at 12:57 PM, Christoph Hellwig wrote: > On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote: >> To complete the picture for folks not cc'ed on my patches, >> xfs use case suggests there is also justification for the additional helpers: >> >>

Re: [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote: > To complete the picture for folks not cc'ed on my patches, > xfs use case suggests there is also justification for the additional helpers: > > uuid_is_null() / uuid_equal() > guid_is_null() / guid_equal() The is_null is useful and

Re: [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 5, 2017 at 12:24 PM, Andy Shevchenko wrote: > On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote: [...] >> I think with this semantic change, our proposals can reach common >> grounds >> and satisfy a wider group of users (i.e. filesystem

Re: [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote: > On Fri, May 5, 2017 at 9:20 AM, Dan Williams > wrote: > > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko > > wrote: > > > for (i = 0; i < NFIT_UUID_MAX; i++) > > >

[PATCH v2 0/3] OF/PCI address PCI inbound memory limitations

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU)

[PATCH v2 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v2 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v2 0/3] OF/PCI address PCI inbound memory limitations

It is possible that PCI device supports 64-bit DMA addressing, and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64), however PCI host bridge may have limitations on the inbound transaction addressing. This is particularly problematic on ARM/ARM64 SOCs where the IOMMU (i.e. SMMU)

[PATCH v2 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

[PATCH v2 1/3] of/pci/dma: fix DMA configuration for PCI masters

current device framework and OF framework integration assumes dma-ranges in a way where memory-mapped devices define their dma-ranges. (child-bus-address, parent-bus-address, length). of_dma_configure is specifically written to take care of memory mapped devices. but no implementation exists for

Re: [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 5, 2017 at 9:20 AM, Dan Williams wrote: > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko > wrote: >> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 >> bytes. Instead we convert them to use uuid_le

Re: [PATCH 2/3] iommu/pci: reserve iova for PCI masters

On Thu, May 4, 2017 at 11:50 PM, Robin Murphy wrote: > On 03/05/17 05:46, Oza Pawandeep wrote: >> this patch reserves the iova for PCI masters. >> ARM64 based SOCs may have scattered memory banks. >> such as iproc based SOC has >> >> <0x 0x8000 0x0 0x8000>,

Re: [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 05, 2017 at 10:06:06AM +0300, Amir Goldstein wrote: > I much rather that you sort out uuid helpers in a way that will > satisfy the filesystem > needs (just provide the helpers don't need to convert filesystems code). Yeah. > IMO, you should acknowledge that the common use case for

Re: [PATCH v1] ACPI: Switch to use generic UUID API

On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use uuid_le type. At the same time we > convert current users. > > acpi_str_to_uuid() becomes

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

-Shevchenko/ACPI-Switch-to-use-generic-UUID-API/20170505-134225 config: i386-tinyconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): I