While in principle it's possible to have a vendor virtualising another, this is fairly tricky in practice and comes with the world's supply of security issues.
Reject any CPU policy with vendors not matching the host's. Signed-off-by: Alejandro Vallejo <[email protected]> --- v2: * Reversed polarity of leaf0 check in policy compatibility helper. * Reworded changelog entry in terms of LM + save/restore. --- CHANGELOG.md | 5 +++++ xen/lib/x86/policy.c | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 18f3d10f20..426c0bce67 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -22,6 +22,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Xenoprofile support. Oprofile themselves removed support for Xen in 2014 prior to the version 1.0 release, and there has been no development since before then in Xen. + - Domains can no longer run on a CPU vendor if they were initially launched + on a different CPU vendor. This affects live migrations and save/restore + workflows accross mixed-vendor hosts. Cross-vendor emulation has always + been unreliable, but since 2017 with the advent of speculation security it + became unsustainably so. - Removed xenpm tool on non-x86 platforms as it doesn't actually provide anything useful outside of x86. diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c index f033d22785..079c42a29b 100644 --- a/xen/lib/x86/policy.c +++ b/xen/lib/x86/policy.c @@ -15,7 +15,8 @@ int x86_cpu_policies_are_compatible(const struct cpu_policy *host, #define FAIL_MSR(m) \ do { e.msr = (m); goto out; } while ( 0 ) - if ( guest->basic.max_leaf > host->basic.max_leaf ) + if ( (guest->x86_vendor != host->x86_vendor) || + (guest->basic.max_leaf > host->basic.max_leaf) ) FAIL_CPUID(0, NA); if ( guest->feat.max_subleaf > host->feat.max_subleaf ) -- 2.43.0
