On Thu, Apr 11, 2024, Sean Christopherson wrote: > On Thu, Apr 11, 2024, Jim Mattson wrote: > > On Thu, Apr 11, 2024 at 10:21 AM Liang, Kan <kan.liang@xxxxxxxxxxxxxxx> wrote: > > > On 2024-04-11 1:04 p.m., Sean Christopherson wrote: > > > > On Fri, Jan 26, 2024, Xiong Zhang wrote: > > > >> From: Kan Liang <kan.liang@xxxxxxxxxxxxxxx> > > > >> > > > >> Define and apply the PERF_PMU_CAP_VPMU_PASSTHROUGH flag for the version 4 > > > >> and later PMUs > > > > > > > > Why? I get that is an RFC, but it's not at all obvious to me why this needs to > > > > take a dependency on v4+. > > > > > > The IA32_PERF_GLOBAL_STATUS_RESET/SET MSRs are introduced in v4. They > > > are used in the save/restore of PMU state. Please see PATCH 23/41. > > > So it's limited to v4+ for now. > > > > Prior to version 4, semi-passthrough is possible, but IA32_PERF_GLOBAL_STATUS > > has to be intercepted and emulated, since it is non-trivial to set bits in > > this MSR. > > Ah, then this _perf_ capability should be PERF_PMU_CAP_WRITABLE_GLOBAL_STATUS or And now I see that the capabilities are arch agnostic, whereas GLOBAL_STATUS obviously is not. Unless a writable GLOBAL_STATUS is a hard requirement for perf to be able to support a mediated PMU, this capability probably doesn't need to exist, e.g. KVM can check for a writable GLOBAL_STATUS just as easily as perf (or perf can stuff x86_pmu_capability.writable_global_status directly).
