On 6/5/2024 6:49 AM, Igor Mammedov wrote:
> On Mon, 3 Jun 2024 17:02:20 -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.
>>
>> Typically #UD takes priority over VM-Exit interception checks and
>> KVM doesn't emulate MONITOR/MWAIT. This causes the guest fail to
>> boot.
>>
>> V2:
>> - [PATCH 1]: took Thomas' suggestion for more generic fix
>> - [PATCH 2/3]: no changes
>>
>> V3:
>> - dropped [PATCH 1/3]. Took the simpler approach not to re-order
>> cpu_exec_realizefn() call.
>> - changed patch title in [PATCH V3 1/2]
>> - don't set CPUID_EXT_MONITOR in kvm_cpu_realizefn()
>
> on top of above we should make make
> -overcommit cpu-pm=on
> to error out if KVM_X86_DISABLE_EXITS_MWAIT is not supported/failed
>
> if we don't do this user gets false assumption that cpu-pm=on
> works as expected, and instead of effective CPU usage/IPI delivery
> all they get is a storm of mwait exits.
>
Agree. But seems it's quite complicated. Please refer to the comments on
[PATCH V2 2/3].
We may remove the "-overcommit cpu-pm", and similar to notify-vmexit,
add individual -accel options for flexibility and better cpu-pm control.
But will be over complicated?
KVM_X86_DISABLE_EXITS_MWAIT
KVM_X86_DISABLE_EXITS_HLT
KVM_X86_DISABLE_EXITS_PAUSE
KVM_X86_DISABLE_EXITS_CSTATE
>>
>> Zide Chen (2):
>> vl: Allow multiple -overcommit commands
>> target/i386: Advertise MWAIT iff host supports
>>
>> system/vl.c | 4 ++--
>> target/i386/host-cpu.c | 12 ------------
>> target/i386/kvm/kvm-cpu.c | 11 +++++++++--
>> 3 files changed, 11 insertions(+), 16 deletions(-)
>>
>
