On Mon, Mar 08, 2021, Peter Zijlstra wrote:
> On Mon, Mar 08, 2021 at 10:25:59AM +0800, Xu, Like wrote:
> > On 2021/3/6 6:33, Sean Christopherson wrote:
> > > Handle a NULL x86_pmu.guest_get_msrs at invocation instead of patching
> > > in perf_guest_get_msrs_nop() during setup. If there is no PMU, setup
> >
> > "If there is no PMU" ...
>
> Then you shouldn't be calling this either ofcourse :-)
This effectively is KVM's check to find out there is no PMU. I certainly don't
want to replicate the switch statement in init_hw_perf_events(), plus whatever
is buried in check_hw_exists(). The alternative would be to add X86_FEATURE_PMU
so that KVM can easily check for PMU existence. I don't really see the point
though, as bare metal KVM, where we really care about performance, is likely to
have a functional PMU, and if it doesn't then I doubt whoever is running KVM
cares much about performance.
> > > @@ -671,7 +671,11 @@ void x86_pmu_disable_all(void)
> > > struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
> > > {
> > > - return static_call(x86_pmu_guest_get_msrs)(nr);
> > > + if (x86_pmu.guest_get_msrs)
> > > + return static_call(x86_pmu_guest_get_msrs)(nr);
> >
> > How about using "static_call_cond" per commit "452cddbff7" ?
>
> Given the one user in atomic_switch_perf_msrs() that should work because
> it doesn't seem to care about nr_msrs when !msrs.
Uh, that commit quite cleary says:
NOTE: this is 'obviously' limited to functions with a 'void' return type.
Even if we somehow bypass the (void) cast, IIUC it will compile to a single
'ret', and return whatever happens to be in RAX, not NULL as is needed.
> Still, it calling atomic_switch_perf_msrs() and
> intel_pmu_lbr_is_enabled() when there isn't a PMU at all is of course, a
