On 8/19/2025 9:09 AM, Sean Christopherson 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.
Unless someone has a better idea, I'm inclined to take an erratum for this, i.e.
just sweep it under the rug.
Since WRMSR (WRMSRNS) and XRSTORS are the two instructions that write to
MSRs in CPL0, Why KVM doesn't use the XSS-exiting bitmap?
