Activity log for bug #1806488

Date Who What changed Old value New value Message
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