On Wed, Aug 20, 2025, Chao Gao wrote: > >> + case MSR_IA32_PL0_SSP ... MSR_IA32_INT_SSP_TAB: > >> + if (!guest_cpu_cap_has(vcpu, X86_FEATURE_SHSTK)) > >> + return KVM_MSR_RET_UNSUPPORTED; > >> + if (is_noncanonical_msr_address(data, vcpu)) > > > >This emulation is wrong (in no small part because the architecture sucks). From > >the SDM: > > > > If the processor does not support Intel 64 architecture, these fields have only > > 32 bits; bits 63:32 of the MSRs are reserved. > > > > On processors that support Intel 64 architecture this value cannot represent a > > non-canonical address. > > > > In protected mode, only 31:0 are loaded. > > > >That means KVM needs to drop bits 63:32 if the vCPU doesn't have LM or if the vCPU > >isn't in 64-bit mode. The last one is especially frustrating, because software > >can still get a 64-bit value into the MSRs while running in protected, e.g. by > >switching to 64-bit mode, doing WRMSRs, then switching back to 32-bit mode. > > > >But, there's probably no point in actually trying to correctly emulate/virtualize > >the Protected Mode behavior, because the MSRs can be written via XRSTOR, and to > >close that hole KVM would need to trap-and-emulate XRSTOR. No thanks. > > I don't get why we need to trap-and-emulate XRSTOR. if XRSTOR instruction in > protection mode can change higher 32 bits of CET MSRs, it is the hardware > behavior. why KVM needs to clear the higher 32 bits? If the VMM configures the virtual CPU model to be a 32-bit CPU, i.e. a vCPU that "does not support Intel 64 architecture", i.e. CPUID.0x80000001.EDX.LM = 0, then the behavior of the "hardware" that the guest sees should be that the upper 32 bits do not exist and should always read '0'. But because the actual harware on which the virtual CPU is running _does_ support Intel 64, XRSTORS/XSAVES in the guest could observe behavior that violates the architecture.
