On 5/15/2025 6:48 AM, Sean Christopherson wrote:
On Mon, Mar 24, 2025, Mingwei Zhang wrote:
+/*
- Currently invoked at VM creation to
- Check whether there are existing !exclude_guest events of PMU with
- PERF_PMU_CAP_MEDIATED_VPMU
- Set nr_mediated_pmu_vms to prevent !exclude_guest event creation on
- PMUs with PERF_PMU_CAP_MEDIATED_VPMU
- No impact for the PMU without PERF_PMU_CAP_MEDIATED_VPMU. The perf
- still owns all the PMU resources.
- */
+int perf_get_mediated_pmu(void) +{
- guard(mutex)(&perf_mediated_pmu_mutex);
- if (atomic_inc_not_zero(&nr_mediated_pmu_vms))
return 0;- if (atomic_read(&nr_include_guest_events))
return -EBUSY;- atomic_inc(&nr_mediated_pmu_vms);
- return 0;
+} +EXPORT_SYMBOL_GPL(perf_get_mediated_pmu);
IMO, all of the mediated PMU logic should be guarded with a Kconfig. I strongly suspect KVM x86 will be the only user for the foreseeable, e.g. arm64 is trending toward a partioned PMU approach, and subjecting other architectures to the (minor) overhead associated with e.g. nr_mediated_pmu_vms seems pointless. The other nicety is that it helps encapsulate the mediated PMU code, which for those of us that haven't been living and breathing this for the last few months, is immensely helpful.
I'm fine with this.
+void perf_put_mediated_pmu(void)
To avoid confusion with perf_put_guest_context() in future patches, I think it makes sense to go with something like perf_{create,release}_mediated_pmu(). I actually like the get/put terminology in isolation, but they look weird side-by-side.
Agree.