On Fri, May 5, 2017 at 9:21 PM, Robin Murphy wrote:
> 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.
>>>
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 config or I/O space, s
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 offsets used for
> EVTQ_PROD/
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 offsets used for
> EVTQ_PROD/
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 also MSI for gerror,
>
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
> Signed-off-by: Geetha Sowjanya
> ---
> drivers/acpi/
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, arm_smmu_device_dt_probe/acpi_probe has been mo
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 iommu driver for Qualcomm "B" family devices which do not completely
impl
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 like it *used* to make sense to free the device. But now it
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 respectiv
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 like it *used* to make sense to free the device. But now it is
> >> embedded in 'struct iommu' (which is allocat
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 iommu driver for Qualcomm "B" family devices which do not completely
>>> implement the ARM SMMU spec. These devices have context-bank
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 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
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 map
On Fri, May 5, 2017 at 1:21 PM, Rob Clark wrote:
> 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 acce
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 the device allocated).
>>
>> Sp
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 the device allocated).
>
> Spotted when testing qcom_iommu with CONFIG_DEBUG_TEST_D
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
---
v1: original
v2: b
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
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 passthrough. It revolves all on
> > enabling/disabl
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 ex
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
>>>
>>> <0x 0x8000
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 0x0002 /* Cavium ThunderX2
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 distinc
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
> >>Signed-off-by: Geetha Sowjanya
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
---
include/acpi/actbl2.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/inclu
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 p
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 */
<0x
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) trans
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 p
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 changed, 2 insertions(+)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
in
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 p
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 */
<0x
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) trans
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 p
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 Pinchart
Failures to look up an IOMMU when
< snip ..>
>> +
>> +static struct platform_driver qcom_iommu_driver = {
>> + .driver = {
>> + .name = "qcom-iommu",
>> + .of_match_table = of_match_ptr(qcom_iommu_of_match),
>> + .pm = &qcom_iommu_pm_ops,
>> + },
>> +
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 insertions(+)
diff --git a/Documentation/arm64/silicon-errata.txt
b/Documentation/arm64/
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 shared irqs.
Signed-off-by: Geetha
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
---
drivers/acpi/arm64/iort.c | 10 +-
1 file changed, 9 insertions(+),
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, 10 insertions(+)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v
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 call, so that SMMU options
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 a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index faa9f2c..76a6f5d 100644
--- a/include/ac
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 patchset does software wo
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 access with page 0 offsets.
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 wrote:
> On 0
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? T
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) trans
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) trans
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 p
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 p
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
---
v2
- Addressed Will's
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 s
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:
>>
>> uuid_is_null() / uuid_equ
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
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 developers).
>>
>> Christoph also suggeste
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++)
> > > - if (memcmp(to_nfit_uuid(i), spa->range_guid, 16
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) trans
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 p
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 p
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) trans
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 p
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 p
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 type. At the same time we
>> convert current users.
>>
>> acpi_st
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>, /* 2G @ 2G */
>> <0x
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 fi
66 matches
Mail list logo
