On 11/19/2024 10:00 PM, Sean Christopherson wrote:
> On Thu, Aug 01, 2024, Mingwei Zhang wrote:
>> This series contains perf interface improvements to address Peter's
>> comments. In addition, fix several bugs for v2. This version is based on
>> 6.10-rc4. The main changes are:
>>
>> - Use atomics to replace refcounts to track the nr_mediated_pmu_vms.
>> - Use the generic ctx_sched_{in,out}() to switch PMU resources when a
>> guest is entering and exiting.
>> - Add a new EVENT_GUEST flag to indicate the context switch case of
>> entering and exiting a guest. Updates the generic ctx_sched_{in,out}
>> to specifically handle this case, especially for time management.
>> - Switch PMI vector in perf_guest_{enter,exit}() as well. Add a new
>> driver-specific interface to facilitate the switch.
>> - Remove the PMU_FL_PASSTHROUGH flag and uses the PASSTHROUGH pmu
>> capability instead.
>> - Adjust commit sequence in PERF and KVM PMI interrupt functions.
>> - Use pmc_is_globally_enabled() check in emulated counter increment [1]
>> - Fix PMU context switch [2] by using rdpmc() instead of rdmsr().
>>
>> AMD fixes:
>> - Add support for legacy PMU MSRs in MSR interception.
>> - Make MSR usage consistent if PerfMonV2 is available.
>> - Avoid enabling passthrough vPMU when local APIC is not in kernel.
>> - increment counters in emulation mode.
>>
>> This series is organized in the following order:
>>
>> Patches 1-3:
>> - Immediate bug fixes that can be applied to Linux tip.
>> - Note: will put immediate fixes ahead in the future. These patches
>> might be duplicated with existing posts.
>> - Note: patches 1-2 are needed for AMD when host kernel enables
>> preemption. Otherwise, guest will suffer from softlockup.
>>
>> Patches 4-17:
>> - Perf side changes, infra changes in core pmu with API for KVM.
>>
>> Patches 18-48:
>> - KVM mediated passthrough vPMU framework + Intel CPU implementation.
>>
>> Patches 49-58:
>> - AMD CPU implementation for vPMU.
> Please rename everything in KVM to drop "passthrough" and simply use "mediated"
> for the overall concept. This is not a passthrough setup by any stretch of the
> word. I realize it's a ton of renaming, but calling this "passthrough" is very
> misleading and actively harmful for unsuspecting readers.
Sure.
>
> For helpers and/or comments that deal with intercepting (or not) MSRs, use
> "intercept" and appropriate variations. E.g. intel_pmu_update_msr_intercepts().
Sure.
>
> And for RDPMC, maybe kvm_rdpmc_in_guest() to follow kvm_{hlt,mwait,pause,cstate_in_guest()?
> I don't love the terminology, but there's a lot of value in being consistent
> throughout KVM.
Sure.
>
> I am not willing to budge on this, at all.
>
> I'm ok with the perf side of things using "passthrough" if "mediated" feels weird
> in that context and we can't come up with a better option, but for the KVM side,
> "passthrough" is simply wrong.
Kan, what's you idea on perf side's naming? I prefer unified naming in the
whole patchset.
