linux-kernel - Re: [PATCH v2 03/13] perf/x86/amd: add AMD Fam19h Branch Sampling support

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YZZE+bPCokVrTARM@hirez.programming.kicks-ass.net>
Date:   Thu, 18 Nov 2021 13:20:09 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Stephane Eranian <eranian@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kim.phillips@....com,
        acme@...hat.com, jolsa@...hat.com, songliubraving@...com,
        mpe@...erman.id.au, maddy@...ux.ibm.com
Subject: Re: [PATCH v2 03/13] perf/x86/amd: add AMD Fam19h Branch Sampling
 support

On Tue, Nov 16, 2021 at 11:23:39PM -0800, Stephane Eranian wrote:
> On Tue, Nov 16, 2021 at 12:29 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > On Mon, Nov 15, 2021 at 11:48:01PM -0800, Stephane Eranian wrote:
> > > On Fri, Nov 12, 2021 at 8:02 AM Peter Zijlstra <peterz@...radead.org> wrote:
> > > >
> > > > On Thu, Nov 11, 2021 at 12:44:05AM -0800, Stephane Eranian wrote:
> > > > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> > > > > index 38b2c779146f..28559557f966 100644
> > > > > --- a/arch/x86/events/core.c
> > > > > +++ b/arch/x86/events/core.c
> > > > > @@ -683,11 +683,16 @@ void x86_pmu_disable_all(void)
> > > > >
> > > > >               if (!test_bit(idx, cpuc->active_mask))
> > > > >                       continue;
> > > > > +
> > > > > +             if (is_amd_brs(hwc))
> > > > > +                     amd_brs_disable();
> > > > > +
> > > > >               rdmsrl(x86_pmu_config_addr(idx), val);
> > > > >               if (!(val & ARCH_PERFMON_EVENTSEL_ENABLE))
> > > > >                       continue;
> > > > >               val &= ~ARCH_PERFMON_EVENTSEL_ENABLE;
> > > > >               wrmsrl(x86_pmu_config_addr(idx), val);
> > > > > +
> > > > >               if (is_counter_pair(hwc))
> > > > >                       wrmsrl(x86_pmu_config_addr(idx + 1), 0);
> > > > >       }
> > > >
> > > > Please, stick that in amd_pmu_disable_all().
> > >
> > >
> > > If I do that, I need to add a for_each_counter() loop to
> > > amd_pmu_disable_all() but it does not have one call systematically.
> > > If you are okay with it, then I am fine as well.
> >
> > Why ? There is only one BRS you can disable it first, and then do the
> > loop. Same on the enable_all side, enable it once, not per event.
> > ->add/->del can keep a per-event count for sharing purposes, but you
> > don't need that for {en,dis}able_all, right?
> 
> Ok, I made the changes you suggested. It looks closer to the way LBR is handled.
> However, this means that there is no path by which you can get to
> amd_pmu_disable_event()
> without having gone through amd_pmu_disable_all(). Is that always the
> case? And same thing
> on the enable side.

So that's true for ->add() and ->del(), those cannot be called without
being wrapped in ->pmu_disable(), ->pmu_enable().

There is however the ->stop() and ->start() usage for throttling, which
can stop an individual event (while leaving the event scheduled on the
PMU). Now, I think the ->stop() gets called with the PMU enabled, but
the ->start() is with it disabled again.

The ramification would be that we'd stop the event, but leave BRS
enabled for a throttled event. Which should be harmless, no?