diff mbox series

[8/8] x86/cpuid: Enable CPUID Faulting for the control domain

Message ID 20190911200504.5693-9-andrew.cooper3@citrix.com (mailing list archive)
State Superseded
Headers show
Series x86/cpuid: Switch to using XEN_DOMCTL_set_cpumsr_policy | expand

Commit Message

Andrew Cooper Sept. 11, 2019, 8:05 p.m. UTC
The domain builder no longer uses CPUID instructions for policy decisions.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Wei Liu <wl@xen.org>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
 xen/arch/x86/cpu/common.c | 19 ++-----------------
 1 file changed, 2 insertions(+), 17 deletions(-)

Comments

Jan Beulich Sept. 12, 2019, 9:07 a.m. UTC | #1
On 11.09.2019 22:05, Andrew Cooper wrote:
> The domain builder no longer uses CPUID instructions for policy decisions.

How certain are we that there are no other components left relying
on being able to see raw CPUID output in Dom0? Sadly customers are
often doing strange things, insisting that they're right in doing
so. For this reason I wonder whether, at least as a transitional
measure, we should have a command line option allowing to restore
prior behavior.

Jan
Andrew Cooper Sept. 12, 2019, 9:28 a.m. UTC | #2
On 12/09/2019 10:07, Jan Beulich wrote:
> On 11.09.2019 22:05, Andrew Cooper wrote:
>> The domain builder no longer uses CPUID instructions for policy decisions.
> How certain are we that there are no other components left relying
> on being able to see raw CPUID output in Dom0?

Cstates and Turbo are the ones already accounted for, but we are going
to have to do something less broken than the current behaviour for PVH Dom0.

> Sadly customers are
> often doing strange things, insisting that they're right in doing
> so. For this reason I wonder whether, at least as a transitional
> measure, we should have a command line option allowing to restore
> prior behavior.

Hmm ok.

~Andrew
diff mbox series

Patch

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 8de4a44c1a..2e883835b8 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -168,23 +168,8 @@  void ctxt_switch_levelling(const struct vcpu *next)
 		 */
 		if (nextd && is_idle_domain(nextd))
 			return;
-		/*
-		 * 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_control_domain(nextd) &&
+
+		set_cpuid_faulting(nextd &&
 				   (is_pv_domain(nextd) ||
 				    next->arch.msrs->
 				    misc_features_enables.cpuid_faulting));