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 <alejandro.garciavallejo@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
CHANGELOG.md | 5 +++++
tools/tests/cpu-policy/test-cpu-policy.c | 27 ++++++++++++++++++++++++
xen/arch/x86/lib/cpu-policy/policy.c | 5 ++++-
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index c191e504aba..90ba5da69e4 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -23,6 +23,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 system with CPUs of a vendor different from
+ the one they were initially launched on. This affects live migrations and
+ save/restore workflows across 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/tools/tests/cpu-policy/test-cpu-policy.c b/tools/tests/cpu-policy/test-cpu-policy.c
index 301df2c0028..88a9a26e8f1 100644
--- a/tools/tests/cpu-policy/test-cpu-policy.c
+++ b/tools/tests/cpu-policy/test-cpu-policy.c
@@ -586,6 +586,19 @@ static void test_is_compatible_success(void)
.platform_info.cpuid_faulting = true,
},
},
+ {
+ .name = "Host CPU vendor == Guest CPU vendor (both unknown)",
+ .host = {
+ .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1,
+ .basic.vendor_ecx = X86_VENDOR_AMD_ECX,
+ .basic.vendor_edx = X86_VENDOR_AMD_EDX,
+ },
+ .guest = {
+ .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1,
+ .basic.vendor_ecx = X86_VENDOR_AMD_ECX,
+ .basic.vendor_edx = X86_VENDOR_AMD_EDX,
+ },
+ },
};
struct cpu_policy_errors no_errors = INIT_CPU_POLICY_ERRORS;
@@ -629,6 +642,20 @@ static void test_is_compatible_failure(void)
},
.e = { -1, -1, 0xce },
},
+ {
+ .name = "Host CPU vendor != Guest CPU vendor (both unknown)",
+ .host = {
+ .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 1,
+ .basic.vendor_ecx = X86_VENDOR_AMD_ECX,
+ .basic.vendor_edx = X86_VENDOR_AMD_EDX,
+ },
+ .guest = {
+ .basic.vendor_ebx = X86_VENDOR_AMD_EBX + 2,
+ .basic.vendor_ecx = X86_VENDOR_AMD_ECX,
+ .basic.vendor_edx = X86_VENDOR_AMD_EDX,
+ },
+ .e = { 0, -1, -1 },
+ },
};
printf("Testing policy compatibility failure:\n");
diff --git a/xen/arch/x86/lib/cpu-policy/policy.c b/xen/arch/x86/lib/cpu-policy/policy.c
index f033d22785b..f991b1f3a96 100644
--- a/xen/arch/x86/lib/cpu-policy/policy.c
+++ b/xen/arch/x86/lib/cpu-policy/policy.c
@@ -15,7 +15,10 @@ 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->basic.vendor_ebx != host->basic.vendor_ebx) ||
+ (guest->basic.vendor_ecx != host->basic.vendor_ecx) ||
+ (guest->basic.vendor_edx != host->basic.vendor_edx) ||
+ (guest->basic.max_leaf > host->basic.max_leaf) )
FAIL_CPUID(0, NA);
if ( guest->feat.max_subleaf > host->feat.max_subleaf )
--
2.43.0On 12/03/2026 11:21 am, Alejandro Vallejo wrote: > 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 <alejandro.garciavallejo@amd.com> > Reviewed-by: Jan Beulich <jbeulich@suse.com> > --- > CHANGELOG.md | 5 +++++ > tools/tests/cpu-policy/test-cpu-policy.c | 27 ++++++++++++++++++++++++ > xen/arch/x86/lib/cpu-policy/policy.c | 5 ++++- > 3 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index c191e504aba..90ba5da69e4 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -23,6 +23,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 system with CPUs of a vendor different from > + the one they were initially launched on. This affects live migrations and > + save/restore workflows across mixed-vendor hosts. Cross-vendor emulation > + has always been unreliable, but since 2017 with the advent of speculation > + security it became unsustainably so. c/s 0f1cb96e9785294f149ab3c7feb90c0eb9daeede was when it got added to Xen. I'm certain there's a whitepaper somewhere from AMD about this, but I can't locate it. It was partly marketing about how you could buy AMD hardware (which was cheaper) and live-migrate your Intel VMs without interruption. It would have been nice to find for posterity. For the changelog, can I suggest this: diff --git a/CHANGELOG.md b/CHANGELOG.md index c191e504aba9..377711d40953 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -23,6 +23,12 @@ 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. + - Cross-vendor support; guests can now only be configured as the same + vendor as the host CPU. When added back in 2009, with enough trickery + Intel and AMD CPUs could be made to be compatible enough to live migrate + a guest, but the vendors have been diverging since then in ways that Xen + cannot compensate for, and the advent of speculative security issues has + put to rest any possibility of this being a viable option. - Removed xenpm tool on non-x86 platforms as it doesn't actually provide anything useful outside of x86. which is closer to the style of the surrounding bullet points. Also s/domain/guest/ which is a subtle but important distinction made by the Security Team when discussing configurations. ~Andrew
On Thu Mar 12, 2026 at 10:01 PM CET, Andrew Cooper wrote: > On 12/03/2026 11:21 am, Alejandro Vallejo wrote: >> 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 <alejandro.garciavallejo@amd.com> >> Reviewed-by: Jan Beulich <jbeulich@suse.com> >> --- >> CHANGELOG.md | 5 +++++ >> tools/tests/cpu-policy/test-cpu-policy.c | 27 ++++++++++++++++++++++++ >> xen/arch/x86/lib/cpu-policy/policy.c | 5 ++++- >> 3 files changed, 36 insertions(+), 1 deletion(-) >> >> diff --git a/CHANGELOG.md b/CHANGELOG.md >> index c191e504aba..90ba5da69e4 100644 >> --- a/CHANGELOG.md >> +++ b/CHANGELOG.md >> @@ -23,6 +23,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 system with CPUs of a vendor different from >> + the one they were initially launched on. This affects live migrations and >> + save/restore workflows across mixed-vendor hosts. Cross-vendor emulation >> + has always been unreliable, but since 2017 with the advent of speculation >> + security it became unsustainably so. > > c/s 0f1cb96e9785294f149ab3c7feb90c0eb9daeede was when it got added to Xen. > > I'm certain there's a whitepaper somewhere from AMD about this, but I > can't locate it. It was partly marketing about how you could buy AMD > hardware (which was cheaper) and live-migrate your Intel VMs without > interruption. It would have been nice to find for posterity. > > For the changelog, can I suggest this: > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index c191e504aba9..377711d40953 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -23,6 +23,12 @@ 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. > + - Cross-vendor support; guests can now only be configured as the same > + vendor as the host CPU. When added back in 2009, with enough trickery > + Intel and AMD CPUs could be made to be compatible enough to live migrate > + a guest, but the vendors have been diverging since then in ways that Xen > + cannot compensate for, and the advent of speculative security issues has > + put to rest any possibility of this being a viable option. > > - Removed xenpm tool on non-x86 platforms as it doesn't actually provide > anything useful outside of x86. > > > which is closer to the style of the surrounding bullet points. Also > s/domain/guest/ which is a subtle but important distinction made by the > Security Team when discussing configurations. Sure on both accounts. I don't mind the contents so long as there is any. Should I consider these on the "doable on commit" camp? Or do you want a v6? Cheers, Alejandro
© 2016 - 2026 Red Hat, Inc.