On Tue Feb 10, 2026 at 9:19 AM CET, Roger Pau Monné wrote: > On Fri, Feb 06, 2026 at 05:15:23PM +0100, Alejandro Vallejo wrote: >> While in principle it's possible to have a vendor virtualising another, >> this is fairly tricky in practice. Not doing so enables certain >> optimisations with regards to vendor checks in later patches. >> >> Signed-off-by: Alejandro Vallejo <[email protected]> >> --- >> Patch 1 from the cross-vendor series. Do not merge here. It's simply for >> consistency. >> --- >> xen/lib/x86/policy.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> 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) ) > > You possibly want to expand test-cpu-policy.c to add a small test to > ensure this works as expected? Not that it shouldn't, but it's > trivial to expand test_is_compatible_{success,failure}() to add a > small test for the vendor checking. > > Thanks, Roger.
I didn't consider it. I guess I could. What I'm thinking also is that this vendor check should probably check the encoded vendor (ebcx/ecx/edx) rather than the decoded one. Cheers, Alejandro
