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>
Cc:     Andi Kleen <ak@linux.intel.com>, 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>,
        songliubraving@fb.com
References: <20181231072112.21051-1-namit@vmware.com>
 <87zhshe66w.fsf@linux.intel.com>
 <20190107163227.GH14122@hirez.programming.kicks-ass.net>
 <c4e836e8-1949-27f5-f6a0-ed860f590ec5@intel.com>
 <20190108092559.GA6808@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: <306d38fb-7ce6-a3ec-a351-6c117559ebaa@intel.com>
Date:   Tue, 8 Jan 2019 12:01:11 +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: <20190108092559.GA6808@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 8/01/19 11:25 AM, Peter Zijlstra wrote:
> On Tue, Jan 08, 2019 at 09:47:18AM +0200, Adrian Hunter wrote:
>> 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.
> 
> Meh; you always need a magic combo of CONFIG symbols to make stuff work.
> We don't even have a CONFIG symbol for PT, so if you really care you
> should probably start there.
> 
> If you want symbols; what stops us from exposing kallsyms in kcore as
> is?
> 
>> 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.
> 
> We're working on BPF and kallsym events, those should, esp. when
> combined with kcore, allow you to extract the actual instructions.

The problem is that the jitted code gets freed from memory, which is why I
suggested the ability to pin it for a while.