linux-kernel - Re: [PATCH] iommu: Add Kconfig help text for IOMMU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230508094014.53913cf3@jacob-builder>
Date:   Mon, 8 May 2023 09:40:14 -0700
From:   Jacob Pan <jacob.jun.pan@...ux.intel.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>, iommu@...ts.linux.dev,
        Jason Gunthorpe <jgg@...dia.com>,
        Lu Baolu <baolu.lu@...ux.intel.com>,
        Joerg Roedel <joro@...tes.org>,
        Jean-Philippe Brucker <jean-philippe@...aro.com>,
        Robin Murphy <robin.murphy@....com>,
        Will Deacon <will@...nel.org>, Raj Ashok <ashok.raj@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>, Yi Liu <yi.l.liu@...el.com>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        jacob.jun.pan@...ux.intel.com,
        "Hansen, Dave" <dave.hansen@...el.com>
Subject: Re: [PATCH] iommu: Add Kconfig help text for IOMMU_SVA

Hi Linus,

On Sun, 7 May 2023 11:52:18 -0700, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:

> On Sat, May 6, 2023 at 3:03 PM Jacob Pan <jacob.jun.pan@...ux.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