From: Jason Gunthorpe <jgg@ziepe.ca>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Kevin Tian <kevin.tian@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev
Subject: Re: [git pull] IOMMU Updates for Linux v6.4
Date: Fri, 5 May 2023 16:57:17 -0300 [thread overview]
Message-ID: <ZFVfncB76TrB+c4K@ziepe.ca> (raw)
In-Reply-To: <CAHk-=wjW4CzM9YZqwB3jU9mt7FKdctLWAbOcBQAwJ0_2eRmP=g@mail.gmail.com>
On Fri, May 05, 2023 at 11:03:46AM -0700, Linus Torvalds wrote:
> That config option rename in particular I find to just be bad. We now
> have some code that is *very* central, to the point where we have a
> field for it in the 'struct mm_struct', and special callback for
> fork() and exit(), and then the config option is called something
> completely incomprehensible like 'IOMMU_SVA'?
The purpose of this field is to enable the new Intel ENQCMD
instruction that requries the arch code to put the processes PASID
value into some MSR and keep it there across context switches. See
commit fa6af69f38d3 ("x86/traps: Demand-populate PASID MSR via #GP")
ENQCMD is used when the IOMMU page table points directly at the CPU
page table (Shared Virtual Addressing) and supports some simple
stateless "PCI" devices that Intel has designed.
At least with the current situation CONFIG_INTEL_ENQCMD might be an
appropriate name, split out from the IOMMU kconfig and put in arch
kconfig?
Ideally we wouldn't need this on today's ARM systems, for instance.
Jason
next prev parent reply other threads:[~2023-05-05 19:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-30 11:13 [git pull] IOMMU Updates for Linux v6.4 Joerg Roedel
2023-04-30 20:07 ` Linus Torvalds
2023-04-30 23:06 ` Jason Gunthorpe
2023-05-06 4:09 ` Jacob Pan
2023-05-05 14:02 ` Joerg Roedel
2023-05-05 18:03 ` Linus Torvalds
2023-05-05 19:57 ` Jason Gunthorpe [this message]
2023-05-05 20:10 ` Linus Torvalds
2023-05-06 2:58 ` Tian, Kevin
2023-04-30 20:08 ` 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=ZFVfncB76TrB+c4K@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--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