lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3cd57606-5a82-8978-b057-8b3cfea8c62d@arm.com>
Date:   Tue, 19 Sep 2023 12:26:20 +0100
From:   Suzuki K Poulose <suzuki.poulose@....com>
To:     Anshuman Khandual <anshuman.khandual@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mike Leach <mike.leach@...aro.org>,
        James Clark <james.clark@....com>,
        Leo Yan <leo.yan@...aro.org>, Jonathan Corbet <corbet@....net>,
        linux-doc@...r.kernel.org, coresight@...ts.linaro.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V5 - RESEND 1/3] coresight: etm: Override TRCIDR3.CCITMIN
 on errata affected cpus

Hi Anshuman

On 15/09/2023 10:36, Anshuman Khandual wrote:
> This work arounds errata 1490853 on Cortex-A76, and Neoverse-N1, errata
> 1491015 on Cortex-A77, errata 1502854 on Cortex-X1, and errata 1619801 on
> Neoverse-V1, based affected cpus, where software read for TRCIDR3.CCITMIN
> field in ETM gets an wrong value.
> 
> If software uses the value returned by the TRCIDR3.CCITMIN register field,
> then it will limit the range which could be used for programming the ETM.
> In reality, the ETM could be programmed with a much smaller value than what
> is indicated by the TRCIDR3.CCITMIN field and still function correctly.
> 
> If software reads the TRCIDR3.CCITMIN register field, corresponding to the
> instruction trace counting minimum threshold, observe the value 0x100 or a
> minimum cycle count threshold of 256. The correct value should be 0x4 or a
> minimum cycle count threshold of 4.
> 
> This work arounds the problem via storing 4 in drvdata->ccitmin on affected
> systems where the TRCIDR3.CCITMIN has been 256, thus preserving cycle count
> threshold granularity.
> 

The patch looks good to me, please find a minor change below.

> These errata information has been updated in arch/arm64/silicon-errata.rst,
> but without their corresponding configs because these have been implemented
> directly in the driver.
> 
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will@...nel.org>
> Cc: Suzuki K Poulose <suzuki.poulose@....com>
> Cc: Mike Leach <mike.leach@...aro.org>
> Cc: James Clark <james.clark@....com>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: linux-doc@...r.kernel.org
> Cc: coresight@...ts.linaro.org
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: linux-kernel@...r.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> ---
>   Documentation/arch/arm64/silicon-errata.rst   | 10 ++++++
>   .../coresight/coresight-etm4x-core.c          | 36 +++++++++++++++++++
>   2 files changed, 46 insertions(+)
> 
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index e96f057ea2a0..8f1be5da68b7 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -115,6 +115,10 @@ stable kernels.
>   +----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Cortex-A76      | #1463225        | ARM64_ERRATUM_1463225       |
>   +----------------+-----------------+-----------------+-----------------------------+
> +| ARM            | Cortex-A76      | #1490853        | N/A                         |
> ++----------------+-----------------+-----------------+-----------------------------+
> +| ARM            | Cortex-A77      | #1491015        | N/A                         |
> ++----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Cortex-A77      | #1508412        | ARM64_ERRATUM_1508412       |
>   +----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Cortex-A710     | #2119858        | ARM64_ERRATUM_2119858       |
> @@ -125,6 +129,8 @@ stable kernels.
>   +----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Cortex-A715     | #2645198        | ARM64_ERRATUM_2645198       |
>   +----------------+-----------------+-----------------+-----------------------------+
> +| ARM            | Cortex-X1       | #1502854        | N/A                         |
> ++----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Cortex-X2       | #2119858        | ARM64_ERRATUM_2119858       |
>   +----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Cortex-X2       | #2224489        | ARM64_ERRATUM_2224489       |
> @@ -133,6 +139,8 @@ stable kernels.
>   +----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Neoverse-N1     | #1349291        | N/A                         |
>   +----------------+-----------------+-----------------+-----------------------------+
> +| ARM            | Neoverse-N1     | #1490853        | N/A                         |
> ++----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Neoverse-N1     | #1542419        | ARM64_ERRATUM_1542419       |
>   +----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Neoverse-N2     | #2139208        | ARM64_ERRATUM_2139208       |
> @@ -141,6 +149,8 @@ stable kernels.
>   +----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | Neoverse-N2     | #2253138        | ARM64_ERRATUM_2253138       |
>   +----------------+-----------------+-----------------+-----------------------------+
> +| ARM            | Neoverse-V1     | #1619801        | N/A                         |
> ++----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | MMU-500         | #841119,826419  | N/A                         |
>   +----------------+-----------------+-----------------+-----------------------------+
>   | ARM            | MMU-600         | #1076982,1209401| N/A                         |
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> index 77b0271ce6eb..c01455bb1caf 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c
> @@ -1150,6 +1150,39 @@ static void cpu_detect_trace_filtering(struct etmv4_drvdata *drvdata)
>   	drvdata->trfcr = trfcr;
>   }
>   
> +/*
> + * The following errata on applicable cpu ranges, affect the CCITMIN filed
> + * in TCRIDR3 register. Software read for the field returns 0x100 limiting
> + * the cycle threshold granularity, whereas the right value should have
> + * been 0x4, which is well supported in the hardware.
> + */
> +static struct midr_range etm_wrong_ccitmin_cpus[] = {
> +	/* Erratum #1490853 - Cortex-A76 */
> +	MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 4, 0),
> +	/* Erratum #1490853 - Neoverse-N1 */
> +	MIDR_RANGE(MIDR_NEOVERSE_N1, 0, 0, 4, 0),
> +	/* Erratum #1491015 - Cortex-A77 */
> +	MIDR_RANGE(MIDR_CORTEX_A77, 0, 0, 1, 0),
> +	/* Erratum #1502854 - Cortex-X1 */
> +	MIDR_REV(MIDR_CORTEX_X1, 0, 0),
> +	/* Erratum #1619801 - Neoverse-V1 */
> +	MIDR_REV(MIDR_NEOVERSE_V1, 0, 0),
> +	{},
> +};
> +
> +static bool etm4_core_reads_wrong_ccitmin(struct etmv4_drvdata *drvdata)
> +{
> +	/*
> +	 * Erratum affected cpus will read 256 as the minimum
> +	 * instruction trace cycle counting threshold whereas
> +	 * the correct value should be 4 instead. Override the
> +	 * recorded value for 'drvdata->ccitmin' to workaround
> +	 * this problem.
> +	 */
> +	return is_midr_in_range_list(read_cpuid_id(), etm_wrong_ccitmin_cpus) &&
> +	       (drvdata->ccitmin == 256);

minor nit: Having looked at this, it feels like, fixing the ccitmin
value to 4, could be moved into this function. Otherwise,  we have all
the required information about the erratum and the real application of
work around is left in the caller, which kind of feels disconnected.

So, please could we rename the above function to:

static void etm4_fixup_wrong_ccitmin(str..)
{
   /* Comment as above */
    if (....)
	drvdata->ccitmin = 4;
}


Rest looks fine to me.

Suzuki


> +}
> +
>   static void etm4_init_arch_data(void *info)
>   {
>   	u32 etmidr0;
> @@ -1214,6 +1247,9 @@ static void etm4_init_arch_data(void *info)
>   	etmidr3 = etm4x_relaxed_read32(csa, TRCIDR3);
>   	/* CCITMIN, bits[11:0] minimum threshold value that can be programmed */
>   	drvdata->ccitmin = FIELD_GET(TRCIDR3_CCITMIN_MASK, etmidr3);
> +	if (etm4_core_reads_wrong_ccitmin(drvdata))
> +		drvdata->ccitmin = 4;
> +
>   	/* EXLEVEL_S, bits[19:16] Secure state instruction tracing */
>   	drvdata->s_ex_level = FIELD_GET(TRCIDR3_EXLEVEL_S_MASK, etmidr3);
>   	drvdata->config.s_ex_level = drvdata->s_ex_level;

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ