On 15/01/2019 20:33, Gerald Schaefer wrote:
On Tue, 15 Jan 2019 18:37:30 +0100
Pierre Morel wrote:
The s390 iommu can only allow DMA transactions between the zPCI device
entries start_dma and end_dma.
Let's declare the regions before start_dma and after end_dma as
reserved regions using the a
On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson wrote:
>
> +Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
>
> On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig wrote:
> >
> > Hi everyone,
> >
> > this series converts the remaining MMC host drivers to properly kmap the
> > s
Hi Robin,
On 2019-01-14 17:38, Robin Murphy wrote:
> On 14/01/2019 16:09, Thierry Reding wrote:
>> On Mon, Jan 14, 2019 at 02:22:40PM +0100, Marek Szyprowski wrote:
>>> This reverts commit 1874619a7df4b14b23b14877e705ae15325773e3.
>>>
>>> That patch broke IOMMU support for devices, which fails to
On 15/01/2019 21:06, Auger Eric wrote:
>>> + iommu_report_device_fault(master->dev, &event);
>>
>> We should return here if the fault is successfully injected
>
> Even if the fault gets injected in the guest can't it be still useful to
> get the message below on host side?
I don't think
Hi Jean,
On 1/16/19 1:25 PM, Jean-Philippe Brucker wrote:
> On 15/01/2019 21:06, Auger Eric wrote:
+ iommu_report_device_fault(master->dev, &event);
>>>
>>> We should return here if the fault is successfully injected
>>
>> Even if the fault gets injected in the guest can't it be stil
On Tue, Jan 15, 2019 at 07:33:54PM +0300, Dmitry Osipenko wrote:
> Should I expect that the patches will appear in the IOMMU git and in
> -next consequently? Please let me know if there is any problem with
> the applying of the patches.
Hmm, I thought I applied these patches already, but obviously
Hi Suravee,
On Wed, Jan 16, 2019 at 04:15:10AM +, Suthikulpanit, Suravee wrote:
> From: Suravee Suthikulpanit
>
> When a device switches domain, IOMMU driver detach device from the old
> domain, and attach device to the new domain. During this period
> the host table root pointer is not set,
16.01.2019 15:55, Joerg Roedel пишет:
> On Tue, Jan 15, 2019 at 07:33:54PM +0300, Dmitry Osipenko wrote:
>> Should I expect that the patches will appear in the IOMMU git and in
>> -next consequently? Please let me know if there is any problem with
>> the applying of the patches.
>
> Hmm, I thought
On Wed, Jan 16, 2019 at 04:16:25AM +, Suthikulpanit, Suravee wrote:
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index 525659b88ade..ab31ba75da1b 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -1248,7 +1248,13 @@ static void __domain_fl
On Wed, Jan 16, 2019 at 11:25 AM Arnd Bergmann wrote:
> On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson wrote:
> >
> > +Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
Nah it's not THAT bounce buffer.
> Linus probably knows more here, but I have a vague recollection of
>
On Wed, Jan 16, 2019 at 2:51 PM Linus Walleij wrote:
>
> On Wed, Jan 16, 2019 at 11:25 AM Arnd Bergmann wrote:
> > On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson wrote:
> > >
> > > +Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
>
> Nah it's not THAT bounce buffer.
>
> >
On Tue, Jan 15, 2019 at 02:22:57PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Segments can't be larger than the maximum DMA mapping size
> supported on the platform. Take that into account when
> setting the maximum segment size for a block device.
>
> Signed-off-by: Joerg Roedel
> ---
Joerg,
On 1/16/19 8:26 PM, j...@8bytes.org wrote:
> On Wed, Jan 16, 2019 at 04:16:25AM +, Suthikulpanit, Suravee wrote:
>> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
>> index 525659b88ade..ab31ba75da1b 100644
>> --- a/drivers/iommu/amd_iommu.c
>> +++ b/drivers/iommu/amd
On Tue, Jan 15, 2019 at 02:20:19PM +0100, Christoph Hellwig wrote:
> On Tue, Jan 15, 2019 at 09:37:42AM +0100, Joerg Roedel wrote:
> > On Mon, Jan 14, 2019 at 01:20:45PM -0500, Michael S. Tsirkin wrote:
> > > Which would be fine especially if we can manage not to introduce a bunch
> > > of indirect
On Wed, Jan 16, 2019 at 09:05:40AM -0500, Michael S. Tsirkin wrote:
> On Tue, Jan 15, 2019 at 02:22:57PM +0100, Joerg Roedel wrote:
> > + max_size = dma_max_mapping_size(&vdev->dev);
> > +
>
>
> Should this be limited to ACCESS_PLATFORM?
>
> I see no reason to limit this without as guest can
>
Joerg,
On 1/16/19 8:03 PM, j...@8bytes.org wrote:
> Hi Suravee,
>
> On Wed, Jan 16, 2019 at 04:15:10AM +, Suthikulpanit, Suravee wrote:
>> From: Suravee Suthikulpanit
>>
>> When a device switches domain, IOMMU driver detach device from the old
>> domain, and attach device to the new domain.
Joerg,
On 1/16/19 8:26 PM, j...@8bytes.org wrote:
> How about the attached diff? If
> I understand the problem correctly, it should fix the problem more
> reliably.
>
> Thanks,
>
> Joerg
>
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index 87ba23a75b38..dc1e2a8a1
On Mon, Jan 14, 2019 at 09:33:23PM +0100, Christoph Hellwig wrote:
> On Mon, Jan 14, 2019 at 03:25:13PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 14, 2019 at 09:14:08PM +0100, Christoph Hellwig wrote:
> > > Otherwise is_swiotlb_buffer will return false positives when
> > > we first initia
Hi Joerg,
On 12/20/18 10:08 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This check needs to be there and got lost at some point
> during development. Add it again.
>
> Fixes: 641fb0efbff0 ('iommu/of: Don't call iommu_ops->add_device directly')
I experience a regression with those 2 patches
While debugging a DMA mapping leak, I needed to access
debug_dma_dump_mappings() but easily from user space.
This patch adds a /sys/kernel/debug/dma-api/dump file which contain all
current DMA mapping.
Signed-off-by: Corentin Labbe
---
kernel/dma/debug.c | 47 +++
On 14/01/2019 22:32, Jacob Pan wrote:
>> [...]
+/**
+ * struct iommu_fault - Generic fault data
+ *
+ * @type contains fault type
+ * @reason fault reasons if relevant outside IOMMU driver.
+ * IOMMU driver internal faults are not reported.
+ * @addr: tells the of
This is an attempt to fix an iommu exception when doing dma to the
i2c controller with EDMA. Without these mappings the smmu raises a
context fault [1] exactly with the address of the i2c data i/o reg.
This was seen on an NXP LS1043A chip while working on enabling SMMU.
[1] arm-smmu 900.iommu:
On 16/01/2019 15:27, Auger Eric wrote:
> Hi Joerg,
>
> On 12/20/18 10:08 AM, Joerg Roedel wrote:
>> From: Joerg Roedel
>>
>> This check needs to be there and got lost at some point
>> during development. Add it again.
>>
>> Fixes: 641fb0efbff0 ('iommu/of: Don't call iommu_ops->add_device directly
On Wed, Jan 16, 2019 at 04:33:51PM +, Jean-Philippe Brucker wrote:
> There is a fix on the list:
> https://www.spinics.net/lists/arm-kernel/msg698371.html
It is also in my tree already, I will send it upstream this week.
Regards,
Joerg
___
On 15/01/2019 21:27, Auger Eric wrote:
[...]
/* iommu fault flags */
-#define IOMMU_FAULT_READ 0x0
-#define IOMMU_FAULT_WRITE 0x1
+#define IOMMU_FAULT_READ (1 << 0)
+#define IOMMU_FAULT_WRITE (1 << 1)
+#define IOMMU_FAULT_EXEC (1 << 2)
On Wed, Jan 16, 2019 at 02:08:55PM +, Suthikulpanit, Suravee wrote:
> Actually, I am not sure how we would be missing the flush on the last device.
> In my test, I am seeing the flush command being issued correctly during
> vfio_unmap_unpin(), which is after all devices are detached.
> Although
On Wed, Jan 16, 2019 at 02:40:59PM +, Suthikulpanit, Suravee wrote:
> Actually, device_flush_dte(alias) should be needed regardless of this patch.
> Are you planning to add this?
Yes, I stumbled over this while writing the diff. I'll submit that as a
separate patch.
Thanks,
Joerg
___
Hi,
I made an attempt to boot Linux 5.0-rc2 as Dom0 on Xen
Arm64 and got the following splat:
[4.074264] Unable to handle kernel NULL pointer dereference at virtual
address
[4.083074] Mem abort info:
[4.085870] ESR = 0x9604
[4.089050] Exception class = DA
Hi Jean, Joerg,
On 1/16/19 5:43 PM, Joerg Roedel wrote:
> On Wed, Jan 16, 2019 at 04:33:51PM +, Jean-Philippe Brucker wrote:
>> There is a fix on the list:
>> https://www.spinics.net/lists/arm-kernel/msg698371.html
>
> It is also in my tree already, I will send it upstream this week.
OK than
On 16/01/2019 16:17, Laurentiu Tudor wrote:
This is an attempt to fix an iommu exception when doing dma to the
i2c controller with EDMA. Without these mappings the smmu raises a
context fault [1] exactly with the address of the i2c data i/o reg.
This was seen on an NXP LS1043A chip while working
On 16/01/2019 13:44, Corentin Labbe wrote:
While debugging a DMA mapping leak, I needed to access
debug_dma_dump_mappings() but easily from user space.
This patch adds a /sys/kernel/debug/dma-api/dump file which contain all
current DMA mapping.
Signed-off-by: Corentin Labbe
---
kernel/dma/de
Does this fix your problem?
diff --git a/arch/arm/include/asm/xen/page-coherent.h
b/arch/arm/include/asm/xen/page-coherent.h
index b3ef061d8b74..2c403e7c782d 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -1 +1,95 @@
+/* SPDX-License-Identi
Hi Jean,
On 1/16/19 4:52 PM, Jean-Philippe Brucker wrote:
> On 14/01/2019 22:32, Jacob Pan wrote:
>>> [...]
> +/**
> + * struct iommu_fault - Generic fault data
> + *
> + * @type contains fault type
> + * @reason fault reasons if relevant outside IOMMU driver.
> + * IOMMU d
Commit 9d3a4de4cb8d ("iommu: Disambiguate MSI region types") changed
the reserved region type in intel_iommu_get_resv_regions() from
IOMMU_RESV_RESERVED to IOMMU_RESV_MSI, but it forgot to also change
the type in intel_iommu_put_resv_regions().
This leads to a memory leak, because now the check in
Hi Gerald,
On 1/16/19 8:11 PM, Gerald Schaefer wrote:
> Commit 9d3a4de4cb8d ("iommu: Disambiguate MSI region types") changed
> the reserved region type in intel_iommu_get_resv_regions() from
> IOMMU_RESV_RESERVED to IOMMU_RESV_MSI, but it forgot to also change
> the type in intel_iommu_put_resv_re
* Allocate dma iova cookie for a domain while adding dma iommu
devices.
* Perform a stricter check for domain type parameter.
Signed-off-by: Navneet Kumar
---
drivers/iommu/tegra-smmu.c | 43 +++
1 file changed, 27 insertions(+), 16 deletions(-)
diff --gi
Use PTB_ASID instead of SMMU_CONFIG to flush smmu.
PTB_ASID can be accessed from non-secure mode, SMMU_CONFIG cannot be.
Using SMMU_CONFIG could pose a problem when kernel doesn't have secure
mode access enabled from boot.
Signed-off-by: Navneet Kumar
---
drivers/iommu/tegra-smmu.c | 2 +-
1 fil
Add support for PCI devices.
Signed-off-by: Navneet Kumar
---
drivers/iommu/tegra-smmu.c | 47 +-
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 1a44cf6..4b43c63 100644
---
Enable clients' translation only after setting up the swgroups.
Signed-off-by: Navneet Kumar
---
drivers/iommu/tegra-smmu.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index fa175d9..1a44cf6
Add support for get/put reserved regions.
Signed-off-by: Navneet Kumar
---
drivers/iommu/tegra-smmu.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 4b43c63..e848a45 100644
--- a/drivers/iommu/teg
40 matches
Mail list logo
