From: Catalin Marinas <catalin.marinas@arm•com>
To: Shanker Donthineni <sdonthineni@nvidia•com>
Cc: Will Deacon <will@kernel•org>,
linux-arm-kernel@lists•infradead.org,
Mark Rutland <mark.rutland@arm•com>,
linux-kernel@vger•kernel.org, linux-doc@vger•kernel.org,
Vikram Sethi <vsethi@nvidia•com>,
Jason Sequeira <jsequeira@nvidia•com>
Subject: Re: [PATCH v1] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
Date: Fri, 5 Jun 2026 09:01:45 +0100 [thread overview]
Message-ID: <aiKCaRvofEFaSVkO@arm.com> (raw)
In-Reply-To: <20260604231254.1904988-1-sdonthineni@nvidia.com>
On Thu, Jun 04, 2026 at 06:12:54PM -0500, Shanker Donthineni wrote:
> On systems with NVIDIA Olympus cores, a Device-nGnR* load can be
> observed by a peripheral before an older, non-overlapping Device-nGnR*
> store to the same peripheral. This breaks the program-order guarantee
> that software expects for Device-nGnR* accesses and can leave a
> peripheral in an incorrect state, as a load is observed before an
> earlier store takes effect.
>
> The erratum can occur only when all of the following apply:
>
> - A PE executes a Device-nGnR* store followed by a younger
> Device-nGnR* load.
> - The store is not a store-release.
> - The accesses target the same peripheral and do not overlap in bytes.
> - There is at most one intervening Device-nGnR* store in program
> order, and there are no intervening Device-nGnR* loads.
> - There is no DSB, and no DMB that orders loads, between the store and
> the load.
> - Specific micro-architectural and timing conditions occur.
>
> Two ways to restore ordering: insert a barrier (any DSB, or a DMB that
> orders loads) between the store and the load, or make the store a
> store-release. A load-acquire on the load side would not help, because
> acquire semantics do not prevent a load from being observed ahead of an
> older store; only the store side (release or a barrier) closes the
> window.
Ignoring Device-nGnR*, a store-release followed by a load (not
load-acquire) would not guarantee any ordering. I assume the
store-release behaviour is specific to this erratum - part of the
preconditions.
The patch looks fine to me.
Reviewed-by: Catalin Marinas <catalin.marinas@arm•com>
next prev parent reply other threads:[~2026-06-05 8:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 23:12 [PATCH v1] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum Shanker Donthineni
2026-06-05 8:01 ` Catalin Marinas [this message]
2026-06-05 9:26 ` Vladimir Murzin
2026-06-05 14:34 ` Shanker Donthineni
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=aiKCaRvofEFaSVkO@arm.com \
--to=catalin.marinas@arm$(echo .)com \
--cc=jsequeira@nvidia$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-doc@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=mark.rutland@arm$(echo .)com \
--cc=sdonthineni@nvidia$(echo .)com \
--cc=vsethi@nvidia$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox