All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Zaid Alali <zaidal@os.amperecomputing.com>
Cc: catalin.marinas@arm.com, will@kernel.org, puranjay@kernel.org,
	broonie@kernel.org, mbenes@suse.cz, mark.rutland@arm.com,
	ruanjinjie@huawei.com, oliver.upton@linux.dev, robh@kernel.org,
	anshuman.khandual@arm.com, james.morse@arm.com,
	shiqiliu@hust.edu.cn, eahariha@linux.microsoft.com,
	scott@os.amperecomputing.com, joey.gouly@arm.com,
	ardb@kernel.org, yangyicong@hisilicon.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: errata: Add Ampere erratum AC04_CPU_50 workaround alternative
Date: Tue, 28 Jan 2025 08:34:47 +0000	[thread overview]
Message-ID: <87msfbtjyw.wl-maz@kernel.org> (raw)
In-Reply-To: <20250127201829.209258-1-zaidal@os.amperecomputing.com>

On Mon, 27 Jan 2025 20:18:29 +0000,
Zaid Alali <zaidal@os.amperecomputing.com> wrote:
> 
> Add an alternative code sequence to work around Ampere erratum
> AC03_CPU_50 on AmpereOne and Ampere1A.
> 
> Due to AC03_CPU_50, when ICC_PMR_EL1 should have a value of 0xf0 a
> direct read of the register will return a value of 0xf8. An incorrect
> value from a direct read can only happen with the value 0xf0.

Under which precise conditions? Does it equally apply to virtual
interrupts or SCR_EL3.FIQ==0, for which there is no non-secure shift
(which I can only assume is the source of the erratum)? Does it
equally affect G0 and G1 interrupts?

> 
> Note: Currently there are no checks against a value of 0xf0, and that
> save restore of 0xf8 -> 0xf0 is fine, so this is all future proofing.
> 
> Signed-off-by: Zaid Alali <zaidal@os.amperecomputing.com>
> ---
>  arch/arm64/Kconfig                  | 16 ++++++++++++++++
>  arch/arm64/include/asm/arch_gicv3.h |  2 +-
>  arch/arm64/include/asm/daifflags.h  |  4 ++--
>  arch/arm64/include/asm/irqflags.h   |  6 +++---
>  arch/arm64/include/asm/sysreg.h     |  9 +++++++++
>  arch/arm64/kernel/cpu_errata.c      | 15 +++++++++++++++
>  arch/arm64/kernel/entry.S           |  4 ++++
>  arch/arm64/tools/cpucaps            |  1 +

Please add an entry to Documentation/arch/arm64/silicon-errata.txt.

>  8 files changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fcdd0ed3eca8..8d6e263d66c7 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -461,6 +461,22 @@ config AMPERE_ERRATUM_AC03_CPU_38
>  
>  	  If unsure, say Y.
>  
> +config AMPERE_ERRATUM_AC03_CPU_50
> +	bool "AmpereOne: AC03_CPU_50: Certain checks for ICC_PMR_EL1 that expects the value 0xf0 may read 0xf8 instead"
> +	default y
> +	help
> +	  This option adds an alternative code sequence to work around Ampere
> +	  erratum AC03_CPU_50 on AmpereOne and Ampere1A.
> +
> +	  Due to AC03_CPU_50, when ICC_PMR_EL1 should have a value of 0xf0 a
> +	  direct read of the register will return a value of 0xf8. An incorrect
> +	  value from a direct read can only happen with the value 0xf0.
> +
> +	  The workaround for the erratum will do logical AND 0xf0 to the
> +	  value read from ICC_PMR_EL1 register before returning the value.
> +
> +	  If unsure, say Y.
> +

An alternative for this would simply to prevent the enabling of pNMI
on this platform.

	M.

-- 
Without deviation from the norm, progress is not possible.


  reply	other threads:[~2025-01-28  8:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-27 20:18 [PATCH] arm64: errata: Add Ampere erratum AC04_CPU_50 workaround alternative Zaid Alali
2025-01-28  8:34 ` Marc Zyngier [this message]
2025-01-28 20:54   ` Oliver Upton
2025-02-04 21:54     ` Zaid Alali
2025-02-04 21:46   ` Zaid Alali
2025-02-05 14:14     ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87msfbtjyw.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=eahariha@linux.microsoft.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mbenes@suse.cz \
    --cc=oliver.upton@linux.dev \
    --cc=puranjay@kernel.org \
    --cc=robh@kernel.org \
    --cc=ruanjinjie@huawei.com \
    --cc=scott@os.amperecomputing.com \
    --cc=shiqiliu@hust.edu.cn \
    --cc=will@kernel.org \
    --cc=yangyicong@hisilicon.com \
    --cc=zaidal@os.amperecomputing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.