On Mon, 13 May 2019 at 21:35, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: > > 2019-05-13 17:46+0800, Wanpeng Li: > > From: Wanpeng Li <wanpengli@xxxxxxxxxxx> > > > > MSR IA32_MSIC_ENABLE bit 18, according to SDM: > > > > | When this bit is set to 0, the MONITOR feature flag is not set (CPUID.01H:ECX[bit 3] = 0). > > | This indicates that MONITOR/MWAIT are not supported. > > | > > | Software attempts to execute MONITOR/MWAIT will cause #UD when this bit is 0. > > | > > | When this bit is set to 1 (default), MONITOR/MWAIT are supported (CPUID.01H:ECX[bit 3] = 1). > > > > This bit should be set to 1, if BIOS enables MONITOR/MWAIT support on host and > > we intend to expose mwait/monitor to the guest. > > The CPUID.01H:ECX[bit 3] ought to mirror the value of the MSR bit and > as userspace has control of them both, I'd argue that it is userspace's > job to configure both bits to match on the initial setup. > > Also, CPUID.01H:ECX[bit 3] is a better guard than kvm_mwait_in_guest(). > kvm_mwait_in_guest() affects the behavior of MONITOR/MWAIT, not its > guest visibility. > Some weird migration cases might want MONITOR in CPUID without > kvm_mwait_in_guest() and the MSR should be correct there as well. > > Missing the MSR bit shouldn't be a big problem for guests, so I am in > favor of fixing the userspace code. > > Thanks. > > (For extra correctness in KVM, we could implement toggling of the CPUID > bit based on guest writes to the MSR.) Do it in v2 and a separate qemu patch, thanks for your review. Regards, Wanpeng Li
