From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
iommu@lists.linux.dev, Jason Gunthorpe <jgg@nvidia.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
Joerg Roedel <joro@8bytes.org>,
Jean-Philippe Brucker <jean-philippe@linaro.com>,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>, Raj Ashok <ashok.raj@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>, Yi Liu <yi.l.liu@intel.com>,
"Yu, Fenghua" <fenghua.yu@intel.com>,
jacob.jun.pan@linux.intel.com, "Hansen,
Dave" <dave.hansen@intel.com>
Subject: Re: [PATCH] iommu: Add Kconfig help text for IOMMU_SVA
Date: Mon, 8 May 2023 09:40:14 -0700 [thread overview]
Message-ID: <20230508094014.53913cf3@jacob-builder> (raw)
In-Reply-To: <CAHk-=wjmOAQnqJF-pW=fzMXb_Rk_J_Oi4ESBLmVPhxwBK4xfGg@mail.gmail.com>
Hi Linus,
On Sun, 7 May 2023 11:52:18 -0700, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sat, May 6, 2023 at 3:03 PM Jacob Pan <jacob.jun.pan@linux.intel.com>
> wrote:
> >
> > Right, how about IOMMU_SHARING_CPU_PGTABLE?
>
> I think from a VM / process angle, I'd actually prefer calling the
> "pasid" part just that: IOMMU_PASID.
>
> The VM code certainly understands about address space IDs, even if
> people have called them different things: normal people called them
> ASID's long ago, then Intel at some pointed decided that "PCID" made
> sense as a name (narrator: "no it didn't"), and then you got that
> combined "PASID" thing.
>
> Now, it may be that this then goes hand-in-hand with other IOMMU code
> that isn't *about* PASID itself, but that depends on PASID's being
> present, and so I'd just expect IOMMU_PASID to be one of those options
> that are selected by other options.
>
> So maybe there is some part of IOMMU_SVA that is not about PASID
> itself, but I really think that the PASID code itself should just have
> that CONFIG_PASID around it.
Conversely, we could also have some part of PASID that is not about SVA.
e.g. Today, on PASID enabled IOMMUs, DMA request w/o PASID (legacy) uses a
special PASID 0. This has nothing to do with mm->pasid.
> End result: from a legibility standpoint, I think it could be as
> simple as having that
>
> config IOMMU_SVA
>
> option have a "select IOMMU_PASID".
> Then make the VM/process PASID code depend on that. Maybe the "struct
> device *" stuff makes more sense under CONFIG_IOMMU_SVA, ie things
> like iopf_queue_add_device() and friends.
right, we don;t support non-PASID IOPF.
> How does that sound? Maybe those two options then always end up going
> together, but even if that is the case, I think from a VM/process
> standpoint it makes a lot more sense to simply have a "PASID enabled"
> option. It's much more understandable in that context, while something
> like "IOMMU_SVA" really is just a random jumble of letters to a VM
> person.
My only concern is the case above where DMA API uses a PASID for legacy DMA
requests w/o PASID. I am also trying to add non-zero PASID for
Intel's ENQCMDS.
https://lore.kernel.org/linux-iommu/20230427174937.471668-1-jacob.jun.pan@linux.intel.com/
The PASIDs used in this case uses IOVA page tables, not shared with any
mm_struct.
From this use case, we need to select IOMMU_PASID, but not necessarily for
mm->pasid which IMHO is only meaningful when IOMMU shares page tables with
the CPU.
> And while the individual words in IOMMU_SHARING_CPU_PGTABLE all make
> sense, it's not clear what the combination means, and why it should
> have anything to do with then having an address space identifier for
> it.
>
> Linus
>
Thanks,
Jacob
next prev parent reply other threads:[~2023-05-08 16:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-06 13:31 [PATCH] iommu: Add Kconfig help text for IOMMU_SVA Jacob Pan
2023-05-06 15:19 ` kernel test robot
2023-05-06 15:39 ` kernel test robot
2023-05-06 15:39 ` kernel test robot
2023-05-06 15:43 ` Linus Torvalds
2023-05-06 22:07 ` Jacob Pan
2023-05-07 18:52 ` Linus Torvalds
2023-05-08 16:40 ` Jacob Pan [this message]
2023-05-08 16:42 ` Linus Torvalds
2023-05-08 16:55 ` Jason Gunthorpe
2023-05-08 17:17 ` Linus Torvalds
2023-05-08 20:21 ` Jacob Pan
2023-05-09 0:13 ` Tian, Kevin
2023-05-09 1:55 ` Baolu Lu
2023-05-09 0:10 ` Tian, Kevin
2023-05-09 23:06 ` Jason Gunthorpe
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=20230508094014.53913cf3@jacob-builder \
--to=jacob.jun.pan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=fenghua.yu@intel.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.com \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
/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