From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94336C3A59E for ; Fri, 16 Aug 2019 13:01:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 76CB32064A for ; Fri, 16 Aug 2019 13:01:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727571AbfHPNBS (ORCPT ); Fri, 16 Aug 2019 09:01:18 -0400 Received: from mga12.intel.com ([192.55.52.136]:56584 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726075AbfHPNBS (ORCPT ); Fri, 16 Aug 2019 09:01:18 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2019 06:01:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,393,1559545200"; d="scan'208";a="171409585" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.122]) ([10.237.72.122]) by orsmga008.jf.intel.com with ESMTP; 16 Aug 2019 06:01:12 -0700 Subject: Re: [PATCH v5] perf machine: arm/arm64: Improve completeness for kernel address space To: Leo Yan Cc: Arnaldo Carvalho de Melo , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, clang-built-linux@googlegroups.com, Mathieu Poirier , Peter Zijlstra , Suzuki Poulouse , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org References: <20190815082521.16885-1-leo.yan@linaro.org> <20190815113242.GA28881@leoy-ThinkPad-X240s> <20190816014541.GA17960@leoy-ThinkPad-X240s> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: <363577f1-097e-eddd-a6ca-b23f644dd8ce@intel.com> Date: Fri, 16 Aug 2019 16:00:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190816014541.GA17960@leoy-ThinkPad-X240s> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/08/19 4:45 AM, Leo Yan wrote: > Hi Adrian, > > On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote: > > [...] > >>>> How come you cannot use kallsyms to get the information? >>> >>> Thanks for pointing out this. Sorry I skipped your comment "I don't >>> know how you intend to calculate ARM_PRE_START_SIZE" when you reviewed >>> the patch v3, I should use that chance to elaborate the detailed idea >>> and so can get more feedback/guidance before procceed. >>> >>> Actually, I have considered to use kallsyms when worked on the previous >>> patch set. >>> >>> As mentioned in patch set v4's cover letter, I tried to implement >>> machine__create_extra_kernel_maps() for arm/arm64, the purpose is to >>> parse kallsyms so can find more kernel maps and thus also can fixup >>> the kernel start address. But I found the 'perf script' tool directly >>> calls machine__get_kernel_start() instead of running into the flow for >>> machine__create_extra_kernel_maps(); >> >> Doesn't it just need to loop through each kernel map to find the lowest >> start address? > > Based on your suggestion, I worked out below change and verified it > can work well on arm64 for fixing up start address; please let me know > if the change works for you? How does that work if take a perf.data file to a machine with a different architecture? > > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > index f6ee7fbad3e4..51d78313dca1 100644 > --- a/tools/perf/util/machine.c > +++ b/tools/perf/util/machine.c > @@ -2671,9 +2671,26 @@ int machine__nr_cpus_avail(struct machine *machine) > return machine ? perf_env__nr_cpus_avail(machine->env) : 0; > } > > +static int machine__fixup_kernel_start(void *arg, > + const char *name __maybe_unused, > + char type, > + u64 start) > +{ > + struct machine *machine = arg; > + > + type = toupper(type); > + > + /* Fixup for text, weak, data and bss sections. */ > + if (type == 'T' || type == 'W' || type == 'D' || type == 'B') > + machine->kernel_start = min(machine->kernel_start, start); > + > + return 0; > +} > + > int machine__get_kernel_start(struct machine *machine) > { > struct map *map = machine__kernel_map(machine); > + char filename[PATH_MAX]; > int err = 0; > > /* > @@ -2687,6 +2704,7 @@ int machine__get_kernel_start(struct machine *machine) > machine->kernel_start = 1ULL << 63; > if (map) { > err = map__load(map); > /* > * On x86_64, PTI entry trampolines are less than the > * start of kernel text, but still above 2^63. So leave > @@ -2695,6 +2713,16 @@ int machine__get_kernel_start(struct machine *machine) > if (!err && !machine__is(machine, "x86_64")) > machine->kernel_start = map->start; > } > + > + machine__get_kallsyms_filename(machine, filename, PATH_MAX); > + > + if (symbol__restricted_filename(filename, "/proc/kallsyms")) > + goto out; > + > + if (kallsyms__parse(filename, machine, machine__fixup_kernel_start)) > + pr_warning("Fail to fixup kernel start address. skipping...\n"); > + > +out: > return err; > } > > Thanks, > Leo Yan >