From: Andy Lutomirski <luto@kernel.org> To: Fenghua Yu <fenghua.yu@intel.com> Cc: Peter Zijlstra <peterz@infradead.org>, Dave Hansen <dave.hansen@intel.com>, H Peter Anvin <hpa@zytor.com>, Jean-Philippe Brucker <jean-philippe@linaro.org>, Dave Jiang <dave.jiang@intel.com>, Ashok Raj <ashok.raj@intel.com>, x86 <x86@kernel.org>, amd-gfx <amd-gfx@lists.freedesktop.org>, Christoph Hellwig <hch@infradead.org>, Ingo Molnar <mingo@redhat.com>, Ravi V Shankar <ravi.v.shankar@intel.com>, Borislav Petkov <bp@alien8.de>, Thomas Gleixner <tglx@linutronix.de>, Tony Luck <tony.luck@intel.com>, Felix Kuehling <Felix.Kuehling@amd.com>, linux-kernel <linux-kernel@vger.kernel.org>, iommu <iommu@lists.linux-foundation.org>, Jacob Jun Pan <jacob.jun.pan@intel.com>, David Woodhouse <dwmw2@infradead.org> Subject: Re: [PATCH v6 12/12] x86/traps: Fix up invalid PASID Date: Fri, 31 Jul 2020 16:34:11 -0700 [thread overview] Message-ID: <CALCETrXnO4oh+WyxtSM-j_pP4QgkSg24=y76OBEHxXxAfJtPhA@mail.gmail.com> (raw) In-Reply-To: <1594684087-61184-13-git-send-email-fenghua.yu@intel.com> On Mon, Jul 13, 2020 at 4:48 PM Fenghua Yu <fenghua.yu@intel.com> wrote: > > A #GP fault is generated when ENQCMD instruction is executed without > a valid PASID value programmed in the current thread's PASID MSR. The > #GP fault handler will initialize the MSR if a PASID has been allocated > for this process. > > Decoding the user instruction is ugly and sets a bad architecture > precedent. It may not function if the faulting instruction is modified > after #GP. > > Thomas suggested to provide a reason for the #GP caused by executing ENQCMD > without a valid PASID value programmed. #GP error codes are 16 bits and all > 16 bits are taken. Refer to SDM Vol 3, Chapter 16.13 for details. The other > choice was to reflect the error code in an MSR. ENQCMD can also cause #GP > when loading from the source operand, so its not fully comprehending all > the reasons. Rather than special case the ENQCMD, in future Intel may > choose a different fault mechanism for such cases if recovery is needed on > #GP. Decoding the user instruction is ugly and sets a bad architecture precedent, but we already do it in #GP for UMIP. So I'm unconvinced. Memo to Intel, though: you REALLY need to start thinking about what the heck an OS is supposed to do with all these new faults you're coming up with. The new #NM for TILE is utterly nonsensical. Sure, it works for an OS that does not use CR0.TS and as long as no one tries to extend the same mechanism for some new optional piece of state, but as soon as Intel tries to use the same mechanism for anything else, it falls apart. Please do better. > + > +/* > + * Write the current task's PASID MSR/state. This is called only when PASID > + * is enabled. > + */ > +static void fpu__pasid_write(u32 pasid) > +{ > + u64 msr_val = pasid | MSR_IA32_PASID_VALID; > + > + fpregs_lock(); > + > + /* > + * If the MSR is active and owned by the current task's FPU, it can > + * be directly written. > + * > + * Otherwise, write the fpstate. > + */ > + if (!test_thread_flag(TIF_NEED_FPU_LOAD)) { > + wrmsrl(MSR_IA32_PASID, msr_val); > + } else { > + struct ia32_pasid_state *ppasid_state; > + > + ppasid_state = get_xsave_addr(¤t->thread.fpu.state.xsave, > + XFEATURE_PASID); > + /* > + * ppasid_state shouldn't be NULL because XFEATURE_PASID > + * is enabled. > + */ > + WARN_ON_ONCE(!ppasid_state); > + ppasid_state->pasid = msr_val; WARN instead of BUG is nice, but you'll immediate oops if this fails. How about: if (!WARN_ON_ONCE(!ppasid_state)) ppasid_state->pasid = msr_val; _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-07-31 23:34 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-13 23:47 [PATCH v6 00/12] x86: tag application address space for devices Fenghua Yu 2020-07-13 23:47 ` [PATCH v6 01/12] iommu: Change type of pasid to u32 Fenghua Yu 2020-07-14 2:45 ` Liu, Yi L 2020-07-14 13:54 ` Fenghua Yu 2020-07-14 13:56 ` Liu, Yi L 2020-07-22 14:03 ` Joerg Roedel 2020-07-22 17:21 ` Fenghua Yu 2020-07-13 23:47 ` [PATCH v6 02/12] iommu/vt-d: Change flags type to unsigned int in binding mm Fenghua Yu 2020-07-13 23:47 ` [PATCH v6 03/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing) Fenghua Yu 2020-07-14 3:25 ` Liu, Yi L 2020-07-15 23:32 ` Fenghua Yu 2020-07-13 23:47 ` [PATCH v6 04/12] x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 05/12] x86/fpu/xstate: Add supervisor PASID state for ENQCMD feature Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 06/12] x86/msr-index: Define IA32_PASID MSR Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 07/12] mm: Define pasid in mm Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 08/12] fork: Clear PASID for new mm Fenghua Yu 2021-02-24 10:19 ` Jean-Philippe Brucker 2021-02-25 22:17 ` Fenghua Yu 2021-03-01 23:00 ` Jacob Pan 2021-03-02 10:43 ` Jean-Philippe Brucker 2020-07-13 23:48 ` [PATCH v6 09/12] x86/process: Clear PASID state for a newly forked/cloned thread Fenghua Yu 2020-08-01 1:44 ` Andy Lutomirski 2020-07-13 23:48 ` [PATCH v6 10/12] x86/mmu: Allocate/free PASID Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 11/12] sched: Define and initialize a flag to identify valid PASID in the task Fenghua Yu 2020-07-13 23:48 ` [PATCH v6 12/12] x86/traps: Fix up invalid PASID Fenghua Yu 2020-07-31 23:34 ` Andy Lutomirski [this message] 2020-08-01 0:42 ` Fenghua Yu 2020-08-03 15:03 ` Dave Hansen 2020-08-03 15:12 ` Andy Lutomirski 2020-08-03 15:19 ` Raj, Ashok 2020-08-03 16:36 ` Dave Hansen 2020-08-03 17:16 ` Andy Lutomirski 2020-08-03 17:34 ` Dave Hansen 2020-08-03 19:24 ` Andy Lutomirski 2020-08-01 1:28 ` Andy Lutomirski 2020-08-03 17:19 ` Fenghua Yu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CALCETrXnO4oh+WyxtSM-j_pP4QgkSg24=y76OBEHxXxAfJtPhA@mail.gmail.com' \ --to=luto@kernel.org \ --cc=Felix.Kuehling@amd.com \ --cc=amd-gfx@lists.freedesktop.org \ --cc=ashok.raj@intel.com \ --cc=bp@alien8.de \ --cc=dave.hansen@intel.com \ --cc=dave.jiang@intel.com \ --cc=dwmw2@infradead.org \ --cc=fenghua.yu@intel.com \ --cc=hch@infradead.org \ --cc=hpa@zytor.com \ --cc=iommu@lists.linux-foundation.org \ --cc=jacob.jun.pan@intel.com \ --cc=jean-philippe@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=peterz@infradead.org \ --cc=ravi.v.shankar@intel.com \ --cc=tglx@linutronix.de \ --cc=tony.luck@intel.com \ --cc=x86@kernel.org \ --subject='Re: [PATCH v6 12/12] x86/traps: Fix up invalid PASID' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).