Hi Arnaldo,
On Mon, Jun 24, 2019 at 04:00:09PM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> > > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > > > index 0c7776b51045..ae831f836c70 100644
> > > > --- a/tools/perf/util/cs-etm.c
> > > > +++ b/tools/perf/util/cs-etm.c
> > > > @@ -613,10 +613,34 @@ static void cs_etm__free(struct perf_session *session)
> > > > static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address)
> > > > {
> > > > struct machine *machine;
> > > > + u64 fixup_kernel_start = 0;
> > > > + const char *arch;
> > > >
> > > > machine = etmq->etm->machine;
> > > > + arch = perf_env__arch(machine->env);
> > > >
> > > > - if (address >= etmq->etm->kernel_start) {
> > > > + /*
> > > > + * Since arm and arm64 specify some memory regions prior to
> > > > + * 'kernel_start', kernel addresses can be less than 'kernel_start'.
> > > > + *
> > > > + * For arm architecture, the 16MB virtual memory space prior to
> > > > + * 'kernel_start' is allocated to device modules, a PMD table if
> > > > + * CONFIG_HIGHMEM is enabled and a PGD table.
> > > > + *
> > > > + * For arm64 architecture, the root PGD table, device module memory
> > > > + * region and BPF jit region are prior to 'kernel_start'.
> > > > + *
> > > > + * To reflect the complete kernel address space, compensate these
> > > > + * pre-defined regions for kernel start address.
> > > > + */
> > > > + if (!strcmp(arch, "arm64"))
> > > > + fixup_kernel_start = etmq->etm->kernel_start -
> > > > + ARM64_PRE_START_SIZE;
> > > > + else if (!strcmp(arch, "arm"))
> > > > + fixup_kernel_start = etmq->etm->kernel_start -
> > > > + ARM_PRE_START_SIZE;
> > >
> > > I will test your work but from a quick look wouldn't it be better to
> > > have a single define name here? From looking at the modifications you
> > > did to Makefile.config there doesn't seem to be a reason to have two.
> >
> > Thanks for suggestion. I changed to use single define
> > ARM_PRE_START_SIZE and sent patch v2 [1].
> >
> > If possible, please test patch v2.
> >
> > Thanks,
> > Leo Yan
>
> So just for the record, I'm waiting for Mathieu on this one, i.e. for
> him to test/ack v3.
Yes, this makes sense. I'd like to get Mathieu's green light as well,
it needs to take much time to build llvm/clang on SBC, so it's no rush.
Thanks,
Leo Yan
