Skip to content

Commit af3e957

Browse files
committed
Revert "iommu/dma: Add config for PCI SAC address trick"
This reverts commit 4bf7fda. It turns out that it was hopelessly naive to think that this would work, considering that we've always done this. The first machine I actually tested this on broke at bootup, getting to Reached target cryptsetup.target - Local Encrypted Volumes. and then hanging. It's unclear what actually fails, since there's a lot else going on around that time (eg amdgpu probing also happens around that same time, but it could be some other random init thing that didn't complete earlier and just caused the boot to hang at that point). The expectations that we should default to some unsafe and untested mode seems entirely unfounded, and the belief that this wouldn't affect modern systems is clearly entirely false. The machine in question is about two years old, so it's not exactly shiny, but it's also not some dusty old museum piece PDP-11 in a closet. Cc: Robin Murphy <robin.murphy@arm.com> Cc: Christoph Hellwig <hch@lst.de> Cc: John Garry <john.garry@huawei.com> Cc: Joerg Roedel <jroedel@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent 20cf903 commit af3e957

File tree

2 files changed

+1
-27
lines changed

2 files changed

+1
-27
lines changed

drivers/iommu/Kconfig

Lines changed: 0 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -144,32 +144,6 @@ config IOMMU_DMA
144144
select IRQ_MSI_IOMMU
145145
select NEED_SG_DMA_LENGTH
146146

147-
config IOMMU_DMA_PCI_SAC
148-
bool "Enable 64-bit legacy PCI optimisation by default"
149-
depends on IOMMU_DMA
150-
help
151-
Enable by default an IOMMU optimisation for 64-bit legacy PCI devices,
152-
wherein the DMA API layer will always first try to allocate a 32-bit
153-
DMA address suitable for a single address cycle, before falling back
154-
to allocating from the device's full usable address range. If your
155-
system has 64-bit legacy PCI devices in 32-bit slots where using dual
156-
address cycles reduces DMA throughput significantly, this may be
157-
beneficial to overall performance.
158-
159-
If you have a modern PCI Express based system, this feature mostly just
160-
represents extra overhead in the allocation path for no practical
161-
benefit, and it should usually be preferable to say "n" here.
162-
163-
However, beware that this feature has also historically papered over
164-
bugs where the IOMMU address width and/or device DMA mask is not set
165-
correctly. If device DMA problems and IOMMU faults start occurring
166-
after disabling this option, it is almost certainly indicative of a
167-
latent driver or firmware/BIOS bug, which would previously have only
168-
manifested with several gigabytes worth of concurrent DMA mappings.
169-
170-
If this option is not set, the feature can still be re-enabled at
171-
boot time with the "iommu.forcedac=0" command-line argument.
172-
173147
# Shared Virtual Addressing
174148
config IOMMU_SVA
175149
bool

drivers/iommu/dma-iommu.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -69,7 +69,7 @@ struct iommu_dma_cookie {
6969
};
7070

7171
static DEFINE_STATIC_KEY_FALSE(iommu_deferred_attach_enabled);
72-
bool iommu_dma_forcedac __read_mostly = !IS_ENABLED(CONFIG_IOMMU_DMA_PCI_SAC);
72+
bool iommu_dma_forcedac __read_mostly;
7373

7474
static int __init iommu_dma_forcedac_setup(char *str)
7575
{

0 commit comments

Comments
 (0)