Re: [PATCH] x86/perf: Fix guest_get_msrs static call if there is no PMU

[Sean Christopherson]

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