[Devel] [PATCH 1/1] x86/kvm: skip PMU event trigger when guest PMU is disabled

[Konstantin Khorenko]

0. are you going to send this patch upstream?
    Please create a task, i do not see a cloned task for that.
    And when sending upstream, quite probably we'll have to remove "unlikely":
    what is the default for upstream regarding PMU: disabled or enabled?

1. for which tree you you have prepared this patch?
    Please use [PATCH vz10 1/1] format
    i assume it's for vz10 and the patch does not apply.

      git apply --check fails on arch/x86/kvm/x86.c:8877.

The hunk removes kvm_pmu_trigger_event(vcpu, PERF_COUNT_HW_INSTRUCTIONS);,
but since upstream commit f19063b1ca058 ("KVM: x86/pmu: Snapshot event selectors that KVM emulates in 
software") the tree carries:

    arch/x86/kvm/x86.c lines 8960-8960

       kvm_pmu_trigger_event(vcpu, kvm_pmu_eventsel.INSTRUCTIONS_RETIRED);


2. Gate the other three kvm_pmu_trigger_event() call sites for consistency.

      The same dead-weight argument applies verbatim to:
     • x86_emulate_instruction() - arch/x86/kvm/x86.c:9286 (INSTRUCTIONS_RETIRED)
     • x86_emulate_instruction() - arch/x86/kvm/x86.c:9288 (BRANCH_INSTRUCTIONS_RETIRED)
     • nested_vmx_run() - arch/x86/kvm/vmx/nested.c:3687 (BRANCH_INSTRUCTIONS_RETIRED)

The CPUID-skip path is hottest, so ROI is highest there - but the remaining three are equally trivial 
to close and avoid a confusing "one gated, three not" state that will invite a follow-up VSTOR later. 
A plain if (...) at each site reads better than a wrapper helper.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

On 5/22/26 12:07, Denis V. Lunev wrote:
> kvm_skip_emulated_instruction() calls kvm_pmu_trigger_event() on every
> emulated-instruction skip (notably every CPUID exit) to feed the PMU
> INSTRUCTIONS_RETIRED counter. The function does a stack bitmap allocation,
> a bitmap_and against pmu->global_ctrl, indirect calls to pmc_event_is_allowed()
> and cpl_is_matched(), and an empty kvm_for_each_pmc() walk before returning
> when nothing is programmed. On guests with PMU disabled at the per-VM level
> (<pmu state='off'/>), all of this work is dead-weight and runs on every
> VMEXIT.
> 
> Guard the call with a check on kvm->arch.enable_pmu. The unlikely() hint
> keeps the hot exit path straight-line and places the (rarely-taken) call
> out-of-line for better I-cache density.
> 
> Measured on at_cpu_cpuid (-k 0, VSTOR-131579 methodology), guest PMU off,
> on top of a Nova-side default-PMU-off VM config:
> 
>    AMD Zen2 (epyc01, EPYC 7302):     +2.7%, ~57 cyc/VMEXIT saved
>    Intel Ice Lake-SP (hw-hdd01):     +0.6%, ~26 cyc/VMEXIT saved
> 
> The AMD bias is consistent with the per-call retpoline + unret + Safe-RET
> tax on Zen2/Zen3 with default mitigations: removing an entire call/return
> sequence from the AMD hot path saves more than the same removal on Intel
> with Enhanced/Auto IBRS. Same "retpoline fingerprint" identified in
> VSTOR-130475's branch-mispredict-rate analysis.
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-132543
> https://virtuozzo.atlassian.net/browse/VSTOR-132471
> 
> Feature: kvm
> Signed-off-by: Denis V. Lunev <den at openvz.org>
> ---
>   arch/x86/kvm/x86.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index a68259e4f66a..aa349adf7b90 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8877,7 +8877,8 @@ int kvm_skip_emulated_instruction(struct kvm_vcpu *vcpu)
>   	if (unlikely(!r))
>   		return 0;
>   
> -	kvm_pmu_trigger_event(vcpu, PERF_COUNT_HW_INSTRUCTIONS);
> +	if (unlikely(vcpu->kvm->arch.enable_pmu))
> +		kvm_pmu_trigger_event(vcpu, PERF_COUNT_HW_INSTRUCTIONS);
>   
>   	/*
>   	 * rflags is the old, "raw" value of the flags.  The new value has