[Xen-changelog] [xen master] x86/cpuid: Fix feature flags reported to dom0

[patchbot@xxxxxxx]

commit 38b1c3a5affbe3451f366576aef9c7149d62de04
Author:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Thu Jan 12 16:14:56 2017 +0000
Commit:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CommitDate: Fri Jan 13 13:16:57 2017 +0000

    x86/cpuid: Fix feature flags reported to dom0
    
    c/s a11e8c9 "x86/pv: Use per-domain policy information in pv_cpuid()" 
switched
    PV domains from using a (hardware for dom0, toolstack-chosen from domU) 
value
    masked against pv_featureset[], to actually using the value calculated by
    recalculate_cpuid_policy().
    
    For domU, this is no practical change as the content is still chosen by the
    toolstack.  For dom0 however, we no longer have two sources of information
    potentially clearing bits.  Modern Linux seems to care about having 
CMP_LEGACY
    set in its view of CPUID on an Intel box.
    
    The deliberate setting of HTT, X2APIC and CMP_LEGACY in 
{pv,hvm}_featureset[]
    is necessary for domUs, as the toolstack may have (tried to) set up topology
    information in a different representation than the hardware uses.  The bits
    therefore needed to be set in the masks used in the older logic, to avoid
    clobbering the toolstacks information.
    
    Move the HTT/X2APIC/CMP_LEGACY logic from calculate_{pv,hvm}_max_policy()
    (where the meaning of {pv,hvm}_featureset[] has changed subtly) to
    recalculate_cpuid_policy() where the masking logic now lives.
    
    This will cause {pv,hvm}_max_policy to actually contain real hardware values
    (so dom0 sees real hardware values), but still allows the toolstack to set
    bits not present in real hardware for domUs.
    
    Reported-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Tested-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
---
 xen/arch/x86/cpuid.c | 24 ++++++++----------------
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index b685874..1e5013d 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -164,14 +164,6 @@ static void __init calculate_pv_max_policy(void)
     /* Unconditionally claim to be able to set the hypervisor bit. */
     __set_bit(X86_FEATURE_HYPERVISOR, pv_featureset);
 
-    /*
-     * Allow the toolstack to set HTT, X2APIC and CMP_LEGACY.  These bits
-     * affect how to interpret topology information in other cpuid leaves.
-     */
-    __set_bit(X86_FEATURE_HTT, pv_featureset);
-    __set_bit(X86_FEATURE_X2APIC, pv_featureset);
-    __set_bit(X86_FEATURE_CMP_LEGACY, pv_featureset);
-
     sanitise_featureset(pv_featureset);
     cpuid_featureset_to_policy(pv_featureset, p);
 }
@@ -199,14 +191,6 @@ static void __init calculate_hvm_max_policy(void)
     __set_bit(X86_FEATURE_HYPERVISOR, hvm_featureset);
 
     /*
-     * Allow the toolstack to set HTT, X2APIC and CMP_LEGACY.  These bits
-     * affect how to interpret topology information in other cpuid leaves.
-     */
-    __set_bit(X86_FEATURE_HTT, hvm_featureset);
-    __set_bit(X86_FEATURE_X2APIC, hvm_featureset);
-    __set_bit(X86_FEATURE_CMP_LEGACY, hvm_featureset);
-
-    /*
      * Xen can provide an APIC emulation to HVM guests even if the host's APIC
      * isn't enabled.
      */
@@ -301,6 +285,14 @@ void recalculate_cpuid_policy(struct domain *d)
     }
 
     /*
+     * Allow the toolstack to set HTT, X2APIC and CMP_LEGACY.  These bits
+     * affect how to interpret topology information in other cpuid leaves.
+     */
+    __set_bit(X86_FEATURE_HTT, max_fs);
+    __set_bit(X86_FEATURE_X2APIC, max_fs);
+    __set_bit(X86_FEATURE_CMP_LEGACY, max_fs);
+
+    /*
      * 32bit PV domains can't use any Long Mode features, and cannot use
      * SYSCALL on non-AMD hardware.
      */
--
generated by git-patchbot for /home/xen/git/xen.git#master

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog