On 07/07/2022 21:35, Martin K. Petersen wrote:
Christoph,
Yes, I've mostly been waiting for an ACK from Martin.
Sorry, I'm on vacation this week. The series looks OK to me although I
do agree that it would be great if the max was reflected in the queue's
hard limit and opt in the soft limit.
On 30/06/2022 13:08, John Garry wrote:
Hi Christoph,
Can you please consider picking up this series? A few things to note
beforehand:
- I changed to only apply the mapping limit to SAS hosts in this
version. I would need a fresh ack from Martin for those SCSI parts, but
wanted to make sure
On 06/07/2022 13:00, Will Deacon wrote:
On Mon, Apr 04, 2022 at 07:27:10PM +0800, John Garry wrote:
Function iommu_group_store_type() supports changing the default domain
of an IOMMU group.
Many conditions need to be satisfied and steps taken for this action to be
successful.
Satisfying these
On 01/07/2022 04:56, Feng Tang wrote:
inclination.
ok, what you are saying sounds reasonable. I just remember that when we
analyzed the longterm aging issue that we concluded that the FQ size and its
relation to the magazine size was a factor and this change makes me a little
worried about new
On 01/07/2022 00:49, Damien Le Moal wrote:
+ if (dma_dev) {
+ shost->max_sectors = min_t(unsigned int, shost->max_sectors,
+ dma_opt_mapping_size(dma_dev) >> SECTOR_SHIFT);
+ }
Hi Damien,
> Hmm... shost->max_sectors becomes the max_hw_sector
On 01/07/2022 00:41, Damien Le Moal wrote:
shost->dma_dev = dma_dev;
+ if (dma_dev->dma_mask) {
+ shost->max_sectors = min_t(unsigned int, shost->max_sectors,
+ dma_max_mapping_size(dma_dev) >> SECTOR_SHIFT);
+ }
Nit: you could remove th
to shost limits, which includes host DMA mapping limits.
Cap the ata_device max_sectors according to shost->max_sectors to respect
this shost limit.
Signed-off-by: John Garry
Acked-by: Damien Le Moal
---
drivers/ata/libata-scsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
max_sectors from
dma_opt_mapping_size(), which knows this mapping limit.
Signed-off-by: John Garry
---
drivers/scsi/scsi_transport_sas.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/scsi/scsi_transport_sas.c
b/drivers/scsi/scsi_transport_sas.c
index 12bff64dade6..1b45248748e0 100644
The shost->max_sectors is repeatedly capped according to the host DMA
mapping limit for each sdev in __scsi_init_queue(). This is unnecessary, so
set only once when adding the host.
Signed-off-by: John Garry
---
drivers/scsi/hosts.c| 5 +
drivers/scsi/scsi_lib.c | 4
2 fi
may be quite slow.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
Acked-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 6 ++
drivers/iommu/iova.c | 5 +
include/linux/iova.h | 2 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers
for device drivers to know this "optimal" limit, such that
they may try to produce mapping which don't exceed it.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
---
Documentation/core-api/dma-api.rst | 14 ++
include/linux/dma-map-ops.h| 1 +
include/linu
ctors only once when
adding" is a subset of a previous patch I did not transfer the RB tags
- Rebase on v5.19-rc4
John Garry (5):
dma-mapping: Add dma_opt_mapping_size()
dma-iommu: Add iommu_dma_opt_mapping_size()
scsi: core: Cap shost max_sectors according to DMA limits o
[ 4.319253] iommu: Adding device :06:00.2 to group 5
[ 4.325869] iommu: Adding device :20:01.0 to group 15
[ 4.332648] iommu: Adding device :20:02.0 to group 16
[ 4.338946] swapper/0 invoked oom-killer:
gfp_mask=0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null
On 30/06/2022 10:02, Robin Murphy wrote:
On 2022-06-30 08:33, Feng Tang wrote:
kmalloc will round up the request size to power of 2, and current
iova_magazine's size is 1032 (1024+8) bytes, so each instance
allocated will get 2048 bytes from kmalloc, causing around 1KB
waste.
And in some exstre
On 28/06/2022 12:27, John Garry via iommu wrote:
On 28/06/2022 12:23, Robin Murphy wrote:
+
+ size_t
+ dma_opt_mapping_size(struct device *dev);
+
+Returns the maximum optimal size of a mapping for the device.
Mapping large
+buffers may take longer so device drivers are advised to limit
On 29/06/2022 06:58, Damien Le Moal wrote:
On 6/29/22 14:40, Christoph Hellwig wrote:
On Tue, Jun 28, 2022 at 12:33:58PM +0100, John Garry wrote:
Well Christoph originally offered to take this series via the dma-mapping
tree.
@Christoph, is that still ok with you? If so, would you rather I
On 28/06/2022 10:14, Damien Le Moal wrote:
BTW, this patch has no real dependency on the rest of the series, so
could be taken separately if you prefer.
Sure, you can send it separately. Adding it through the scsi tree is fine too.
Well Christoph originally offered to take this series via the
On 28/06/2022 12:23, Robin Murphy wrote:
+
+ size_t
+ dma_opt_mapping_size(struct device *dev);
+
+Returns the maximum optimal size of a mapping for the device. Mapping
large
+buffers may take longer so device drivers are advised to limit total DMA
+streaming mappings length to the return
On 28/06/2022 00:24, Damien Le Moal wrote:
On 6/28/22 00:25, John Garry wrote:
ATA devices (struct ata_device) have a max_sectors field which is
configured internally in libata. This is then used to (re)configure the
associated sdev request queue max_sectors value from how it is earlier set
in
to shost limits, which includes host DMA mapping limits.
Cap the ata_device max_sectors according to shost->max_sectors to respect
this shost limit.
Signed-off-by: John Garry
Acked-by: Damien Le Moal
---
drivers/ata/libata-scsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
max_sectors from
dma_opt_mapping_size(), which knows this mapping limit.
Signed-off-by: John Garry
---
drivers/scsi/scsi_transport_sas.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/scsi/scsi_transport_sas.c
b/drivers/scsi/scsi_transport_sas.c
index 12bff64dade6..1b45248748e0 100644
may be quite slow.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
---
drivers/iommu/dma-iommu.c | 6 ++
drivers/iommu/iova.c | 5 +
include/linux/iova.h | 2 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index
The shost->max_sectors is repeatedly capped according to the host DMA
mapping limit for each sdev in __scsi_init_queue(). This is unnecessary, so
set only once when adding the host.
Signed-off-by: John Garry
---
drivers/scsi/hosts.c| 5 +
drivers/scsi/scsi_lib.c | 4
2 fi
for device drivers to know this "optimal" limit, such that
they may try to produce mapping which don't exceed it.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
---
Documentation/core-api/dma-api.rst | 9 +
include/linux/dma-map-ops.h| 1 +
include/linu
added Martin's tag to the SCSI patch
John Garry (5):
dma-mapping: Add dma_opt_mapping_size()
dma-iommu: Add iommu_dma_opt_mapping_size()
scsi: core: Cap shost max_sectors according to DMA mapping limits only
once
scsi: scsi_transport_sas: Cap shost max_sectors according to DMA
o
On 14/06/2022 14:12, John Garry wrote:
On 06/06/2022 10:30, John Garry wrote:
Add the IOMMU callback for DMA mapping API dma_opt_mapping_size(), which
allows the drivers to know the optimal mapping limit and thus limit the
requested IOVA lengths.
This value is based on the IOVA rcache range
On 10/06/2022 16:37, John Garry via iommu wrote:
On 6/9/22 10:54, John Garry wrote:
ok, but do you have a system where the UFS host controller is behind
an IOMMU? I had the impression that UFS controllers would be mostly
found in embedded systems and IOMMUs are not as common on there
On 06/06/2022 10:30, John Garry wrote:
Add the IOMMU callback for DMA mapping API dma_opt_mapping_size(), which
allows the drivers to know the optimal mapping limit and thus limit the
requested IOVA lengths.
This value is based on the IOVA rcache range limit, as IOVAs allocated
above this limit
On 09/06/2022 21:34, Bart Van Assche wrote:
On 6/9/22 10:54, John Garry wrote:
ok, but do you have a system where the UFS host controller is behind
an IOMMU? I had the impression that UFS controllers would be mostly
found in embedded systems and IOMMUs are not as common on there.
Modern
p-focused distro configs are likely to want to turn
it back on for maximum compatibility.
Signed-off-by: Robin Murphy
FWIW,
Reviewed-by: John Garry
If we're not enabling by default for x86 then doesn't Jeorg have some
XHCI issue which we would now need to quirk? I don't rememb
On 09/06/2022 18:18, Bart Van Assche wrote:
SCSI host bus adapters that support 64-bit DMA may support much
larger transfer sizes than 128 KiB.
Indeed, and that is my problem today, as my storage controller is
generating DMA mapping lengths which exceeds 128K and they slow
everything down.
On 08/06/2022 22:07, Bart Van Assche wrote:
On 6/8/22 10:50, John Garry wrote:
Please note that this limit only applies if we have an IOMMU enabled
for the scsi host dma device. Otherwise we are limited by dma direct
or swiotlb max mapping size, as before.
SCSI host bus adapters that support
On 08/06/2022 18:33, Bart Van Assche wrote:
On 6/6/22 02:30, John Garry wrote:
+ if (dma_dev->dma_mask) {
+ shost->max_sectors = min_t(unsigned int, shost->max_sectors,
+ dma_opt_mapping_size(dma_dev) >> SECTOR_SHIFT);
+ }
Since IOVA_RANGE_CACHE_MA
On 08/06/2022 18:26, Bart Van Assche wrote:
On 6/6/22 02:30, John Garry via iommu wrote:
+unsigned long iova_rcache_range(void)
+{
+ return PAGE_SIZE << (IOVA_RANGE_CACHE_MAX_SIZE - 1);
+}
My understanding is that iova cache entries may be smaller than
IOVA_RANGE_CACHE_MAX_SIZE and
On 07/06/2022 23:43, Bart Van Assche wrote:
On 6/6/22 02:30, John Garry wrote:
As reported in [0], DMA mappings whose size exceeds the IOMMU IOVA
caching
limit may see a big performance hit.
This series introduces a new DMA mapping API, dma_opt_mapping_size(), so
that drivers may know this
to shost limits, which includes host DMA mapping limits.
Cap the ata_device max_sectors according to shost->max_sectors to respect
this shost limit.
Signed-off-by: John Garry
Acked-by: Damien Le Moal
---
drivers/ata/libata-scsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
max_sectors from
dma_opt_mapping_size(), which knows this mapping limit.
In addition, the shost->max_sectors is repeatedly set for each sdev in
__scsi_init_queue(). This is unnecessary, so set once when adding the
host.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
Reviewed-by: Martin K. Peter
may be quite slow.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
---
drivers/iommu/dma-iommu.c | 6 ++
drivers/iommu/iova.c | 5 +
include/linux/iova.h | 2 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index
for device drivers to know this "optimal" limit, such that
they may try to produce mapping which don't exceed it.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
---
Documentation/core-api/dma-api.rst | 9 +
include/linux/dma-map-ops.h| 1 +
include/linu
/4 (thanks)
Changes since v1:
- Relocate scsi_add_host_with_dma() dma_dev check (Reported by Dan)
- Add tags from Damien and Martin (thanks)
- note: I only added Martin's tag to the SCSI patch
John Garry (4):
dma-mapping: Add dma_opt_mapping_size()
dma-iommu: Add iommu_dma_opt_mappin
to shost limits, which includes host DMA mapping limits.
Cap the ata_device max_sectors according to shost->max_sectors to respect
this shost limit.
Signed-off-by: John Garry
Acked-by: Damien Le Moal
---
drivers/ata/libata-scsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
max_sectors from
dma_opt_mapping_size(), which knows this mapping limit.
In addition, the shost->max_sectors is repeatedly set for each sdev in
__scsi_init_queue(). This is unnecessary, so set once when adding the
host.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
Reviewed-by: Martin K. Peter
may be quite slow.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 6 ++
drivers/iommu/iova.c | 5 +
include/linux/iova.h | 2 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 09f6e1c0f9c0..f619e41b9172 100644
l.org/linux-iommu/f5b78c9c-312e-70ab-ecbb-f14623a4b...@arm.com/
Changes since v1:
- Relocate scsi_add_host_with_dma() dma_dev check (Reported by Dan)
- Add tags from Damien and Martin (thanks)
- note: I only added Martin's tag to the SCSI patch
John Garry (4):
dma-mapping: Add dma_opt_ma
for device drivers to know this "optimal" limit, such that
they may try to produce mapping which don't exceed it.
Signed-off-by: John Garry
Reviewed-by: Damien Le Moal
---
Documentation/core-api/dma-api.rst | 9 +
include/linux/dma-map-ops.h| 1 +
include/linu
On 22/05/2022 23:22, Damien Le Moal wrote:
On 2022/05/22 22:13, Christoph Hellwig wrote:
The whole series looks fine to me. I'll happily queue it up in the
dma-mapping tree if the SCSI and ATA maintainers are ok with that.
Fine with me. I sent an acked-by for the libata bit.
Thanks, I'm g
shost->cmd_per_lun,
ea2f0f77538c50 John Garry2021-05-19 226
shost->can_queue);
ea2f0f77538c50 John Garry2021-05-19 227
2ad7ba6ca08593 John Garry2022-05-20 @228if (dma_d
On 21/05/2022 00:33, Damien Le Moal wrote:
Hi Damien,
+unsigned long iova_rcache_range(void)
Why not a size_t return type ?
The IOVA code generally uses unsigned long for size/range while
dam-iommu uses size_t as appropiate, so I'm just sticking to that.
+{
+ return PAGE_SIZE <<
On 21/05/2022 00:30, Damien Le Moal wrote:
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index f69b77cbf538..a3ae6345473b 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -225,6 +225,11 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, struct
device *dev,
s
to shost limits, which includes host DMA mapping limits.
Cap the ata_device max_sectors according to shost->max_sectors to respect
this shost limit.
Signed-off-by: John Garry
---
drivers/ata/libata-scsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-scsi.c b/driv
max_sectors from
dma_opt_mapping_size(), which knows this mapping limit.
In addition, the shost->max_sectors is repeatedly set for each sdev in
__scsi_init_queue(). This is unnecessary, so set once when adding the
host.
Signed-off-by: John Garry
---
drivers/scsi/hosts.c| 5 +
drivers/s
may be quite slow.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c | 6 ++
drivers/iommu/iova.c | 5 +
include/linux/iova.h | 2 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 09f6e1c0f9c0..f619e41b9172 100644
use this limit.
I also added a patch for libata-scsi as it does not currently honour the
shost max_sectors limit.
[0]
https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leiz...@huawei.com/
[1]
https://lore.kernel.org/linux-iommu/f5b78c9c-312e-70ab-ecbb-f14623a4b...@arm.com/
for device drivers to know this "optimal" limit, such that
they may try to produce mapping which don't exceed it.
Signed-off-by: John Garry
---
Documentation/core-api/dma-api.rst | 9 +
include/linux/dma-map-ops.h| 1 +
include/linux/dma-mapping.h| 5 ++
On 18/05/2022 18:36, Robin Murphy wrote:
For devices stuck behind a conventional PCI bus, saving extra cycles at
33MHz is probably fairly significant. However since native PCI Express
is now the norm for high-performance devices, the optimisation to always
prefer 32-bit addresses for the sake of
On 17/05/2022 13:02, Robin Murphy wrote:
Indeed, sorry but NAK for this being nonsense. As I've said at least
once before, if the unnecessary SAC address allocation attempt slows
down your workload, make it not do that in the first place. If you
don't like the existing command-line parameter
On 17/05/2022 11:40, Robin Murphy wrote:
On 2022-05-16 14:06, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len
regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
Add the IOMMU callback for DMA mapping
On 17/05/2022 09:38, Christoph Hellwig wrote:
On Mon, May 16, 2022 at 09:06:01PM +0800, John Garry wrote:
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
Add the IOMMU
On 17/05/2022 09:09, Yicong Yang wrote:
+ target = cpumask_any(cpumask_of_node(dev_to_node(&hisi_ptt->pdev->dev)));
+ if (target < nr_cpumask_bits) {
the comment for cpumask_any() hints to check against nr_cpu_ids - any specific
reason to check against nr_cpumask_bits?
here should be:
On 16/05/2022 13:52, Yicong Yang wrote:
As requested before, please mention "perf tool" in the commit subject
From: Qi Liu
Use find_pmu_for_event() to simplify logic in auxtrace_record__init().
Signed-off-by: Qi Liu
Signed-off-by: Yicong Yang
---
tools/perf/arch/arm/util/auxtrace.c | 53
: John Garry
---
drivers/hwtracing/ptt/hisi_ptt.c | 157 +++
drivers/hwtracing/ptt/hisi_ptt.h | 23 +
2 files changed, 180 insertions(+)
diff --git a/drivers/hwtracing/ptt/hisi_ptt.c b/drivers/hwtracing/ptt/hisi_ptt.c
index ef25ce98f664..c3fdb9bfb1b4 100644
-by: John Garry
---
drivers/Makefile | 1 +
drivers/hwtracing/Kconfig| 2 +
drivers/hwtracing/ptt/Kconfig| 12 +
drivers/hwtracing/ptt/Makefile | 2 +
drivers/hwtracing/ptt/hisi_ptt.c | 964 +++
drivers/hwtracing/ptt
__scsi_init_queue() - which
will limit the total SGL length the driver tries to map and in turn limits
IOVA lengths requested.
[0]
https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leiz...@huawei.com/
Signed-off-by: John Garry
---
Sending as an RFC as iommu_dma_max_mapping_size
ng Yang
FWIW,
Reviewed-by: John Garry
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 627a3ed5ee8f..5ec15ae2a9b1 100644
---
On 12/04/2022 08:41, Yicong Yang wrote:
+ hisi_ptt_pmus = zalloc(sizeof(struct perf_pmu *) * (*nr_ptts));
+ if (!hisi_ptt_pmus) {
+ pr_err("hisi_ptt alloc failed\n");
+ *err = -ENOMEM;
using PTR_ERR seems better, if possible
ok will change to that. *err = -ENOMEM is used he
+static int hisi_ptt_alloc_trace_buf(struct hisi_ptt *hisi_ptt)
+{
+ struct hisi_ptt_trace_ctrl *ctrl = &hisi_ptt->trace_ctrl;
+ struct device *dev = &hisi_ptt->pdev->dev;
+ int i;
+
+ hisi_ptt->trace_ctrl.buf_index = 0;
+
+ /* If the trace buffer has already been allocated, zero it
On 07/04/2022 13:58, Yicong Yang wrote:
From: Qi Liu
'perf record' and 'perf report --dump-raw-trace' supported in this
patch.
Example usage:
Output will contain raw PTT data and its textual representation, such
as:
0 0 0x5810 [0x30]: PERF_RECORD_AUXTRACE size: 0x40 offset: 0
ref: 0xa5d
On 07/04/2022 13:58, Yicong Yang wrote:
HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated
Endpoint(RCiEP) device, providing the capability to dynamically monitor and
tune the PCIe traffic, and trace the TLP headers.
Add the driver for the device to enable the trace func
On 07/04/2022 09:21, Leizhen (ThunderTown) wrote:
On 2022/4/4 19:27, John Garry wrote:
Add support to allow the maximum optimised DMA len be set for an IOMMU
group via sysfs.
This is much the same with the method to change the default domain type
for a group.
Signed-off-by: John Garry
On 07/04/2022 09:27, Leizhen (ThunderTown) wrote:
Thanks for having a look
On 2022/4/4 19:27, John Garry wrote:
Add max opt argument to iova_domain_init_rcaches(), and use it to set the
rcaches range.
Also fix up all users to set this value (at 0, meaning use default),
including a
opt DMA size.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c| 15 ++-
drivers/iommu/iova.c | 19 ---
drivers/vdpa/vdpa_user/iova_domain.c | 4 ++--
include/linux/iova.h | 3 ++-
4 files changed, 34 insertions
Add support to allow the maximum optimised DMA len be set for an IOMMU
group via sysfs.
This is much the same with the method to change the default domain type
for a group.
Signed-off-by: John Garry
---
.../ABI/testing/sysfs-kernel-iommu_groups | 16 +
drivers/iommu/iommu.c
Allow iommu_change_dev_def_domain() to create a new default domain, keeping
the same as current.
Also remove comment about the function purpose, which will become stale.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 49 ++-
include/linux/iommu.h
y.
Delete macro IOVA_RANGE_CACHE_MAX_SIZE in case it's reused by mistake.
[0]
https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leiz...@huawei.com/
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 20 ++--
include/linux/iova.h | 3 +++
2 files changed
ge
- Combine last 2x patches
[0]
https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leiz...@huawei.com/
[1]
https://lore.kernel.org/linux-iommu/1607538189-237944-1-git-send-email-john.ga...@huawei.com/
John Garry (5):
iommu: Refactor iommu_group_store_type()
iova: Allow rcache range u
common part and a part specific
to update the IOMMU group attribute.
No functional change intended.
Some code comments are tidied up also.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 96 ---
1 file changed, 62 insertions(+), 34 deletions(-)
diff
+
endmenu
diff --git a/drivers/hwtracing/ptt/Kconfig b/drivers/hwtracing/ptt/Kconfig
new file mode 100644
index ..8902a6f27563
--- /dev/null
+++ b/drivers/hwtracing/ptt/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config HISI_PTT
+ tristate "HiSilicon P
On 08/03/2022 08:49, Yicong Yang wrote:
The DMA of HiSilicon PTT device can only work with identical mapping.
nit: I'd have "DMA operations of the HiSilicon PTT device can only work
properly with identity mappings".
So add a quirk for the device to force the domain passthrough.
".. domain
On 04/03/2022 04:46, yf.wang--- via iommu wrote:
* MEDIATEK Confidentiality Notice
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws.
On 14/02/2022 17:29, John Garry wrote:
Hi guys,
And a friendly reminder on this series also.
Cheers,
john
For streaming DMA mappings involving an IOMMU and whose IOVA len regularly
exceeds the IOVA rcache upper limit (meaning that they are not cached),
performance can be reduced.
This may
On 18/02/2022 16:28, John Garry wrote:
Hi guys,
A friendly reminder on this one.
Cheers,
john
Now that the FQ code has been moved to dma-iommu.c and also the rcache-
related structures have been brought into iova.c, let's rearrange the code
to remove all the forward declarations.
On 24/02/2022 03:53, Yicong Yang wrote:
On 2022/2/22 19:06, John Garry wrote:
On 21/02/2022 08:43, Yicong Yang wrote:
HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex
integrated Endpoint(RCiEP) device, providing the capability
to dynamically monitor and tune the PCIe traffic
+
static irqreturn_t hisi_ptt_irq(int irq, void *context)
{
struct hisi_ptt *hisi_ptt = context;
@@ -169,7 +233,7 @@ static irqreturn_t hisi_ptt_irq(int irq, void *context)
if (!(status & HISI_PTT_TRACE_INT_STAT_MASK))
return IRQ_NONE;
- return IRQ_HANDLED
On 21/02/2022 08:43, Yicong Yang wrote:
HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex
integrated Endpoint(RCiEP) device, providing the capability
to dynamically monitor and tune the PCIe traffic, and trace
the TLP headers.
Add the driver for the device to enable the trace func
nctional change intended.
Signed-off-by: John Garry
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 7e9c3a97c040..d543131025b3 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -17,75 +17,40 @@
#define IOVA_RANGE_CACHE_MAX_SIZE 6/* log of max cached IOVA range
opt DMA size.
Signed-off-by: John Garry
---
drivers/iommu/dma-iommu.c| 15 ++-
drivers/iommu/iova.c | 19 ---
drivers/vdpa/vdpa_user/iova_domain.c | 4 ++--
include/linux/iova.h | 3 ++-
4 files changed, 34 insertions
Add support to allow the maximum optimised DMA len be set for an IOMMU
group via sysfs.
This is much the same with the method to change the default domain type
for a group.
Signed-off-by: John Garry
---
.../ABI/testing/sysfs-kernel-iommu_groups | 16 +
drivers/iommu/iommu.c
Allow iommu_change_dev_def_domain() to create a new default domain, keeping
the same as current.
Also remove comment about the function purpose, which will become stale.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 49 ++-
include/linux/iommu.h
y.
Delete macro IOVA_RANGE_CACHE_MAX_SIZE in case it's reused by mistake.
[0]
https://lore.kernel.org/linux-iommu/20210129092120.1482-1-thunder.leiz...@huawei.com/
Signed-off-by: John Garry
---
drivers/iommu/iova.c | 20 ++--
include/linux/iova.h | 3 +++
2 files changed
common part and a part specific
to update the IOMMU group attribute.
No functional change intended.
Some code comments are tidied up also.
Signed-off-by: John Garry
---
drivers/iommu/iommu.c | 96 ---
1 file changed, 62 insertions(+), 34 deletions(-)
diff
3063345-mutt-send-email-...@kernel.org/T/#m5b2b59576d35cad544314470f32e5f40ac5d1fe9
John Garry (5):
iommu: Refactor iommu_group_store_type()
iova: Allow rcache range upper limit to be flexible
iommu: Allow iommu_change_dev_def_domain() realloc same default domain
type
iommu: Allow max opt DMA len be set for a group vi
On 03/02/2022 11:34, Michael S. Tsirkin wrote:
On Thu, Feb 03, 2022 at 05:59:20PM +0800, John Garry wrote:
Currently the rcache structures are allocated for all IOVA domains, even if
they do not use "fast" alloc+free interface. This is wasteful of memory.
In addition
On 08/02/2022 11:21, Yicong Yang wrote:
This patch should be earlier in the series, before the PTT driver, and the
comment on hisi_ptt_check_iommu_mapping() should mention what is going on here.
ok I'll reorder the serives and modify the comments of
hisi_ptt_check_iommu_mapping() like:
/*
On 24/01/2022 13:11, Yicong Yang wrote:
The DMA of HiSilicon PTT device can only work with identical
mapping. So add a quirk for the device to force the domain
passthrough.
This patch should be earlier in the series, before the PTT driver, and
the comment on hisi_ptt_check_iommu_mapping() shou
On 24/01/2022 13:11, Yicong Yang wrote:
HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex
integrated Endpoint(RCiEP) device, providing the capability
to dynamically monitor and tune the PCIe traffic, and trace
the TLP headers.
Add the driver for the device to enable the trace func
eviewed-by: Christoph Hellwig
Reviewed-by: John Garry
BTW, It looks like we can get rid of iommu_ops.dev_has_feat also.
It does not seem to be called, while arm-smmu-v3 driver does provide a
callback.
---
include/linux/iommu.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
di
On 07/02/2022 06:41, Lu Baolu wrote:
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 583ec0fa4ac1..e8d58654361c 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -3348,9 +3348,6 @@ static inline int iommu_devinfo_cache_init(void)
static i
separate rcache init explicitly, which includes
error checking.
Signed-off-by: John Garry
---
Differences to v1:
- Drop stubs for iova_domain_init_rcaches() and iova_domain_free_rcaches()
- Use put_iova_domain() in vdpa code
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d85d54
On 31/01/2022 16:17, Joerg Roedel wrote:
From: Joerg Roedel
The polling loop for the register change in iommu_ga_log_enable() needs
to have a udelay() in it. Otherwise the CPU might be faster than the
IOMMU hardware and wrongly trigger the WARN_ON() further down the code
stream.
Fixes: 8bda0c
On 26/01/2022 17:00, Robin Murphy wrote:
As above, I vote for just forward-declaring the free routine in iova.c
and keeping it entirely private.
BTW, speaking of forward declarations, it's possible to remove all the
forward declarations in iova.c now that the FQ code is gone - but with a
good
1 - 100 of 545 matches
Mail list logo
