xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: [PATCH v5 11/21] x86/cpu: Context switch cpuid masks and faulting state in context_switch()
Date: Thu, 7 Apr 2016 12:57:16 +0100	[thread overview]
Message-ID: <1460030246-30153-12-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1460030246-30153-1-git-send-email-andrew.cooper3@citrix.com>

A single ctxt_switch_levelling() function pointer is provided
(defaulting to an empty nop), which is overridden in the appropriate
$VENDOR_init_levelling().

set_cpuid_faulting() is made private and included within
intel_ctxt_switch_levelling().

One (attempted) functional change is that the faulting configuration should
not be special cased for dom0.  It turns out that the toolstack relies on the
special case (and indeed, on being a PV domain in the first place) to
correctly build HVM domains.

For now, the control domain is left as a special case, until futher work can
be completed to remove the restriction.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
---
v3:
 * Don't leave cpuid masking/faulting active for the kexec kernel.
v2:
 * Style fixes.
 * ASSERT() that faulting is available in set_cpuid_faulting().
v5:
 * Fix the building of HVM domains from hardware with faulting available.
---
 xen/arch/x86/cpu/amd.c          |  3 +++
 xen/arch/x86/cpu/common.c       |  7 +++++++
 xen/arch/x86/cpu/intel.c        | 37 ++++++++++++++++++++++++++++++++-----
 xen/arch/x86/crash.c            |  3 +++
 xen/arch/x86/domain.c           |  4 +---
 xen/include/asm-x86/processor.h |  2 +-
 6 files changed, 47 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 93a8a5e..3e2f4a8 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -331,6 +331,9 @@ static void __init noinline amd_init_levelling(void)
 		       (uint32_t)cpuidmask_defaults._7ab0,
 		       (uint32_t)cpuidmask_defaults._6c);
 	}
+
+	if (levelling_caps)
+		ctxt_switch_levelling = amd_ctxt_switch_levelling;
 }
 
 /*
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 7ef75b0..fe6eab4 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -88,6 +88,13 @@ static const struct cpu_dev default_cpu = {
 };
 static const struct cpu_dev *this_cpu = &default_cpu;
 
+static void default_ctxt_switch_levelling(const struct domain *nextd)
+{
+	/* Nop */
+}
+void (* __read_mostly ctxt_switch_levelling)(const struct domain *nextd) =
+	default_ctxt_switch_levelling;
+
 bool_t opt_cpu_info;
 boolean_param("cpuinfo", opt_cpu_info);
 
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 6e1fbbb..e21c32d 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -32,13 +32,15 @@ static bool_t __init probe_intel_cpuid_faulting(void)
 	return 1;
 }
 
-static DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled);
-void set_cpuid_faulting(bool_t enable)
+static void set_cpuid_faulting(bool_t enable)
 {
+	static DEFINE_PER_CPU(bool_t, cpuid_faulting_enabled);
+	bool_t *this_enabled = &this_cpu(cpuid_faulting_enabled);
 	uint32_t hi, lo;
 
-	if (!cpu_has_cpuid_faulting ||
-	    this_cpu(cpuid_faulting_enabled) == enable )
+	ASSERT(cpu_has_cpuid_faulting);
+
+	if (*this_enabled == enable)
 		return;
 
 	rdmsr(MSR_INTEL_MISC_FEATURES_ENABLES, lo, hi);
@@ -47,7 +49,7 @@ void set_cpuid_faulting(bool_t enable)
 		lo |= MSR_MISC_FEATURES_CPUID_FAULTING;
 	wrmsr(MSR_INTEL_MISC_FEATURES_ENABLES, lo, hi);
 
-	this_cpu(cpuid_faulting_enabled) = enable;
+	*this_enabled = enable;
 }
 
 /*
@@ -154,6 +156,28 @@ static void intel_ctxt_switch_levelling(const struct domain *nextd)
 	struct cpuidmasks *these_masks = &this_cpu(cpuidmasks);
 	const struct cpuidmasks *masks = &cpuidmask_defaults;
 
+	if (cpu_has_cpuid_faulting) {
+		/*
+		 * We *should* be enabling faulting for the control domain.
+		 *
+		 * Unfortunately, the domain builder (having only ever been a
+		 * PV guest) expects to be able to see host cpuid state in a
+		 * native CPUID instruction, to correctly build a CPUID policy
+		 * for HVM guests (notably the xstate leaves).
+		 *
+		 * This logic is fundimentally broken for HVM toolstack
+		 * domains, and faulting causes PV guests to behave like HVM
+		 * guests from their point of view.
+		 *
+		 * Future development plans will move responsibility for
+		 * generating the maximum full cpuid policy into Xen, at which
+		 * this problem will disappear.
+		 */
+		set_cpuid_faulting(nextd && is_pv_domain(nextd) &&
+				   !is_control_domain(nextd));
+		return;
+	}
+
 #define LAZY(msr, field)						\
 	({								\
 		if (unlikely(these_masks->field != masks->field) &&	\
@@ -227,6 +251,9 @@ static void __init noinline intel_init_levelling(void)
 			       (uint32_t)cpuidmask_defaults.e1cd,
 			       (uint32_t)cpuidmask_defaults.Da1);
 	}
+
+	if (levelling_caps)
+		ctxt_switch_levelling = intel_ctxt_switch_levelling;
 }
 
 static void early_init_intel(struct cpuinfo_x86 *c)
diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c
index 888a214..f28f527 100644
--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -189,6 +189,9 @@ void machine_crash_shutdown(void)
 
     nmi_shootdown_cpus();
 
+    /* Reset CPUID masking and faulting to the host's default. */
+    ctxt_switch_levelling(NULL);
+
     info = kexec_crash_save_info();
     info->xen_phys_start = xen_phys_start;
     info->dom0_pfn_to_mfn_frame_list_list =
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a4f6db2..cba77a2 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2082,9 +2082,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
             load_segments(next);
         }
 
-        set_cpuid_faulting(is_pv_domain(nextd) &&
-                           !is_control_domain(nextd) &&
-                           !is_hardware_domain(nextd));
+        ctxt_switch_levelling(nextd);
     }
 
     context_saved(prev);
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index a950554..f29d370 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -209,7 +209,7 @@ extern struct cpuinfo_x86 boot_cpu_data;
 extern struct cpuinfo_x86 cpu_data[];
 #define current_cpu_data cpu_data[smp_processor_id()]
 
-extern void set_cpuid_faulting(bool_t enable);
+extern void (*ctxt_switch_levelling)(const struct domain *nextd);
 
 extern u64 host_pat;
 extern bool_t opt_cpu_info;
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-04-07 11:57 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-07 11:57 [PATCH v5 00/21] x86: Improvements to cpuid handling for guests Andrew Cooper
2016-04-07 11:57 ` [PATCH v5 01/21] xen/x86: Annotate VM applicability in featureset Andrew Cooper
2016-04-07 23:01   ` Jan Beulich
2016-04-07 11:57 ` [PATCH v5 02/21] xen/x86: Calculate maximum host and guest featuresets Andrew Cooper
2016-04-07 23:04   ` Jan Beulich
2016-04-07 11:57 ` [PATCH v5 03/21] xen/x86: Generate deep dependencies of features Andrew Cooper
2016-04-07 23:18   ` Jan Beulich
2016-04-07 23:36     ` Andrew Cooper
2016-04-08 15:17       ` Jan Beulich
2016-04-08 15:18         ` Andrew Cooper
2016-04-07 11:57 ` [PATCH v5 04/21] xen/x86: Clear dependent features when clearing a cpu cap Andrew Cooper
2016-04-08 15:36   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 05/21] xen/x86: Improve disabling of features which have dependencies Andrew Cooper
2016-04-08 15:04   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 06/21] xen/x86: Improvements to in-hypervisor cpuid sanity checks Andrew Cooper
2016-04-08 16:10   ` Konrad Rzeszutek Wilk
2016-04-08 18:06   ` Jan Beulich
2016-04-07 11:57 ` [PATCH v5 07/21] x86/cpu: Move set_cpumask() calls into c_early_init() Andrew Cooper
2016-04-08 18:09   ` Jan Beulich
2016-04-07 11:57 ` [PATCH v5 08/21] x86/cpu: Sysctl and common infrastructure for levelling context switching Andrew Cooper
2016-04-07 16:54   ` Daniel De Graaf
2016-04-08 16:12   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 09/21] x86/cpu: Rework AMD masking MSR setup Andrew Cooper
2016-04-08 16:13   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 10/21] x86/cpu: Rework Intel masking/faulting setup Andrew Cooper
2016-04-08 16:14   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` Andrew Cooper [this message]
2016-04-08 16:15   ` [PATCH v5 11/21] x86/cpu: Context switch cpuid masks and faulting state in context_switch() Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 12/21] x86/pv: Provide custom cpumasks for PV domains Andrew Cooper
2016-04-08 16:17   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 13/21] x86/domctl: Update PV domain cpumasks when setting cpuid policy Andrew Cooper
2016-04-08 16:26   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 14/21] xen+tools: Export maximum host and guest cpu featuresets via SYSCTL Andrew Cooper
2016-04-07 16:54   ` Daniel De Graaf
2016-04-08 16:32   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 15/21] tools/libxc: Modify bitmap operations to take void pointers Andrew Cooper
2016-04-07 13:00   ` Wei Liu
2016-04-08 16:34   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 16/21] tools/libxc: Use public/featureset.h for cpuid policy generation Andrew Cooper
2016-04-08 16:37   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 17/21] tools/libxc: Expose the automatically generated cpu featuremask information Andrew Cooper
2016-04-08 16:38   ` Konrad Rzeszutek Wilk
2016-04-07 11:57 ` [PATCH v5 18/21] tools: Utility for dealing with featuresets Andrew Cooper
2016-04-07 11:57 ` [PATCH v5 19/21] tools/libxc: Wire a featureset through to cpuid policy logic Andrew Cooper
2016-04-07 11:57 ` [PATCH v5 20/21] tools/libxc: Use featuresets rather than guesswork Andrew Cooper
2016-04-07 11:57 ` [PATCH v5 21/21] tools/libxc: Calculate xstate cpuid leaf from guest information Andrew Cooper
2016-04-07 12:58   ` Wei Liu
2016-04-08 21:00   ` Jan Beulich
2016-04-08 21:45     ` Andrew Cooper
2016-04-08 22:38       ` Jan Beulich

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=1460030246-30153-12-git-send-email-andrew.cooper3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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).