[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <de9d0707-0a3b-7a3d-eb95-f8de10765130@arm.com>
Date: Wed, 27 Apr 2022 12:49:43 +0100
From: Robin Murphy <robin.murphy@....com>
To: "Srinivasarao Pathipati (Consultant)" <c_spathi@....qualcomm.com>,
quic_spathi <quic_spathi@...cinc.com>,
"will@...nel.org" <will@...nel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"peterz@...radead.org" <peterz@...radead.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"acme@...nel.org" <acme@...nel.org>,
"alexander.shishkin@...ux.intel.com"
<alexander.shishkin@...ux.intel.com>,
"jolsa@...nel.org" <jolsa@...nel.org>,
"namhyung@...nel.org" <namhyung@...nel.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V1] arm64: perf: Change PMCR write to read-modify-write
On 2022-04-27 12:09, Srinivasarao Pathipati (Consultant) wrote:
>>
>> On 2022-04-27 10:51, Srinivasarao Pathipati wrote:
>>> Preserve the bitfields of PMCR_EL0 during PMU reset.
>>> Reset routine should set only PMCR.C, PMCR.P and PMCR.LC fields only
>>> to reset the counters. Other fields should not be changed
>>> as they could be set before PMU initialization and their value must
>>> be preserved even after reset.
>>
>> No. We also want to ensure PMCR.E and PMCR.D are set to 0, for example.
>> Given that nearly all the writeable fields in PMCR reset to an
>> architecturally UNKNOWN value, preserving that is clearly nonsense.
>> What's your *real* motivation here?
>
> Thanks Robin for reviewing this patch.
> The X bit is set by firmware on Qualcomm chipsets
> same is getting cleared by kernel from armv8pmu_reset().
> We are trying to retain this bit with this patch.
OK, that's fair enough, but anything firmware may have done is not
really relevant once Linux has taken over, since firmware is no longer
in control of the PMU. As mentioned, at this point the driver doesn't
know *why* any bits are set the way they are - maybe they were
deliberately configured by platform firmware; maybe the hardware just
randomly reset to that value; maybe another OS kexec'ed with the PMU
still running and configured in who-knows-what state; we simply can't
reason about it, so we have to configure the PMU into a known state for
how we're going to use it.
> If it is wrong to retaining all bits? can we just retain X bit?
If it's useful for PMU events under Linux to be exported where
applicable, then it seems reasonable for Linux to enable PMCR.X for
itself. Certainly there doesn't seem to be any obvious reason *not* to,
other than perhaps some small power cost, but I guess it could always be
user-controlled if we wanted to be particularly cautious.
Thanks,
Robin.
Powered by blists - more mailing lists