public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Linus Torvalds <torvalds@linux-foundation.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 23:44:14 +0200	[thread overview]
Message-ID: <YTKXLjwkD3Kn8VUz@8bytes.org> (raw)
In-Reply-To: <CAHk-=wjTpYOsRPm4T2EV=Sxm52buZrMpRdwSDeedCSF4jh=M1w@mail.gmail.com>

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.

> 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")
> 
> 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

  reply	other threads:[~2021-09-03 21:44 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
2021-09-03 21:44   ` Joerg Roedel [this message]
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=YTKXLjwkD3Kn8VUz@8bytes.org \
    --to=joro@8bytes.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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