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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjmOAQnqJF-pW=fzMXb_Rk_J_Oi4ESBLmVPhxwBK4xfGg@mail.gmail.com>
Date:   Sun, 7 May 2023 11:52:18 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jacob Pan <jacob.jun.pan@...ux.intel.com>
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>
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@...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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ