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 <[email protected]>
---
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
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
