Re: [RFC PATCH] KVM: x86: RFC for per-VM C-state policy enforcement (KVM_CAP_CSTATE_POLICY)

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] VM-Exits clear the CPU's monitor event pending flag, causing host-side MWAIT to immediately fall through (NOP).
- [High] Executing MWAIT synchronously within the KVM exit handler violates Linux scheduler and RCU invariants.
--

--- Patch [1]: [RFC PATCH] KVM: x86: RFC for per-VM C-state policy enforcement (KVM_CAP_CSTATE_POLICY) ---
commit ba053ea08a3b49a2e72662168226ef280171ed4d
Author: Anthony Harivel <aharivel@redhat.com>

KVM: x86: RFC for per-VM C-state policy enforcement (KVM_CAP_CSTATE_POLICY)

This RFC proposes KVM_CAP_CSTATE_POLICY, a new VM-scoped capability
that lets the host set a per-VM maximum C-state ceiling. When active,
KVM intercepts MWAIT, inspects the requested C-state, and enforces
the ceiling by executing a capped MWAIT on behalf of the guest.

> diff --git a/rfc/KVM_CAP_CSTATE_POLICY.txt b/rfc/KVM_CAP_CSTATE_POLICY.txt
> new file mode 100644
> index 0000000000000..15439e6e7ebbf
> --- /dev/null
> +++ b/rfc/KVM_CAP_CSTATE_POLICY.txt

[ ... ]

> @@ -60,18 +60,18 @@
>  3. Internal flow
>  ----------------
>  
>  When max_cstate >= 0 (policy active):
>  
>    1. VMCS "MWAIT exiting" = 1 (intercept MWAIT).
>    2. On VM exit for MWAIT:
>       a. Extract the C-state hint from the MWAIT operand.
>       b. Map the hint to a logical C-state level (MWAIT sub-states
>          are CPU-family-specific; a translation table is needed).
>       c. If requested_cstate <= max_cstate: execute native MWAIT with
>          the guest's original hint.
>       d. If requested_cstate > max_cstate: execute MWAIT with the
>          capped hint, or return to guest immediately (C0).

[Severity: High]
Does executing native MWAIT on the host side work as intended here?

According to the Intel SDM (Vol 3, 27.5.5 Updates to Non-Register State),
a VM-Exit unconditionally clears the state of the monitor hardware.

Since the state established by the guest's preceding MONITOR instruction
is wiped out by the VM-Exit, won't the subsequent host-side MWAIT find no
armed monitor and immediately fall through as a NOP, resulting in a busy
wait loop instead of entering an idle power state?

[Severity: High]
If we execute MWAIT synchronously within the KVM exit handler, how does
this interact with the Linux scheduler and RCU?

If the CPU successfully enters a deep sleep state via an inline host
MWAIT, it seems the KVM vCPU thread would remain in the TASK_RUNNING
state without yielding via schedule() or notifying RCU via
rcu_idle_enter().

Could this hide the CPU's true idle status from the scheduler, break load
balancing, and stall RCU grace periods by bypassing the host cpuidle
framework?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715124235.1444895-1-aharivel@redhat.com?part=1