Messages in this thread | | | From | Linus Torvalds <> | Date | Sun, 7 May 2023 11:52:18 -0700 | Subject | Re: [PATCH] iommu: Add Kconfig help text for IOMMU_SVA |
| |
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.
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.
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.
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
| |