Re: [git pull] IOMMU Updates for Linux v5.15

From: Robin Murphy
Date: Mon Sep 06 2021 - 07:06:11 EST


On 2021-09-03 22:44, Joerg Roedel wrote:
On Fri, Sep 03, 2021 at 11:43:31AM -0700, Linus Torvalds wrote:
choice
prompt "IOMMU default domain type"
depends on IOMMU_API
default IOMMU_DEFAULT_DMA_LAZY if AMD_IOMMU || INTEL_IOMMU
default IOMMU_DEFAULT_DMA_STRICT

Huh, yeah, that is bogus. Seems like I overlooked that part of the
patch-set because I was so amazed by the simplifications and cleanups in
the rest of it.

Mad as it looks, this does in fact capture the existing behaviour. What we've consolidated here was previously a weird mix of driver- and subsystem-level controls, and it is specifically those two drivers which have a long-standing expectation of using lazy behaviour by default.

See what I'm saying? Making the default be based on some random "this
driver is enabled" when it can then affect *other* drivers that are
also enabled and not part of the decision seems to be a fundamental
confusion about what is going on, when it's not at all clear which
driver will actually be IN USE.

The Kconfig option itself was actually my suggestion, but how the
default value is chosen certainly needs improvement. I will sort this
out with the people involved.

IOW, the fix might be to just say "the default is always lazy".

Or the fix might be something that is global to a configuration and
doesn't rely on which iommu is in use (eg "on x86, the default is
always LAZY")

We could certainly express it as "default IOMMU_DEFAULT_DMA_LAZY if X86" if people would prefer - virtio-iommu doesn't support lazy mode either way, so the end result will still be equivalent.

Robin.

Or the fix is to make that 'iommu_dma_strict' variable - and the
default value for it - be a per-IOMMU thing rather than be a global.

My preference would be to make 'lazy' or 'strict' the default for all,
but the ARM folks might disagree. On the other side it also doesn't make
sense to let IOMMU drivers override the users Kconfig choice at runtime.
We will discuss this and come up with something better. >
Thanks,

Joerg
_______________________________________________
iommu mailing list
iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/iommu