On Mon, Mar 24, 2025, Mingwei Zhang wrote:
> static void kvm_pmu_incr_counter(struct kvm_pmc *pmc)
> {
> - pmc->emulated_counter++;
> - kvm_pmu_request_counter_reprogram(pmc);
> + struct kvm_vcpu *vcpu = pmc->vcpu;
> +
> + /*
> + * For perf-based PMUs, accumulate software-emulated events separately
> + * from pmc->counter, as pmc->counter is offset by the count of the
> + * associated perf event. Request reprogramming, which will consult
> + * both emulated and hardware-generated events to detect overflow.
> + */
> + if (!kvm_mediated_pmu_enabled(vcpu)) {
> + pmc->emulated_counter++;
> + kvm_pmu_request_counter_reprogram(pmc);
> + return;
> + }
> +
> + /*
> + * For mediated PMUs, pmc->counter is updated when the vCPU's PMU is
> + * put, and will be loaded into hardware when the PMU is loaded. Simply
> + * increment the counter and signal overflow if it wraps to zero.
> + */
> + pmc->counter = (pmc->counter + 1) & pmc_bitmask(pmc);
> + if (!pmc->counter) {
Ugh, this is broken for the fastpath. If kvm_skip_emulated_instruction() is
invoked by handle_fastpath_set_msr_irqoff() or handle_fastpath_hlt(), KVM may
consume stale information (GLOBAL_CTRL, GLOBAL_STATUS and PMCs), and even if KVM
gets lucky and those are all fresh, the PMC and GLOBAL_STATUS changes won't be
propagated back to hardware.
The best idea I have is to track whether or not the guest may be counting branches
and/or instruction based on eventsels, and then bail from fastpaths that need to
skip instructions. That flag would also be useful to further optimize
kvm_pmu_trigger_event().
> + pmc_to_pmu(pmc)->global_status |= BIT_ULL(pmc->idx);
> + if (pmc_pmi_enabled(pmc))
> + kvm_make_request(KVM_REQ_PMI, vcpu);
> + }
> }
>
> static inline bool cpl_is_matched(struct kvm_pmc *pmc)
> --
> 2.49.0.395.g12beb8f557-goog
>
