The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/sun50i-iommu.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index 181bb1c3437c..c349a95ec7bd 100644
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/sprd-iommu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/iommu/sprd-iommu.c b/drivers/iommu/sprd-iommu.c
index 73dfd9946312..2bc1de6e823d 100644
--- a/drivers/iommu/sprd-iommu.c
+++ b
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/rockchip-iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 9febfb7f3025..c24561f54f32 100644
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/mtk_iommu.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 6f7c69688ce2..e39a6d1da28d 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/ipmmu-vmsa.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 51ea6f00db2f..31252268f0d0 100644
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/exynos-iommu.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index d0fbf1d10e18..34085d069cda 100644
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/intel/iommu.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index dd22fc7d5176..e2add5a0caef 100644
--- a/drivers/iommu/intel/iommu.c
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 ---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 10 +++---
drivers/iommu/arm/arm-smmu/qcom_iommu.c | 8
3 files changed, 3 insertions(+), 22
The core code bakes its own cookies now.
Signed-off-by: Robin Murphy
---
drivers/iommu/amd/iommu.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 811a49a95d04..40ae7130fc80 100644
--- a/drivers/iommu/amd/iommu.c
+++ b
Now that everyone has converged on iommu-dma for IOMMU_DOMAIN_DMA
support, we can abandon the notion of drivers being responsible for the
cookie type, and consolidate all the management into the core code.
Signed-off-by: Robin Murphy
---
drivers/iommu/iommu.c | 7 +++
include/linux/iommu.h
at how straightforward it's turned out, but it
has survived some very basic smoke testing for arm-smmu using dmatest
on my Arm Juno board. Branch here for convenience:
https://gitlab.arm.com/linux-arm/linux-rm/-/tree/iommu/fq
Please let me know what you think!
Robin.
Robin Murphy (23):
iommu
On 2021-07-21 14:12, Marc Zyngier wrote:
On Wed, 21 Jul 2021 12:42:14 +0100,
Robin Murphy wrote:
[ +Marc for MSI bits ]
On 2021-07-21 02:33, Bixuan Cui wrote:
Add suspend and resume support for arm-smmu-v3 by low-power mode.
When the smmu is suspended, it is powered off and the registers
[ +Marc for MSI bits ]
On 2021-07-21 02:33, Bixuan Cui wrote:
Add suspend and resume support for arm-smmu-v3 by low-power mode.
When the smmu is suspended, it is powered off and the registers are
cleared. So saves the msi_msg context during msi interrupt initialization
of smmu. When resume
On 2021-07-21 02:50, Lu Baolu wrote:
Hi Robin,
Thanks a lot for reviewing my patch!
On 7/20/21 5:27 PM, Robin Murphy wrote:
On 2021-07-20 02:38, Lu Baolu wrote:
When the device and CPU share an address space (such as SVA), the device
must support the same addressing capability as the CPU
On 2021-07-20 02:38, Lu Baolu wrote:
When the device and CPU share an address space (such as SVA), the device
must support the same addressing capability as the CPU. The CPU does not
consider the addressing ability of any device when managing the page table
of a process, so the device must have
On 2021-07-15 17:41, Sven Peter via iommu wrote:
[...]
+ u64 sw_bypass_cpu_start;
+ u64 sw_bypass_dma_start;
+ u64 sw_bypass_len;
+
+ struct list_head streams;
I'm staring to think this could just be a bitmap, in a u16 even.
The problem is that these streams may come
-18 333
dma_addr_t limit, struct device *dev)
0db2e5d18f76a6 Robin Murphy 2015-10-01 334 {
fdbe574eb69312 Robin Murphy 2017-01-19 335 struct
iommu_dma_cookie *cookie = domain->iova_cookie;
c61a4633a56aaa Shaokun Zhang 2019-01-24
On 2021-07-16 07:24, Christoph Hellwig wrote:
On Wed, Jul 14, 2021 at 07:19:50PM +0100, Robin Murphy wrote:
Even at the DMA API level you could hide *some* of it (at the cost of
effectively only having 1/4 of the usable address space), but there are
still cases like where v4l2 has a hard
On 2021-07-16 07:33, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:45:44AM -0600, Logan Gunthorpe wrote:
@@ -194,6 +194,8 @@ static int __dma_map_sg_attrs(struct device *dev, struct
scatterlist *sg,
else
ents = ops->map_sg(dev, sg, nents, dir, attrs);
+
On 2021-07-16 07:33, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:45:44AM -0600, Logan Gunthorpe wrote:
@@ -194,6 +194,8 @@ static int __dma_map_sg_attrs(struct device *dev, struct
scatterlist *sg,
else
ents = ops->map_sg(dev, sg, nents, dir, attrs);
+
On 2021-07-16 07:33, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:45:44AM -0600, Logan Gunthorpe wrote:
@@ -194,6 +194,8 @@ static int __dma_map_sg_attrs(struct device *dev, struct
scatterlist *sg,
else
ents = ops->map_sg(dev, sg, nents, dir, attrs);
+
On 2021-07-16 07:32, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:45:42AM -0600, Logan Gunthorpe wrote:
@@ -458,7 +460,7 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
iommu_full(dev, pages << PAGE_SHIFT, dir);
for_each_sg(sg, s, nents,
On 2021-07-16 07:32, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:45:42AM -0600, Logan Gunthorpe wrote:
@@ -458,7 +460,7 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
iommu_full(dev, pages << PAGE_SHIFT, dir);
for_each_sg(sg, s, nents,
On 2021-07-16 07:32, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 10:45:42AM -0600, Logan Gunthorpe wrote:
@@ -458,7 +460,7 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
iommu_full(dev, pages << PAGE_SHIFT, dir);
for_each_sg(sg, s, nents,
On 2021-07-16 07:19, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 03:16:08PM +0100, Robin Murphy wrote:
On 2021-07-15 15:07, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 02:04:24PM +0100, Robin Murphy wrote:
If people are going to insist on calling iommu_iova_to_phys()
pointlessly
On 2021-07-15 15:07, Christoph Hellwig wrote:
On Thu, Jul 15, 2021 at 02:04:24PM +0100, Robin Murphy wrote:
If people are going to insist on calling iommu_iova_to_phys()
pointlessly and expecting it to work,
Maybe we need to fix that?
Feel free to try, but we didn't have much luck pushing
the internal callback, and any
future ones are likely to want to work with iommu-dma which relies on
iova_to_phys a fair bit, we may as well remove that currently-redundant
check as well and consider it mandatory.
Reviewed-by: Lu Baolu
Signed-off-by: Robin Murphy
---
v2: Lowered the priority of the ops
On 2021-07-15 12:11, Marc Zyngier wrote:
Hi Alex,
On Wed, 14 Jul 2021 16:48:07 +0100,
Alexandru Elisei wrote:
Hi Marc,
On 7/13/21 2:58 PM, Marc Zyngier wrote:
A number of the PMU sysregs expose reset values that are not in
compliant with the architecture (set bits in the RES0 ranges,
for
On 2021-07-15 10:44, Qu Wenruo wrote:
On 2021/7/15 下午5:28, Robin Murphy wrote:
On 2021-07-15 09:55, Qu Wenruo wrote:
Hi,
Recently I'm playing around the Nvidia Xavier AGX board, which has
VHE extension support.
In theory, considering the CPU and memory, it should be pretty
powerful
On 2021-07-15 09:55, Qu Wenruo wrote:
Hi,
Recently I'm playing around the Nvidia Xavier AGX board, which has VHE
extension support.
In theory, considering the CPU and memory, it should be pretty powerful
compared to boards like RPI CM4.
But to my surprise, KVM runs pretty poor on Xavier.
On 2021-07-15 02:38, Lu Baolu wrote:
On 7/15/21 1:28 AM, Robin Murphy wrote:
If people are going to insist on calling iommu_iova_to_phys()
pointlessly and expecting it to work, we can at least do ourselves a
favour by handling those cases in the core code, rather than repeatedly
across
On 2021-06-27 15:34, Sven Peter wrote:
[...]
In the long term, I'd like to extend the dma-iommu framework itself to
support iommu pagesizes with a larger granule than the CPU pagesize if that is
something you agree with.
BTW this isn't something we can fully support in general. IOMMU API
If people are going to insist on calling iommu_iova_to_phys()
pointlessly and expecting it to work, we can at least do ourselves a
favour by handling those cases in the core code, rather than repeatedly
across an inconsistent handful of drivers.
Signed-off-by: Robin Murphy
---
drivers/iommu/amd
On 2021-07-14 10:19, Michael Riesch wrote:
Hello Heiko,
On 7/13/21 10:49 AM, Heiko Stübner wrote:
Hi Michael,
Am Dienstag, 13. Juli 2021, 10:44:00 CEST schrieb Michael Riesch:
The HDMI TX block in the RK3568 requires two power supplies, which have
to be enabled in some cases (at least on the
On 2021-07-14 11:15, Joerg Roedel wrote:
Hi Robin,
On Fri, Jul 09, 2021 at 02:56:47PM +0100, Robin Murphy wrote:
As I mentioned before, conceptually I think this very much belongs in sysfs
as a user decision. We essentially have 4 levels of "strictness":
1: DMA domain with bounce pa
^^ Nit: the subsystem style for the subject format should be
"iommu/dart: Add..." - similarly on patch #1, which I just realised I
missed (sorry!)
On 2021-06-27 15:34, Sven Peter wrote:
Apple's new SoCs use iommus for almost all peripherals. These Device
Address Resolution Tables must be
100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -16,6 +16,7 @@ enum io_pgtable_fmt {
ARM_V7S,
ARM_MALI_LPAE,
AMD_IOMMU_V1,
+ ARM_APPLE_DART,
s/ARM_// - this is pure Apple ;)
With that fixed and hopefully a somewhat clarified comment above,
Reviewed-b
environments, check if the newly flushed region and the
gathered one are disjoint and flush if it is.
Cc: Joerg Roedel
Cc: Will Deacon
Cc: Jiajun Cao
Cc: Lu Baolu
Cc: iommu@lists.linux-foundation.org
Cc: linux-ker...@vger.kernel.org>
Cc: Robin Murphy
Signed-off-by: Nadav Amit
---
drivers
is zero, and "gather" already holds a range, so
gather->pgsize is non-zero and (gather->pgsize && gather->pgsize !=
size) is true. Therefore, again, iommu_iotlb_sync() would be called and
initialize the size.
With the caveat of one comment on the next patch...
Reviewed-by: Rob
On 2021-07-08 15:36, Doug Anderson wrote:
[...]
Or document for the users that want performance how to
change the setting, so that they can decide.
Pushing this to the users can make sense for a Linux distribution but
probably less sense for an embedded platform. So I'm happy to make
some way
On 2021-07-07 13:03, Benjamin Gaignard wrote:
Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.
Do you know what hclk_vio is and whether it's actually necessary? I
don't see any mention of it
On 2021-07-12 16:51, Alexandru Elisei wrote:
Hi Robin,
On 7/12/21 4:44 PM, Robin Murphy wrote:
On 2021-07-12 16:17, Alexandre Chartre wrote:
In a KVM guest on arm64, performance counters interrupts have an
unnecessary overhead which slows down execution when using the "perf
record&quo
On 2021-07-12 16:17, Alexandre Chartre wrote:
In a KVM guest on arm64, performance counters interrupts have an
unnecessary overhead which slows down execution when using the "perf
record" command and limits the "perf record" sampling period.
The problem is that when a guest VM disables counters
On 2021-07-08 09:08, Joerg Roedel wrote:
On Wed, Jul 07, 2021 at 01:00:13PM -0700, Doug Anderson wrote:
a) Nothing is inherently broken with my current approach.
b) My current approach doesn't make anybody terribly upset even if
nobody is totally in love with it.
Well, no, sorry :)
I don't
On 2021-07-08 09:08, Joerg Roedel wrote:
On Wed, Jul 07, 2021 at 01:00:13PM -0700, Doug Anderson wrote:
a) Nothing is inherently broken with my current approach.
b) My current approach doesn't make anybody terribly upset even if
nobody is totally in love with it.
Well, no, sorry :)
I don't
On 2021-07-09 12:43, Wei Liu wrote:
Microsoft Hypervisor provides a set of hypercalls to manage device
domains. The root kernel should parse the DMAR so that it can program
the IOMMU (with hypercalls) correctly.
The DMAR code was designed to work with Intel IOMMU only. Add two more
parameters
On 2021-07-09 12:43, Wei Liu wrote:
Microsoft Hypervisor provides a set of hypercalls to manage device
domains. The root kernel should parse the DMAR so that it can program
the IOMMU (with hypercalls) correctly.
The DMAR code was designed to work with Intel IOMMU only. Add two more
parameters
On 2021-07-09 12:43, Wei Liu wrote:
Some devices may have been claimed by the hypervisor already. One such
example is a user can assign a NIC for debugging purpose.
Ideally Linux should be able to tell retrieve that information, but
there is no way to do that yet. And designing that new
On 2021-07-09 12:43, Wei Liu wrote:
Some devices may have been claimed by the hypervisor already. One such
example is a user can assign a NIC for debugging purpose.
Ideally Linux should be able to tell retrieve that information, but
there is no way to do that yet. And designing that new
On 2021-07-09 12:04, John Garry wrote:
On 09/07/2021 11:26, Robin Murphy wrote:
n 2021-07-09 09:38, Ming Lei wrote:
Hello,
I observed that NVMe performance is very bad when running fio on one
CPU(aarch64) in remote numa node compared with the nvme pci numa node.
Please see the test result[1
On 2021-07-09 09:38, Ming Lei wrote:
Hello,
I observed that NVMe performance is very bad when running fio on one
CPU(aarch64) in remote numa node compared with the nvme pci numa node.
Please see the test result[1] 327K vs. 34.9K.
Latency trace shows that one big difference is in
On 2021-07-02 06:37, David Stevens wrote:
From: David Stevens
Add check for CONFIG_SWIOTLB to dev_is_untrusted, so that swiotlb
related code can be removed more aggressively.
Seems logical, and I think the new name is secretly the best part since
it clarifies the intent of 90% of the
On 2021-07-07 08:55, David Stevens wrote:
From: David Stevens
Add gfp flag for kalloc calls within __iommu_dma_alloc_pages, so the
function can be called from atomic contexts.
Why bother? If you need GFP_ATOMIC for allocating the pages array, then
you don't not need it for allocating the
On 2021-07-08 10:29, Joerg Roedel wrote:
Adding Robin too.
On Wed, Jul 07, 2021 at 04:55:01PM +0900, David Stevens wrote:
Add support for per-domain dynamic pools of iommu bounce buffers to the
dma-iommu API. This allows iommu mappings to be reused while still
maintaining strict iommu
On 2021-07-08 10:17, Joerg Roedel wrote:
Adding Robin.
On Fri, Jul 02, 2021 at 02:37:41PM +0900, David Stevens wrote:
From: David Stevens
Make map_swiotlb and unmap_swiotlb only for mapping, and consistently
use sync_single_for and sync_sg_for functions for swiotlb sync and arch
sync. This
On 2021-07-08 14:57, Kai-Heng Feng wrote:
On Thu, Jul 8, 2021 at 6:18 PM Robin Murphy wrote:
On 2021-07-08 10:28, Joerg Roedel wrote:
On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
@@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
iommu
On 2021-07-08 10:28, Joerg Roedel wrote:
On Thu, Jul 08, 2021 at 03:42:32PM +0800, Kai-Heng Feng wrote:
@@ -344,6 +344,9 @@ static int iommu_init_device(struct device *dev)
iommu = amd_iommu_rlookup_table[dev_data->devid];
dev_data->iommu_v2 = iommu->is_iommu_v2;
+
+
On 2021-07-06 20:12, Gerald Schaefer wrote:
On Tue, 6 Jul 2021 10:22:40 +0100
Robin Murphy wrote:
On 2021-07-05 19:52, Gerald Schaefer wrote:
The following warning occurred sporadically on s390:
DMA-API: nvme 0006:00:00.0: device driver maps memory from kernel text or
rodata [addr
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
On 2021-07-06 17:21, Kai-Heng Feng wrote:
On Tue, Jul 6, 2021 at 5:27 PM Robin Murphy wrote:
On 2021-07-06 07:51, Kai-Heng Feng wrote:
Commit 28b41e2c6aeb ("iommu: Move def_domain type check for untrusted
device into core") not only moved the check for untrusted device to
IOMMU cor
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've gone ahead
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
On 2021-07-06 07:51, Kai-Heng Feng wrote:
Commit 28b41e2c6aeb ("iommu: Move def_domain type check for untrusted
device into core") not only moved the check for untrusted device to
IOMMU core, it also introduced a behavioral change by returning
def_domain_type() directly without checking its
On 2021-07-05 19:52, Gerald Schaefer wrote:
The following warning occurred sporadically on s390:
DMA-API: nvme 0006:00:00.0: device driver maps memory from kernel text or
rodata [addr=48cc5e2f] [len=131072]
WARNING: CPU: 4 PID: 825 at kernel/dma/debug.c:1083
On 2021-07-05 16:21, Jason Gunthorpe wrote:
On Mon, Jul 05, 2021 at 02:47:36PM +0100, Robin Murphy wrote:
On 2021-07-05 11:23, Dan Carpenter wrote:
[ Ancient code, but the bug seems real enough still. -dan ]
Hello Upinder Malhi,
The patch e3cf00d0a87f: "IB/usnic: Add Cisco VIC low-
On 2021-07-05 11:23, Dan Carpenter wrote:
[ Ancient code, but the bug seems real enough still. -dan ]
Hello Upinder Malhi,
The patch e3cf00d0a87f: "IB/usnic: Add Cisco VIC low-level hardware
driver" from Sep 10, 2013, leads to the following static checker
warning:
On 2021-07-02 14:58, Will Deacon wrote:
Hi Nathan,
On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote:
On 7/1/2021 12:40 AM, Will Deacon wrote:
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
On
On 2021-07-02 04:08, Guenter Roeck wrote:
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano
On 2021-07-02 14:58, Will Deacon wrote:
Hi Nathan,
On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote:
On 7/1/2021 12:40 AM, Will Deacon wrote:
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
On
On 2021-07-02 14:58, Will Deacon wrote:
Hi Nathan,
On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote:
On 7/1/2021 12:40 AM, Will Deacon wrote:
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
On
On 2021-07-02 14:58, Will Deacon wrote:
Hi Nathan,
On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote:
On 7/1/2021 12:40 AM, Will Deacon wrote:
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
On
On 2021-07-02 14:58, Will Deacon wrote:
Hi Nathan,
On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote:
On 7/1/2021 12:40 AM, Will Deacon wrote:
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
On
On 2021-07-02 04:08, Guenter Roeck wrote:
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano
On 2021-07-02 04:08, Guenter Roeck wrote:
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano
On 2021-07-02 04:08, Guenter Roeck wrote:
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano
On 2021-07-02 04:08, Guenter Roeck wrote:
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano
On 2021-07-01 10:01, Will Deacon wrote:
On Thu, Jul 01, 2021 at 10:29:29AM +0200, Marek Szyprowski wrote:
Hi Robin,
On 30.06.2021 16:01, Robin Murphy wrote:
On 2021-06-30 14:48, Marek Szyprowski wrote:
On 30.06.2021 14:59, Will Deacon wrote:
On Wed, Jun 30, 2021 at 02:48:15PM +0200, Marek
On 2021-06-30 14:48, Marek Szyprowski wrote:
On 30.06.2021 14:59, Will Deacon wrote:
On Wed, Jun 30, 2021 at 02:48:15PM +0200, Marek Szyprowski wrote:
On 08.06.2021 18:45, Amey Narkhede wrote:
If device registration fails, remove sysfs attribute
and if setting bus callbacks fails, unregister
On 2021-06-30 05:06, Claire Chang wrote:
Factor out the debugfs bits from rmem_swiotlb_device_init() into a separate
rmem_swiotlb_debugfs_init().
Fixes: 461021875c50 ("swiotlb: Add restricted DMA pool initialization")
Reported-by: kernel test robot
Signed-off-by: Claire Chang
---
On 2021-06-30 09:56, Marc Zyngier wrote:
On Tue, 29 Jun 2021 18:34:40 +0100,
Will Deacon wrote:
On Fri, Jun 18, 2021 at 05:24:49PM +0100, Robin Murphy wrote:
Arm Fast Models are still implementing legacy virtio-pci devices behind
the SMMU, which continue to be problematic as "real har
On 2021-06-29 18:34, Will Deacon wrote:
On Fri, Jun 18, 2021 at 05:24:49PM +0100, Robin Murphy wrote:
Arm Fast Models are still implementing legacy virtio-pci devices behind
the SMMU, which continue to be problematic as "real hardware" devices
(from the point of view of the simula
On 2021-06-29 08:03, Jon Nettleton wrote:
On Mon, Jun 14, 2021 at 12:06 PM Robin Murphy wrote:
On 2021-05-24 12:02, Shameer Kolothum wrote:
From: Jon Nettleton
Check if there is any RMR info associated with the devices behind
the SMMU and if any, install bypass SMRs for them
On 2021-06-29 13:16, Claire Chang wrote:
Remove the ifdef to fix implicit function declaration for other pools.
Fixes: 1d9f94400a7a ("swiotlb: Refactor swiotlb_create_debugfs")
There doesn't appear to be a problem with that commit - AFAICS it's
461021875c50 ("swiotlb: Add restricted DMA pool
On 2021-06-28 11:48, Steven Price wrote:
On 25/06/2021 10:49, Chunyou Tang wrote:
Hi Steve,
Thinks for your reply.
When I only set the pte |= ARM_LPAE_PTE_SH_NS;there have no "GPU
Fault",When I set the pte |= ARM_LPAE_PTE_SH_IS(or
ARM_LPAE_PTE_SH_OS);there have "GPU Fault".I
On 2021-06-27 09:47, Andy Yan wrote:
When iommu itself is disabled in dts, we should
fallback to non-iommu buffer, check iommu parent
is meanless here.
Signed-off-by: Andy Yan
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr
Hi Andrey,
On 2021-06-24 17:19, Andrey Grodzovsky via iommu wrote:
Hello,
We are testing AMD GPU removal from PCI topology using sysfs 'remove'
hook. We encountered a crash in IOMMU code related to double free.
Note that the crash happens without even loading AMD graphic driver -
amdgpu. The
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced
1001 - 1100 of 7734 matches
Mail list logo
