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

[Alejandro Vallejo <alejandro.garciavallejo@amd.com>]

On Thu Jan 22, 2026 at 6:13 PM CET, Teddy Astie wrote:
> Le 22/01/2026 à 17:51, Alejandro Vallejo a écrit :
>> 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>
>> ---
>>   CHANGELOG.md         | 4 ++++
>>   xen/lib/x86/policy.c | 3 ++-
>>   2 files changed, 6 insertions(+), 1 deletion(-)
>> 
>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>> index 18f3d10f20..eae2f961c7 100644
>> --- a/CHANGELOG.md
>> +++ b/CHANGELOG.md
>> @@ -22,6 +22,10 @@ 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.  Refuse to start domains whose CPU vendor differs> +     from the host so that security mitigations stay consistent. 
> Cross-vendor

???

>> +     setups have been unreliable and not practical since 2017 with the advent of
>> +     speculation security.
>>   
>
> I don't really like the wording, it sounds like guest will suddenly stop 
> to work for some reason. AFAIK, in the Xen Project only suspend/resume 
> logic is going to be affected, and we probably want to reflect on that 
> instead.

You also won't be able to start a cross vendor VM, which you can do by
manually picking the CPUID leaves in xl.cfg. Though you're right that for the
overwhelming majority of affected users this would manifest as not being able to
restore a saved VM (or not being able to live-migrate, which is effectively the
same thing for this purpose). It's unlikely anyone abuses xl the way I
described.

I'll reword it differently to note the overwhelmingly most affected workflow.

>
>>    - 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..4c0c5386ea 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->basic.max_leaf >  host->basic.max_leaf) ||
>> +         (guest->x86_vendor     != host->x86_vendor) )
>>           FAIL_CPUID(0, NA);
>>   
>>       if ( guest->feat.max_subleaf > host->feat.max_subleaf )
>
>
>
> --
> Teddy Astie | Vates XCP-ng Developer
>
> XCP-ng & Xen Orchestra - Vates solutions
>
> web: https://vates.tech