From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1161643AbcFBR2W (ORCPT <rfc822;w@1wt.eu>);
	Thu, 2 Jun 2016 13:28:22 -0400
Received: from mail-wm0-f46.google.com ([74.125.82.46]:37038 "EHLO
	mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1161314AbcFBR2V (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 2 Jun 2016 13:28:21 -0400
MIME-Version: 1.0
In-Reply-To: <20160602160428.GR22049@tassilo.jf.intel.com>
References: <1464835323-33872-1-git-send-email-davidcc@google.com>
 <1464835323-33872-2-git-send-email-davidcc@google.com> <20160602160428.GR22049@tassilo.jf.intel.com>
From: Stephane Eranian <eranian@google.com>
Date: Thu, 2 Jun 2016 10:28:18 -0700
Message-ID: <CABPqkBQH+_-z8SnXAKKH-3TwpPGRsBgHoW=EEXQKsFT1ZRnCkg@mail.gmail.com>
Subject: Re: [PATCH 1/3] perf/x86/intel: output LBR support statement after validation
To: Andi Kleen <ak@linux.intel.com>
Cc: David Carrillo-Cisneros <davidcc@google.com>,
        LKML <linux-kernel@vger.kernel.org>, "x86@kernel.org" <x86@kernel.org>,
        Ingo Molnar <mingo@redhat.com>, "Yan, Zheng" <zheng.z.yan@intel.com>,
        Kan Liang <kan.liang@intel.com>, Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Andi,

On Thu, Jun 2, 2016 at 9:04 AM, Andi Kleen <ak@linux.intel.com> wrote:
>
>
> I don't think the context switch support is really needed. It's only
> needed for saving/restoring LBRs, and we only do that with LBR callstacks.
> In any other LBR mode that LBRs are only flushed on context switch
> But LBR callstacks will never put kernel addresses into the LBRs
> because they are forced to set a ring 3 filter. So you can't have
> kernel addresses in the LBR when saving/restoring them
> (unless I missed some case)
>
It is not because you force LBR to ring3 only that you do not capture
kernel addresses in the FROM field.
Keep in mind that LBR priv level filtering applies to the target of
the branch and not the source. You might
still get a kernel address if returning from kernel. Now, in callstack
mode, I think the return branch is never
actually recorded in the LBR, it just causes a pop, so theoretically
this should not happen. I'd like to be
100% sure of that, though.

> Dropping that will likely simplify the patch somewhat.
>
> -Andi