2018-12-03 21:20:52 |
dann frazier |
bug |
|
|
added bug |
2018-12-14 21:04:54 |
dann frazier |
nominated for series |
|
Ubuntu Bionic |
|
2018-12-14 21:04:54 |
dann frazier |
bug task added |
|
linux (Ubuntu Bionic) |
|
2018-12-14 21:04:54 |
dann frazier |
nominated for series |
|
Ubuntu Disco |
|
2018-12-14 21:04:54 |
dann frazier |
bug task added |
|
linux (Ubuntu Disco) |
|
2018-12-14 21:04:54 |
dann frazier |
nominated for series |
|
Ubuntu Cosmic |
|
2018-12-14 21:04:54 |
dann frazier |
bug task added |
|
linux (Ubuntu Cosmic) |
|
2018-12-14 21:05:09 |
dann frazier |
linux (Ubuntu Cosmic): assignee |
|
dann frazier (dannf) |
|
2018-12-14 21:05:11 |
dann frazier |
linux (Ubuntu Bionic): assignee |
|
dann frazier (dannf) |
|
2018-12-19 03:37:42 |
dann frazier |
description |
[Impact]
There's a significant performance gain to be had by removing the need to flush the IOMMU TLB on every unmap. I'm seeing a 25% performance gain w/ fio reads on a single NVMe device. This mode of operation is available for x86 via the "intel_iommu=strict" parameter. This support is now available upstream for ARM platforms via the "iommu.strict=[0|1]" parameter, while keeping the default in strict mode.
[Test Case]
$ cat fio.rc
[global]
rw=read
direct=1
ioengine=libaio
iodepth=2048
numjobs=10
bs=4k
group_reporting=1
group_reporting=1
cpumask=0xff
runtime=100
loops = 10000
[job1]
filename=/dev/nvme0n1
[Fix]
44f6876a00e83 iommu/arm-smmu: Support non-strict mode
b2dfeba654cb0 iommu/io-pgtable-arm-v7s: Add support for non-strict mode
9662b99a19abc iommu/arm-smmu-v3: Add support for non-strict mode
b6b65ca20bc93 iommu/io-pgtable-arm: Add support for non-strict mode
68a6efe86f6a1 iommu: Add "iommu.strict" command line option
2da274cdf998a iommu/dma: Add support for non-strict mode
07fdef34d2be6 iommu/arm-smmu-v3: Implement flush_iotlb_all hook
85c7a0f1ef624 iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
[Regression Risk] |
[Impact]
The Intel IOMMU driver provides an option for strict mode. When disabled, batching of IOTLB flush operations is permitted, allowing the user to trade-off isolation for improved performance. Ubuntu's kernel currently lacks a parity for this feature for ARM.
There's a significant performance gain to be had by removing the need to flush the IOMMU TLB on every unmap on arm64. I'm seeing a 25% performance gain w/ fio reads on a single NVMe device.
This mode of operation is available for x86 via the "intel_iommu=strict" parameter. Upstream now exposes an equivalent feature for ARM platforms via the "iommu.strict=[0|1]" parameter, while retaining the default strict-enabled mode.
[Test Case]
$ cat fio.rc
[global]
rw=read
direct=1
ioengine=libaio
iodepth=2048
numjobs=10
bs=4k
group_reporting=1
group_reporting=1
cpumask=0xff
runtime=100
loops = 10000
[job1]
filename=/dev/nvme0n1
[Fix]
44f6876a00e83 iommu/arm-smmu: Support non-strict mode
b2dfeba654cb0 iommu/io-pgtable-arm-v7s: Add support for non-strict mode
9662b99a19abc iommu/arm-smmu-v3: Add support for non-strict mode
b6b65ca20bc93 iommu/io-pgtable-arm: Add support for non-strict mode
68a6efe86f6a1 iommu: Add "iommu.strict" command line option
2da274cdf998a iommu/dma: Add support for non-strict mode
07fdef34d2be6 iommu/arm-smmu-v3: Implement flush_iotlb_all hook
85c7a0f1ef624 iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
[Regression Risk]
Most of these patches are specific to ARM, and have been regression tested on both arm64 (HiSilicon D06) and armhf (QEMU virt) using "stress-ng --vm $(nproc)"
2 patches do touch arch-indep code however:
> 68a6efe86f6a1 iommu: Add "iommu.strict" command line option
Adds a new command line option and sets an attribute that iommu drivers can optionally react to. Doesn't change default behavior.
> 2da274cdf998a iommu/dma: Add support for non-strict mode
This driver is only built for arm64 and ppc64el (determined by looking at the build logs). Most of this patch only changes behavior in the non-default (and new) iommu.strict=0 case. The exception, which is called out in the commit message, is this hunk:
- WARN_ON(iommu_unmap(domain, dma_addr, size) != size);
+ WARN_ON(iommu_unmap_fast(domain, dma_addr, size) != size);
+ if (!cookie->fq_domain)
+ iommu_tlb_sync(domain);
In the default case, where fq_domain will be NULl, we are now factoring iommu_unmap() into:
iommu_unmap_fast()
iommu_tlb_sync()
Looking at the source to iommu_unmap() confirms that this is functionally equivalent. |
|
2018-12-19 15:35:05 |
dann frazier |
linux (Ubuntu Cosmic): status |
New |
In Progress |
|
2018-12-21 20:12:34 |
dann frazier |
linux (Ubuntu Bionic): status |
New |
In Progress |
|
2019-01-09 13:58:39 |
Seth Forshee |
linux (Ubuntu Disco): status |
In Progress |
Fix Committed |
|
2019-01-11 10:51:30 |
Kleber Sacilotto de Souza |
linux (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
2019-01-11 11:08:34 |
Kleber Sacilotto de Souza |
linux (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
2019-01-15 10:32:51 |
Brad Figg |
tags |
|
verification-needed-cosmic |
|
2019-01-15 10:37:02 |
Brad Figg |
tags |
verification-needed-cosmic |
verification-needed-bionic verification-needed-cosmic |
|
2019-01-16 20:52:49 |
dann frazier |
description |
[Impact]
The Intel IOMMU driver provides an option for strict mode. When disabled, batching of IOTLB flush operations is permitted, allowing the user to trade-off isolation for improved performance. Ubuntu's kernel currently lacks a parity for this feature for ARM.
There's a significant performance gain to be had by removing the need to flush the IOMMU TLB on every unmap on arm64. I'm seeing a 25% performance gain w/ fio reads on a single NVMe device.
This mode of operation is available for x86 via the "intel_iommu=strict" parameter. Upstream now exposes an equivalent feature for ARM platforms via the "iommu.strict=[0|1]" parameter, while retaining the default strict-enabled mode.
[Test Case]
$ cat fio.rc
[global]
rw=read
direct=1
ioengine=libaio
iodepth=2048
numjobs=10
bs=4k
group_reporting=1
group_reporting=1
cpumask=0xff
runtime=100
loops = 10000
[job1]
filename=/dev/nvme0n1
[Fix]
44f6876a00e83 iommu/arm-smmu: Support non-strict mode
b2dfeba654cb0 iommu/io-pgtable-arm-v7s: Add support for non-strict mode
9662b99a19abc iommu/arm-smmu-v3: Add support for non-strict mode
b6b65ca20bc93 iommu/io-pgtable-arm: Add support for non-strict mode
68a6efe86f6a1 iommu: Add "iommu.strict" command line option
2da274cdf998a iommu/dma: Add support for non-strict mode
07fdef34d2be6 iommu/arm-smmu-v3: Implement flush_iotlb_all hook
85c7a0f1ef624 iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
[Regression Risk]
Most of these patches are specific to ARM, and have been regression tested on both arm64 (HiSilicon D06) and armhf (QEMU virt) using "stress-ng --vm $(nproc)"
2 patches do touch arch-indep code however:
> 68a6efe86f6a1 iommu: Add "iommu.strict" command line option
Adds a new command line option and sets an attribute that iommu drivers can optionally react to. Doesn't change default behavior.
> 2da274cdf998a iommu/dma: Add support for non-strict mode
This driver is only built for arm64 and ppc64el (determined by looking at the build logs). Most of this patch only changes behavior in the non-default (and new) iommu.strict=0 case. The exception, which is called out in the commit message, is this hunk:
- WARN_ON(iommu_unmap(domain, dma_addr, size) != size);
+ WARN_ON(iommu_unmap_fast(domain, dma_addr, size) != size);
+ if (!cookie->fq_domain)
+ iommu_tlb_sync(domain);
In the default case, where fq_domain will be NULl, we are now factoring iommu_unmap() into:
iommu_unmap_fast()
iommu_tlb_sync()
Looking at the source to iommu_unmap() confirms that this is functionally equivalent. |
[Impact]
The Intel IOMMU driver provides an option for strict mode. When disabled, batching of IOTLB flush operations is permitted, allowing the user to trade-off isolation for improved performance. Ubuntu's kernel currently lacks a parity for this feature for ARM.
There's a significant performance gain to be had by removing the need to flush the IOMMU TLB on every unmap on arm64. I'm seeing a 25% performance gain w/ fio reads on a single NVMe device.
This mode of operation is available for x86 via the "intel_iommu=strict" parameter. Upstream now exposes an equivalent feature for ARM platforms via the "iommu.strict=[0|1]" parameter, while retaining the default strict-enabled mode.
[Test Case]
Run fio with the following config before and after applying the patches and collection IOPS count. Run again after applying the patches. Finally, run a 3rd time after adding iommu.strict=0 to the kernel commandline.
Performance should not regress after the update. Performance should further improve after adding iommu.strict=0 - but if it doesn't for some reason, that is not a regression.
$ cat fio.rc
[global]
rw=read
direct=1
ioengine=libaio
iodepth=2048
numjobs=10
bs=4k
group_reporting=1
group_reporting=1
cpumask=0xff
runtime=100
loops = 10000
[job1]
filename=/dev/nvme0n1
[Fix]
44f6876a00e83 iommu/arm-smmu: Support non-strict mode
b2dfeba654cb0 iommu/io-pgtable-arm-v7s: Add support for non-strict mode
9662b99a19abc iommu/arm-smmu-v3: Add support for non-strict mode
b6b65ca20bc93 iommu/io-pgtable-arm: Add support for non-strict mode
68a6efe86f6a1 iommu: Add "iommu.strict" command line option
2da274cdf998a iommu/dma: Add support for non-strict mode
07fdef34d2be6 iommu/arm-smmu-v3: Implement flush_iotlb_all hook
85c7a0f1ef624 iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
[Regression Risk]
Most of these patches are specific to ARM, and have been regression tested on both arm64 (HiSilicon D06) and armhf (QEMU virt) using "stress-ng --vm $(nproc)"
2 patches do touch arch-indep code however:
> 68a6efe86f6a1 iommu: Add "iommu.strict" command line option
Adds a new command line option and sets an attribute that iommu drivers can optionally react to. Doesn't change default behavior.
> 2da274cdf998a iommu/dma: Add support for non-strict mode
This driver is only built for arm64 and ppc64el (determined by looking at the build logs). Most of this patch only changes behavior in the non-default (and new) iommu.strict=0 case. The exception, which is called out in the commit message, is this hunk:
- WARN_ON(iommu_unmap(domain, dma_addr, size) != size);
+ WARN_ON(iommu_unmap_fast(domain, dma_addr, size) != size);
+ if (!cookie->fq_domain)
+ iommu_tlb_sync(domain);
In the default case, where fq_domain will be NULl, we are now factoring iommu_unmap() into:
iommu_unmap_fast()
iommu_tlb_sync()
Looking at the source to iommu_unmap() confirms that this is functionally equivalent. |
|
2019-01-17 12:25:03 |
Ike Panhc |
tags |
verification-needed-bionic verification-needed-cosmic |
verification-done-bionic verification-done-cosmic |
|
2019-01-28 17:12:01 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
2019-01-28 17:12:01 |
Launchpad Janitor |
cve linked |
|
2018-14625 |
|
2019-01-28 17:12:01 |
Launchpad Janitor |
cve linked |
|
2018-16882 |
|
2019-01-28 17:12:01 |
Launchpad Janitor |
cve linked |
|
2018-17972 |
|
2019-01-28 17:12:01 |
Launchpad Janitor |
cve linked |
|
2018-18281 |
|
2019-01-28 17:12:01 |
Launchpad Janitor |
cve linked |
|
2018-19407 |
|
2019-02-04 08:48:45 |
Launchpad Janitor |
linux (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
2019-02-04 14:46:37 |
Launchpad Janitor |
linux (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
2019-07-24 21:31:49 |
Brad Figg |
tags |
verification-done-bionic verification-done-cosmic |
cscc verification-done-bionic verification-done-cosmic |
|
2022-10-28 15:00:37 |
Tim Gardner |
bug task added |
|
linux-aws (Ubuntu) |
|
2022-10-28 15:00:57 |
Tim Gardner |
nominated for series |
|
Ubuntu Kinetic |
|
2022-10-28 15:00:57 |
Tim Gardner |
bug task added |
|
linux (Ubuntu Kinetic) |
|
2022-10-28 15:00:57 |
Tim Gardner |
bug task added |
|
linux-aws (Ubuntu Kinetic) |
|
2022-10-28 15:00:57 |
Tim Gardner |
nominated for series |
|
Ubuntu Jammy |
|
2022-10-28 15:00:57 |
Tim Gardner |
bug task added |
|
linux (Ubuntu Jammy) |
|
2022-10-28 15:00:57 |
Tim Gardner |
bug task added |
|
linux-aws (Ubuntu Jammy) |
|
2022-10-28 15:01:25 |
Tim Gardner |
linux-aws (Ubuntu Bionic): status |
New |
Invalid |
|
2022-10-28 15:01:43 |
Tim Gardner |
linux-aws (Ubuntu Cosmic): status |
New |
Invalid |
|
2022-10-28 15:02:00 |
Tim Gardner |
linux-aws (Ubuntu Disco): status |
New |
Invalid |
|
2022-10-28 15:02:14 |
Tim Gardner |
linux-aws (Ubuntu Jammy): status |
New |
In Progress |
|
2022-10-28 15:02:28 |
Tim Gardner |
linux-aws (Ubuntu Kinetic): status |
New |
In Progress |
|
2022-10-28 15:02:44 |
Tim Gardner |
linux (Ubuntu Jammy): status |
New |
Invalid |
|
2022-10-28 15:02:59 |
Tim Gardner |
linux (Ubuntu Kinetic): status |
New |
Invalid |
|
2022-10-28 15:03:21 |
Tim Gardner |
linux-aws (Ubuntu): status |
New |
Invalid |
|
2022-11-09 23:44:25 |
Tim Gardner |
linux-aws (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
2022-11-09 23:44:36 |
Tim Gardner |
linux-aws (Ubuntu Kinetic): status |
In Progress |
Fix Committed |
|
2022-12-15 14:16:01 |
Tim Gardner |
linux-aws (Ubuntu Jammy): status |
Fix Committed |
In Progress |
|
2022-12-15 14:16:20 |
Tim Gardner |
linux-aws (Ubuntu Jammy): importance |
Undecided |
Medium |
|
2022-12-15 14:16:20 |
Tim Gardner |
linux-aws (Ubuntu Jammy): assignee |
|
Tim Gardner (timg-tpi) |
|
2022-12-15 14:16:37 |
Tim Gardner |
linux-aws (Ubuntu Kinetic): importance |
Undecided |
Medium |
|
2022-12-15 14:16:37 |
Tim Gardner |
linux-aws (Ubuntu Kinetic): status |
Fix Committed |
In Progress |
|
2022-12-15 14:16:37 |
Tim Gardner |
linux-aws (Ubuntu Kinetic): assignee |
|
Tim Gardner (timg-tpi) |
|
2022-12-15 14:16:49 |
Tim Gardner |
nominated for series |
|
Ubuntu Lunar |
|
2022-12-15 14:16:49 |
Tim Gardner |
bug task added |
|
linux (Ubuntu Lunar) |
|
2022-12-15 14:16:49 |
Tim Gardner |
bug task added |
|
linux-aws (Ubuntu Lunar) |
|
2022-12-15 14:17:20 |
Tim Gardner |
linux-aws (Ubuntu Lunar): importance |
Undecided |
Medium |
|
2022-12-15 14:17:20 |
Tim Gardner |
linux-aws (Ubuntu Lunar): status |
Invalid |
In Progress |
|
2022-12-15 14:17:20 |
Tim Gardner |
linux-aws (Ubuntu Lunar): assignee |
|
Tim Gardner (timg-tpi) |
|
2022-12-15 15:40:18 |
Tim Gardner |
linux-aws (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
2022-12-15 15:40:31 |
Tim Gardner |
linux-aws (Ubuntu Kinetic): status |
In Progress |
Fix Committed |
|
2022-12-15 15:40:43 |
Tim Gardner |
linux-aws (Ubuntu Lunar): status |
In Progress |
Fix Committed |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
linux-aws (Ubuntu Kinetic): status |
Fix Committed |
Fix Released |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
cve linked |
|
2022-3524 |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
cve linked |
|
2022-3564 |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
cve linked |
|
2022-3565 |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
cve linked |
|
2022-3566 |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
cve linked |
|
2022-3567 |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
cve linked |
|
2022-3594 |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
cve linked |
|
2022-3621 |
|
2023-01-06 00:35:58 |
Launchpad Janitor |
cve linked |
|
2022-43945 |
|
2023-01-12 16:42:13 |
Ubuntu Kernel Bot |
tags |
cscc verification-done-bionic verification-done-cosmic |
cscc kernel-spammed-kinetic-linux-aws verification-done-bionic verification-done-cosmic verification-needed-kinetic |
|
2023-01-18 09:42:15 |
Ubuntu Kernel Bot |
tags |
cscc kernel-spammed-kinetic-linux-aws verification-done-bionic verification-done-cosmic verification-needed-kinetic |
cscc kernel-spammed-jammy-linux-aws kernel-spammed-kinetic-linux-aws verification-done-bionic verification-done-cosmic verification-needed-jammy verification-needed-kinetic |
|
2023-01-31 23:27:08 |
Ubuntu Kernel Bot |
tags |
cscc kernel-spammed-jammy-linux-aws kernel-spammed-kinetic-linux-aws verification-done-bionic verification-done-cosmic verification-needed-jammy verification-needed-kinetic |
cscc kernel-spammed-jammy-linux-aws kernel-spammed-jammy-linux-aws-5.19 kernel-spammed-kinetic-linux-aws verification-done-bionic verification-done-cosmic verification-needed-jammy verification-needed-kinetic |
|
2023-02-13 12:33:44 |
Launchpad Janitor |
linux-aws (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
2023-02-13 12:33:44 |
Launchpad Janitor |
cve linked |
|
2022-47940 |
|
2023-03-26 09:09:46 |
Launchpad Janitor |
linux-aws (Ubuntu Lunar): status |
Fix Committed |
Fix Released |
|
2023-09-09 14:16:48 |
Ubuntu Kernel Bot |
tags |
cscc kernel-spammed-jammy-linux-aws kernel-spammed-jammy-linux-aws-5.19 kernel-spammed-kinetic-linux-aws verification-done-bionic verification-done-cosmic verification-needed-jammy verification-needed-kinetic |
cscc kernel-spammed-focal-linux-aws-5.15-v2 kernel-spammed-jammy-linux-aws kernel-spammed-jammy-linux-aws-5.19 kernel-spammed-kinetic-linux-aws verification-done-bionic verification-done-cosmic verification-needed-focal-linux-aws-5.15 verification-needed-jammy verification-needed-kinetic |
|