[Xen-devel] [PATCH 8/8] x86/cpuid: Enable CPUID Faulting for the control domain

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

The domain builder no longer uses CPUID instructions for policy decisions.

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

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));
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel