linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Fenghua Yu <fenghua.yu@intel.com>
To: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>, "H Peter Anvin" <hpa@zytor.com>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Lu Baolu" <baolu.lu@linux.intel.com>,
	"Frederic Barrat" <fbarrat@linux.ibm.com>,
	"Andrew Donnellan" <ajd@linux.ibm.com>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Tony Luck" <tony.luck@intel.com>,
	"Ashok Raj" <ashok.raj@intel.com>,
	"Jacob Jun Pan" <jacob.jun.pan@intel.com>,
	"Dave Jiang" <dave.jiang@intel.com>,
	"Yu-cheng Yu" <yu-cheng.yu@intel.com>,
	"Sohil Mehta" <sohil.mehta@intel.com>,
	"Ravi V Shankar" <ravi.v.shankar@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>, x86 <x86@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	amd-gfx <amd-gfx@lists.freedesktop.org>,
	iommu@lists.linux-foundation.org,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: [PATCH v2 12/12] x86/traps: Fix up invalid PASID
Date: Fri, 12 Jun 2020 17:41:33 -0700	[thread overview]
Message-ID: <1592008893-9388-13-git-send-email-fenghua.yu@intel.com> (raw)
In-Reply-To: <1592008893-9388-1-git-send-email-fenghua.yu@intel.com>

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.

The following heuristic is used to avoid decoding the user instructions
to determine the precise reason for the #GP fault:
1) If the mm for the process has not been allocated a PASID, this #GP
   cannot be fixed.
2) If the PASID MSR is already initialized, then the #GP was for some
   other reason
3) Try initializing the PASID MSR and returning. If the #GP was from
   an ENQCMD this will fix it. If not, the #GP fault will be repeated
   and will hit case "2".

Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
v2:
- Update the first paragraph of the commit message (Thomas)
- Add reasons why don't decode the user instruction and don't use
  #GP error code (Thomas)
- Change get_task_mm() to current->mm (Thomas)
- Add comments on why IRQ is disabled during PASID fixup (Thomas)
- Add comment in fixup() that the function is called when #GP is from
  user (so mm is not NULL) (Dave Hansen)

 arch/x86/include/asm/iommu.h |  1 +
 arch/x86/kernel/traps.c      | 23 +++++++++++++++++++++
 drivers/iommu/intel/svm.c    | 39 ++++++++++++++++++++++++++++++++++++
 3 files changed, 63 insertions(+)

diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h
index ed41259fe7ac..e9365a5d6f7d 100644
--- a/arch/x86/include/asm/iommu.h
+++ b/arch/x86/include/asm/iommu.h
@@ -27,5 +27,6 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr)
 }
 
 void __free_pasid(struct mm_struct *mm);
+bool __fixup_pasid_exception(void);
 
 #endif /* _ASM_X86_IOMMU_H */
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 4cc541051994..0f78d5cdddfe 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -59,6 +59,7 @@
 #include <asm/umip.h>
 #include <asm/insn.h>
 #include <asm/insn-eval.h>
+#include <asm/iommu.h>
 
 #ifdef CONFIG_X86_64
 #include <asm/x86_init.h>
@@ -436,6 +437,16 @@ static enum kernel_gp_hint get_kernel_gp_address(struct pt_regs *regs,
 	return GP_CANONICAL;
 }
 
+static bool fixup_pasid_exception(void)
+{
+	if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM))
+		return false;
+	if (!static_cpu_has(X86_FEATURE_ENQCMD))
+		return false;
+
+	return __fixup_pasid_exception();
+}
+
 #define GPFSTR "general protection fault"
 
 dotraplinkage void do_general_protection(struct pt_regs *regs, long error_code)
@@ -447,6 +458,18 @@ dotraplinkage void do_general_protection(struct pt_regs *regs, long error_code)
 	int ret;
 
 	RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
+
+	/*
+	 * Perform the check for a user mode PASID exception before enable
+	 * interrupts. Doing this here ensures that the PASID MSR can be simply
+	 * accessed because the contents are known to be still associated
+	 * with the current process.
+	 */
+	if (user_mode(regs) && fixup_pasid_exception()) {
+		cond_local_irq_enable(regs);
+		return;
+	}
+
 	cond_local_irq_enable(regs);
 
 	if (static_cpu_has(X86_FEATURE_UMIP)) {
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 27dc866b8461..81fd2380c0f9 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -1078,3 +1078,42 @@ void __free_pasid(struct mm_struct *mm)
 	 */
 	ioasid_free(pasid);
 }
+
+/*
+ * Apply some heuristics to see if the #GP fault was caused by a thread
+ * that hasn't had the IA32_PASID MSR initialized.  If it looks like that
+ * is the problem, try initializing the IA32_PASID MSR. If the heuristic
+ * guesses incorrectly, take one more #GP fault.
+ */
+bool __fixup_pasid_exception(void)
+{
+	u64 pasid_msr;
+	unsigned int pasid;
+
+	/*
+	 * This function is called only when this #GP was triggered from user
+	 * space. So the mm cannot be NULL.
+	 */
+	pasid = current->mm->pasid;
+	/* If the mm doesn't have a valid PASID, then can't help. */
+	if (invalid_pasid(pasid))
+		return false;
+
+	/*
+	 * Since IRQ is disabled now, the current task still owns the FPU on
+	 * this CPU and the PASID MSR can be directly accessed.
+	 *
+	 * If the MSR has a valid PASID, the #GP must be for some other reason.
+	 *
+	 * If rdmsr() is really a performance issue, a TIF_ flag may be
+	 * added to check if the thread has a valid PASID instead of rdmsr().
+	 */
+	rdmsrl(MSR_IA32_PASID, pasid_msr);
+	if (pasid_msr & MSR_IA32_PASID_VALID)
+		return false;
+
+	/* Fix up the MSR if the MSR doesn't have a valid PASID. */
+	wrmsrl(MSR_IA32_PASID, pasid | MSR_IA32_PASID_VALID);
+
+	return true;
+}
-- 
2.19.1


  parent reply	other threads:[~2020-06-13  1:21 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-13  0:41 [PATCH v2 00/12] x86: tag application address space for devices Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 01/12] iommu: Change type of pasid to unsigned int Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 02/12] ocxl: " Fenghua Yu
2020-06-18  8:05   ` Frederic Barrat
2020-06-18 15:37     ` Fenghua Yu
2020-06-18 16:56       ` Frederic Barrat
2020-06-13  0:41 ` [PATCH v2 03/12] iommu/vt-d: Change flags type to unsigned int in binding mm Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 04/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing) Fenghua Yu
2020-06-13 12:17   ` Lu Baolu
2020-06-15 23:16     ` Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 05/12] x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 06/12] x86/fpu/xstate: Add supervisor PASID state for ENQCMD feature Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 07/12] x86/msr-index: Define IA32_PASID MSR Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 08/12] mm: Define pasid in mm Fenghua Yu
2020-06-16  8:28   ` Jean-Philippe Brucker
2020-06-16 15:11     ` Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 09/12] fork: Clear PASID for new mm Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 10/12] x86/process: Clear PASID state for a newly forked/cloned thread Fenghua Yu
2020-06-13  0:41 ` [PATCH v2 11/12] x86/mmu: Allocate/free PASID Fenghua Yu
2020-06-13 13:07   ` Lu Baolu
2020-06-15  2:13   ` Lu Baolu
2020-06-13  0:41 ` Fenghua Yu [this message]
2020-06-15  7:53   ` [PATCH v2 12/12] x86/traps: Fix up invalid PASID Peter Zijlstra
2020-06-15  7:56   ` Peter Zijlstra
2020-06-15 15:48     ` Fenghua Yu
2020-06-15 16:03       ` Peter Zijlstra
2020-06-15 17:11         ` Luck, Tony
2020-06-15 18:12         ` Fenghua Yu
2020-06-15 18:31           ` Peter Zijlstra
2020-06-15 18:55             ` Fenghua Yu
2020-06-15 19:09               ` Peter Zijlstra
2020-06-15 20:17                 ` Fenghua Yu
2020-06-15 20:51                   ` Andy Lutomirski
2020-06-15 20:56                     ` Luck, Tony
2020-06-15 21:18                       ` Andy Lutomirski
2020-06-15 21:24                         ` Luck, Tony
2020-06-15 21:53                   ` Peter Zijlstra
2020-06-16 23:23                 ` Fenghua Yu
2020-06-17  8:31                   ` Peter Zijlstra
2020-06-15 18:19         ` Raj, Ashok
2020-06-15 18:32           ` Peter Zijlstra
2020-06-15  7:52 ` [PATCH v2 00/12] x86: tag application address space for devices Peter Zijlstra
2020-06-15 14:53   ` 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=1592008893-9388-13-git-send-email-fenghua.yu@intel.com \
    --to=fenghua.yu@intel.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=ajd@linux.ibm.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dwmw2@infradead.org \
    --cc=fbarrat@linux.ibm.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yu-cheng.yu@intel.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).