Re: [PATCH v5 1/5] x86: Reject CPU policies with vendors other than the host's

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

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@xxxxxxx>
>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>>  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