From: Linus Torvalds <torvalds@linux-foundation.org>
To: Joerg Roedel <joro@8bytes.org>
Cc: Will Deacon <will@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
iommu <iommu@lists.linux-foundation.org>
Subject: Re: [git pull] IOMMU Updates for Linux v5.15
Date: Fri, 3 Sep 2021 11:43:31 -0700 [thread overview]
Message-ID: <CAHk-=wjTpYOsRPm4T2EV=Sxm52buZrMpRdwSDeedCSF4jh=M1w@mail.gmail.com> (raw)
In-Reply-To: <YTIrHxWNzIwuseXO@8bytes.org>
On Fri, Sep 3, 2021 at 7:03 AM Joerg Roedel <joro@8bytes.org> wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v5.15
So I've merged this, but I'm not entirely happy with some of the
rather insane Kconfig choices.
In particular, the defaults for this:
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
seems fundamentally confused about what the h*ll is going on.
Why? Because a choice like "AMD_IOMMU" or "INTEL_IOMMU" isn't some
exclusive thing. You can have one or the other - or both. Or you could
have another IOMMU entirely, despite _also_ having AMD/INTEL_IOMMU
enabled as a config option.
IOW, maybe INTEL or AMD_IOMMU is enabled in the kernel configuration,
but that might not be the IOMMU that is then actually *active*.
The active IOMMU might be VIRTIO_IOMMU, for example.
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.
Now, I don't think this _matters_ that much in practice, and as
mentioned, I already merged things.
But I think people should seriously think about either
(a) make that default something that is actually *reliable*, so that
the fact that you have possibly enabled iommu X doesn't affect iommu Y
that is actually the one in use
or
(b) make the defaults be actually per-driver, and set when the driver
is in *use* rather than this incorrect model of "enabled but maybe not
even used".
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")
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.
Hmm?
Linus
next prev parent reply other threads:[~2021-09-03 18:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-03 14:03 [git pull] IOMMU Updates for Linux v5.15 Joerg Roedel
2021-09-03 18:43 ` Linus Torvalds [this message]
2021-09-03 21:44 ` Joerg Roedel
2021-09-06 11:06 ` Robin Murphy
2021-09-03 18:45 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wjTpYOsRPm4T2EV=Sxm52buZrMpRdwSDeedCSF4jh=M1w@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).