7a0 is an integer field, not a mask - taking the logical and of the hardware
and policy values results in nonsense. Instead, take the policy value
directly.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
---
CC: Jan Beulich <jbeul...@suse.com>
CC: Wei Liu <w...@xen.org>
CC: Roger Pau Monné <roger....@citrix.com>
Even Rome hardware has 7[0].eax still as 0, and there is no sensible reason to
set max_subleaf higher at this point, so this is only a latent bug for now.
---
xen/arch/x86/domctl.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 1e98fc8009..35ad8cb51c 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -218,11 +218,16 @@ static int update_domain_cpuid_info(struct domain *d,
if ( is_pv_domain(d) && ((levelling_caps & LCAP_7ab0) == LCAP_7ab0) )
{
uint64_t mask = cpuidmask_defaults._7ab0;
- uint32_t eax = ctl->eax;
- uint32_t ebx = p->feat._7b0;
- if ( boot_cpu_data.x86_vendor & (X86_VENDOR_AMD |
X86_VENDOR_HYGON) )
- mask &= ((uint64_t)eax << 32) | ebx;
+ /*
+ * Leaf 7[0].eax is max_subleaf, not a feature mask. Take it
+ * wholesale from the policy, but clamp the features in 7[0].ebx
+ * per usual.
+ */
+ if ( boot_cpu_data.x86_vendor &
+ (X86_VENDOR_AMD | X86_VENDOR_HYGON) )
+ mask = (((uint64_t)p->feat.max_subleaf << 32) |
+ ((uint32_t)mask | p->feat._7b0));
d->arch.pv.cpuidmasks->_7ab0 = mask;
}
--
2.11.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
