Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <ZE5NR5Ml8I2/Ze0f@8bytes.org> <CAHk-=wiriLmq6OgLLF9seANqCJqjCrgUC384zcJUFtv3xJgVkQ@mail.gmail.com>
 <ZFUMja5MpRPWCRXw@8bytes.org> <CAHk-=wjW4CzM9YZqwB3jU9mt7FKdctLWAbOcBQAwJ0_2eRmP=g@mail.gmail.com>
 <ZFVfncB76TrB+c4K@ziepe.ca>
In-Reply-To: <ZFVfncB76TrB+c4K@ziepe.ca>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 5 May 2023 13:10:30 -0700
Message-ID: <CAHk-=wjvonKjgyY1-Mc9POg1euT68wX3Z5+wqBckN+_j=pOaAw@mail.gmail.com>
Subject: Re: [git pull] IOMMU Updates for Linux v6.4
To:     Jason Gunthorpe <jgg@ziepe.ca>
Cc:     Kevin Tian <kevin.tian@intel.com>, Joerg Roedel <joro@8bytes.org>,
        Will Deacon <will@kernel.org>, linux-kernel@vger.kernel.org,
        iommu@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, May 5, 2023 at 12:57=E2=80=AFPM Jason Gunthorpe <jgg@ziepe.ca> wrot=
e:
>
> At least with the current situation CONFIG_INTEL_ENQCMD might be an
> appropriate name, split out from the IOMMU kconfig and put in arch
> kconfig?

That would at least somewhat clarify the use. I find IOMMU_SVA to be a
particularly opaque name.

Admittedly I probably find it opaque because I come at it as somebody
much more familiar with the MM side, not from the IOMMU side (and the
_other_ conditional fields there make sense from that standpoint), but
even so I think it would be good to clarify.

Of course, making clear it's architecture-specific would also be an
argument for having an actual architecture-specific part of 'struct
mm_struct' (the same way we have 'struct thread_info' in task_struct),
but with only one single field I suspect that's just not worth it.

And who knows - maybe other architectures will pick something like this up?

But yes, it might be good to really pin down what the rules are. Right
now IOMMU_SVA has *no* real help-text (there's a comment saying "#
Shared Virtual Addressing"), and is also enabled by ARM_SMMU_V3_SVA,
which apparently doesn't actually want pasid support at all.

I dunno. I don't think this is a huge deal, but it did cause some
confusion during the merge.

                 Linus