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: <BN9PR11MB52760853B80C76F1427284138C769@BN9PR11MB5276.namprd11.prod.outlook.com>
Date:   Tue, 9 May 2023 00:10:17 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     "Torvalds, Linus" <torvalds@...ux-foundation.org>,
        Jason Gunthorpe <jgg@...dia.com>
CC:     Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
        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>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>
Subject: RE: [PATCH] iommu: Add Kconfig help text for IOMMU_SVA

> From: Linus Torvalds <torvalds@...ux-foundation.org>
> Sent: Tuesday, May 9, 2023 1:18 AM
> 
> On Mon, May 8, 2023 at 9:55 AM Jason Gunthorpe <jgg@...dia.com> wrote:
> >
> > CONFIG_IOMMU_MM_PASID perhaps? Says what it does without a clue
> about
> > why it does it. x86 arch code could select it ideally?
> 
> Maybe we don't even need the "IOMMU" part. It's a core x86
> architecture feature. Maybe it usually (always?) gets used within the
> framework of some IOMMU work, but I guess ENCQCMD could be used in
> some hardwired way even without that (ie is it possible to have just
> some "basic PASID set up by VMM environment" thing?)

This makes sense to me. At least that is one possible way in concept,
though we don't have such example now.

> 
> I don't actually know who uses it and how, so I'm probably not the
> right person to name it, but just looking at the x86 code that sets
> it, the PASID code technically has no connection to any iommu code,
> it's literally a core CPU feature with an MSR and some magic faulting
> thing, and seems to be possibly usable as-is.
> 
> That existing
> 
>     #ifdef CONFIG_IOMMU_SVA
> 
> in the x86 traps.c code just looks odd, and making it be
> CONFIG_IOMMU_MM_PASID sounds better to me. I'm just not sure about
> the
> "IOMMU" part either. Just "MM_PASID"?
> 
> That said, the arm-smmu-v3-sva.c code clearly *also* uses pasid,
> except it seems to really want to call it "ssid".
> 
> So "having a per-mm ASID for IO" is clearly a common feature. But

Yes. Currently PASID for mm is globally allocated so each mm is
associated with a single unique pasid. 

> naming seems hard, with x86 calling it PASID, arm64 seemingly calling
> it "SSID".
> 
> Right now the only user *does* seem to be through the IOMMU SVA code,
> but that may or may not be fundamental.
> 
> Now, "SSID" is a completely horrible name, as I immediately realized
> when I tried to google for it. So arm64 is just wrong, and we're most
> definitely continuing to call it PASID.

We have undergone this naming game when enabling SVA before.

At that point IOASID was considered as a generic term to cover both
PCI PASID and ARM specific SSID. But in the end PASID/IOASID are
still mixed in many common code.

IMHO sticking with PASID should be fine. 

> 
> I'd lean towards just "CONFIG_MM_PASID" or something, but at some
> point this is bikeshedding, and I don't know about any possible
> non-iommu direct uses?
> 

I agree that CONFIG_MM_PASID is more accurate in definition.