On 23.01.2026 19:35, 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.
I was wondering of exactly this (particularly in the context here), so: +1. Jan > Additionally, this would fix a minor problem I'm having cleaning up the > CPUID code for XSAVE fixes, and provide better cache locality. > > ~Andrew
