Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v6 12/12] x86/traps: Fix up invalid PASID
Date:   Mon, 3 Aug 2020 12:24:44 -0700
Message-Id: <56C96132-6F42-4E50-B712-C7F31CB01C9D@amacapital.net>
References: <92a14516-1f63-5b5f-7f30-8870fe343c8e@intel.com>
Cc:     Andy Lutomirski <luto@kernel.org>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Joerg Roedel <joro@8bytes.org>, Ingo Molnar <mingo@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        Peter Zijlstra <peterz@infradead.org>,
        H Peter Anvin <hpa@zytor.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        Felix Kuehling <Felix.Kuehling@amd.com>,
        Tony Luck <tony.luck@intel.com>,
        Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Christoph Hellwig <hch@infradead.org>,
        Ashok Raj <ashok.raj@intel.com>,
        Jacob Jun Pan <jacob.jun.pan@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Sohil Mehta <sohil.mehta@intel.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        x86 <x86@kernel.org>, iommu <iommu@lists.linux-foundation.org>,
        amd-gfx <amd-gfx@lists.freedesktop.org>
In-Reply-To: <92a14516-1f63-5b5f-7f30-8870fe343c8e@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Aug 3, 2020, at 10:34 AM, Dave Hansen <dave.hansen@intel.com> wrote:
>=20
> =EF=BB=BFOn 8/3/20 10:16 AM, Andy Lutomirski wrote:
>> - TILE: genuinely per-thread, but it's expensive so it's
>> lazy-loadable.  But the lazy-load mechanism reuses #NM, and it's not
>> fully disambiguated from the other use of #NM.  So it sort of works,
>> but it's gross.
>=20
> For those playing along at home, there's a new whitepaper out from Intel
> about some new CPU features which are going to be fun:
>=20
>> https://software.intel.com/content/dam/develop/public/us/en/documents/arc=
hitecture-instruction-set-extensions-programming-reference.pdf
>=20
> Which part were you worried about?  I thought it was fully disambuguated
> from this:
>=20
>> When XFD causes an instruction to generate #NM, the processor loads
>> the IA32_XFD_ERR MSR to identify the disabled state component(s).
>> Specifically, the MSR is loaded with the logical AND of the IA32_XFD
>> MSR and the bitmap corresponding to the state components required by
>> the faulting instruction.
>>=20
>> Device-not-available exceptions that are not due to XFD =E2=80=94 those=20=

>> resulting from setting CR0.TS to 1 =E2=80=94 do not modify the IA32_XFD_E=
RR
>> MSR.
>=20
> So if you always make sure to *clear* IA32_XFD_ERR after handing and XFD
> exception, any #NM's with a clear IA32_XFD_ERR are from "legacy"
> CR0.TS=3D1.  Any bits set in IA32_XFD_ERR mean a new-style XFD exception.
>=20
> Am I missing something?

I don=E2=80=99t think you=E2=80=99re missing anything, but this mechanism se=
ems to be solidly in the category of =E2=80=9Cjust barely works=E2=80=9D, ki=
nd of like #DB and DR6, which also just barely works.

And this PASID vs #GP mess is just sad. We=E2=80=99re trying to engineer aro=
und an issue that has no need to exist in the first place.  For some reason w=
e have two lazy-loading-fault mechanisms showing up in x86 in rapid successi=
on, one of them is maybe 3/4-baked, and the other is totally separate and ma=
ybe 1/4 baked.

If ENQCMD instead raise #NM, this would be trivial. (And it even makes sense=
 =E2=80=94 the error is, literally, =E2=80=9Can instruction tried to use som=
ething in XSTATE that isn=E2=80=99t initialized=E2=80=9D.). Or if someone ha=
d noticed that, kind of like PKRU, PASID didn=E2=80=99t really belong in XST=
ATE, we wouldn=E2=80=99t have this mess.

Yes, obviously Linux can get all this stuff to work, but maybe Intel could a=
spire to design features that are straightforward to use well instead of mer=
ely possible to use well?=