Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC v2 0/6] x86: dynamic indirect branch promotion
To:     Peter Zijlstra <peterz@infradead.org>,
        Andi Kleen <ak@linux.intel.com>
Cc:     Nadav Amit <namit@vmware.com>, Ingo Molnar <mingo@redhat.com>,
        Andy Lutomirski <luto@kernel.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Edward Cree <ecree@solarflare.com>,
        "H . Peter Anvin" <hpa@zytor.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Nadav Amit <nadav.amit@gmail.com>, X86 ML <x86@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        David Woodhouse <dwmw@amazon.co.uk>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>
References: <20181231072112.21051-1-namit@vmware.com>
 <87zhshe66w.fsf@linux.intel.com>
 <20190107163227.GH14122@hirez.programming.kicks-ass.net>
From:   Adrian Hunter <adrian.hunter@intel.com>
Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki,
 Business Identity Code: 0357606 - 4, Domiciled in Helsinki
Message-ID: <c4e836e8-1949-27f5-f6a0-ed860f590ec5@intel.com>
Date:   Tue, 8 Jan 2019 09:47:18 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <20190107163227.GH14122@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 7/01/19 6:32 PM, Peter Zijlstra wrote:
> On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote:
>> Nadav Amit <namit@vmware.com> writes:
>>>
>>> - Do we use periodic learning or not? Josh suggested to reconfigure the
>>>   branches whenever a new target is found. However, I do not know at
>>>   this time how to do learning efficiently, without making learning much
>>>   more expensive.
>>
>> FWIW frequent patching will likely completely break perf Processor Trace
>> decoding, which needs a somewhat stable kernel text image to decode the
>> traces generated by the CPU. Right now it relies on kcore dumped after
>> the trace usually being stable because jumplabel changes happen only
>> infrequently. But if you start patching frequently this assumption will
>> break.
>>
>> You would either need a way to turn this off, or provide
>> updates for every change to the trace, so that the decoder can
>> keep track.
> 
> I'm thining it would be entirely possible to create and feed text_poke
> events into the regular (!aux) buffer which can be timestamp correlated
> to the PT data.

To rebuild kernel text from such events would require a starting point.
What is the starting point?  The problem with kcore is that people can
deconfig it without realising it is needed to enable the tracing of kernel
self-modifying code.  It would be nice if it was all tied together, so that
if someone selects the ability to trace kernel self-modifying code, then all
the bits needed are also selected.  Perhaps we should expose another ELF
image that contains only kernel executable code, and take the opportunity to
put the symbols in it also.

Also what about BPF jitted code?  Will it always fit in an event?  I was
thinking of trying to add a way to prevent temporarily the unload of modules
or jitted code, which would be a good-enough solution for now.