lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YEaLzKWd0wAmdqvs@google.com>
Date:   Mon, 8 Mar 2021 12:40:44 -0800
From:   Sean Christopherson <seanjc@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "Xu, Like" <like.xu@...el.com>, Dmitry Vyukov <dvyukov@...gle.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        Like Xu <like.xu@...ux.intel.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Jim Mattson <jmattson@...gle.com>, kvm@...r.kernel.org,
        "Thomas Gleixner
        (x86/pti/timer/core/smp/irq/perf/efi/locking/ras/objtool)
        (x86@...nel.org)" <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] x86/perf: Fix guest_get_msrs static call if there is no
 PMU

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ