On Tue, 28 May 2024 11:16:59 -0700 "Chen, Zide" <zide.c...@intel.com> wrote:
> On 5/28/2024 2:23 AM, Igor Mammedov wrote: > > On Fri, 24 May 2024 13:00:14 -0700 > > Zide Chen <zide.c...@intel.com> wrote: > > > >> Currently, if running "-overcommit cpu-pm=on" on hosts that don't > >> have MWAIT support, the MWAIT/MONITOR feature is advertised to the > >> guest and executing MWAIT/MONITOR on the guest triggers #UD. > > > > this is missing proper description how do you trigger issue > > with reproducer and detailed description why guest sees MWAIT > > when it's not supported by host. > > If "overcommit cpu-pm=on" and "-cpu hpst" are present, as shown in the it's bette to provide full QEMU CLI and host/guest kernels used and what hardware was used if it's relevant so others can reproduce problem. > following, CPUID_EXT_MONITOR is set after x86_cpu_filter_features(), so > that it doesn't have a chance to check MWAIT against host features and > will be advertised to the guest regardless of whether it's supported by > the host or not. > > x86_cpu_realizefn() > x86_cpu_filter_features() > cpu_exec_realizefn() > kvm_cpu_realizefn > host_cpu_realizefn > host_cpu_enable_cpu_pm > env->features[FEAT_1_ECX] |= CPUID_EXT_MONITOR; > > > If it's not supported by the host, executing MONITOR or MWAIT > instructions from the guest triggers #UD, no matter MWAIT_EXITING > control is set or not. If I recall right, kvm was able to emulate mwait/monitor. So question is why it leads to exception instead?