On Fri Jan 23, 2026 at 7:35 PM CET, Andrew Cooper wrote:
> On 22/01/2026 4:49 pm, Alejandro Vallejo wrote:
>> Not a functional change now that cross-vendor guests are not launchable.
>>
>> Signed-off-by: Alejandro Vallejo <[email protected]>
>> ---
>> xen/arch/x86/msr.c | 6 ++----
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
>> index ad75a2e108..c9cc4f0692 100644
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -169,9 +169,9 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
>> *val)
>> break;
>>
>> case MSR_IA32_PLATFORM_ID:
>> - if ( !(cp->x86_vendor & X86_VENDOR_INTEL) ||
>> - !(boot_cpu_data.x86_vendor & X86_VENDOR_INTEL) )
>> + if ( cp->x86_vendor != X86_VENDOR_INTEL )
>> goto gp_fault;
>> +
>> rdmsrl(MSR_IA32_PLATFORM_ID, *val);
>> break;
>>
>> @@ -190,8 +190,6 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
>> *val)
>> * the guest.
>> */
>> if ( !(cp->x86_vendor & (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
>> - !(boot_cpu_data.x86_vendor &
>> - (X86_VENDOR_INTEL | X86_VENDOR_AMD)) ||
>> rdmsr_safe(MSR_AMD_PATCHLEVEL, val) )
>> goto gp_fault;
>> break;
>
> Hmm. Thinking about it, this would probably be cleaner to get rid of
> the cp->x86_vendor field entirely, and retain the boot_cpu_data side.
>
> Additionally, this would fix a minor problem I'm having cleaning up the
> CPUID code for XSAVE fixes, and provide better cache locality.
>
> ~Andrew
I'll replace it on the new version for consistency. I don't mind.
FYI, I'm planning to replace all occurences of this on a follow-up series with a
new cpu_vendor() helper (it's a simpler version evolved from the x86_vendor_is()
RFC I sent a while ago) to enhance DCE's ability to eliminate code. It is (I
hope) just a transient matter until all {x86_,}vendor field checks are replaced
by cpu_vendor().
Cheers,
Alejandro
