[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251204144336.GN724103@e132581.arm.com>
Date: Thu, 4 Dec 2025 14:43:36 +0000
From: Leo Yan <leo.yan@....com>
To: James Clark <james.clark@...aro.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Mike Leach <mike.leach@...aro.org>,
John Garry <john.g.garry@...cle.com>, Will Deacon <will@...nel.org>,
Leo Yan <leo.yan@...ux.dev>, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org, coresight@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 6/7] perf cs-etm: Don't hard code config attribute when
configuring the event
On Thu, Dec 04, 2025 at 02:08:59PM +0000, James Clark wrote:
[...]
> > > + err = evsel__get_config_val(cs_etm_pmu, evsel, "contextid", &ctxt);
> > > + if (err)
> > > + return err;
> > > + err = evsel__get_config_val(cs_etm_pmu, evsel, "contextid1", &ctxt1);
> > > + if (err)
> > > + return err;
> > > + err = evsel__get_config_val(cs_etm_pmu, evsel, "contextid2", &ctxt2);
> > > + if (err)
> > > + return err;
> >
> > Seems to me, this is not right. The current code checks any context
> > ID setting but it can tolerate if missing "contexid[*]" format.
> >
> > After calling evsel__get_config_val(), if any "contextid[*]" format is
> > missed, it returns error and will diretly bail out. As a result,
> > cs_etm_validate_context_id() will always return error.
> >
>
> Missed by the driver or the user? evsel__get_config_val() only returns an
> error when "contextid" isn't published by the driver, not when the user
> doesn't supply one of those options. The actual user supplied value is in
> the out param, not the return value.
My question is for missing format from user. Thanks for reminding the
error is only for driver's publishing.
> Having said that, this does make it an error if the driver did stop
> publishing one, which might be too inflexible and is a new behavior. I can
> change to it ignore the errors instead.
Yeah, this will likely break nVHE / pKVM cases.
Thanks,
Leo
Powered by blists - more mailing lists