[MODERATED] Re: [PATCH v2 0/8] PERFv2

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Feb 07, 2019 at 06:37:59AM -0800, speck for Andi Kleen wrote:
> > A few questions:
> > 
> >  - How will this 'feature' interact with MSR_CORE_PERF_GLOBAL_CTRL ?
> 
> It's completely independent of GLOBAL_CTRL on the software level.
> Internally it uses it, but it shouldn't be software visible.

So if you write GLOBAL_CTRL=0 and then use RTM instructions, the ucode
doesn't set GLOBAL_CTRL.3 = 1 ? It would have to, otherwise I don't see
how it would work.

> >  - Is having GLOBAL_CTRL.3 0 and not using RTM instructions enough
> >    guarantee to avoid PMC3 from being clobbered?
> 
> With no use of RTM clobbering should be fairly unlikely,
> but in theory it could happen if RETPOLINE is not used
> (due to an indirect branch mistakenenly executing something
> that looks like XBEGIN). If we assume that RETPOLINE 
> is used I believe it shouldn't happen in the kernel at least.
> Even without RETPOLINE such a case should be fairly unlikely,
> but cannot be 100% ruled out.
> 
> > Esp. that latter question, because both your patches and the below seems
> > to rely on that; and if the answer is yet, the below can be further
> > simplified.
> 
> I don't see how I rely on that?

Your, like my earlier patch, hooks into x86_pmu.enable_event, but if you
look at x86_pmu_start(), we only call that _after_
x86_perf_event_set_period() which would program CNTVAL3.

If we cannot rely on the PMC3 state being stable, we have to add a hook.