From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Lucas Wei <lucaswei@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
sjadavani@google.com, kernel test robot <lkp@intel.com>,
stable@vger.kernel.org, kernel-team@android.com,
linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, visitorckw@google.com,
marscheng@google.com
Subject: Re: [PATCH v2] arm64: errata: Workaround for SI L1 downstream coherency issue
Date: Thu, 1 Jan 2026 16:27:13 +0800 [thread overview]
Message-ID: <aVYv4bf8BVW8b-Sf@google.com> (raw)
In-Reply-To: <20251229033621.996546-1-lucaswei@google.com>
Hi Lucas,
On Mon, Dec 29, 2025 at 03:36:19AM +0000, Lucas Wei wrote:
> When software issues a Cache Maintenance Operation (CMO) targeting a
> dirty cache line, the CPU and DSU cluster may optimize the operation by
> combining the CopyBack Write and CMO into a single combined CopyBack
> Write plus CMO transaction presented to the interconnect (MCN).
> For these combined transactions, the MCN splits the operation into two
> separate transactions, one Write and one CMO, and then propagates the
> write and optionally the CMO to the downstream memory system or external
> Point of Serialization (PoS).
> However, the MCN may return an early CompCMO response to the DSU cluster
> before the corresponding Write and CMO transactions have completed at
> the external PoS or downstream memory. As a result, stale data may be
> observed by external observers that are directly connected to the
> external PoS or downstream memory.
>
> This erratum affects any system topology in which the following
> conditions apply:
> - The Point of Serialization (PoS) is located downstream of the
> interconnect.
> - A downstream observer accesses memory directly, bypassing the
> interconnect.
>
> Conditions:
> This erratum occurs only when all of the following conditions are met:
> 1. Software executes a data cache maintenance operation, specifically,
> a clean or invalidate by virtual address (DC CVAC, DC CIVAC, or DC
> IVAC), that hits on unique dirty data in the CPU or DSU cache. This
> results in a combined CopyBack and CMO being issued to the
> interconnect.
> 2. The interconnect splits the combined transaction into separate Write
> and CMO transactions and returns an early completion response to the
> CPU or DSU before the write has completed at the downstream memory
> or PoS.
> 3. A downstream observer accesses the affected memory address after the
> early completion response is issued but before the actual memory
> write has completed. This allows the observer to read stale data
> that has not yet been updated at the PoS or downstream memory.
>
> The implementation of workaround put a second loop of CMOs at the same
> virtual address whose operation meet erratum conditions to wait until
> cache data be cleaned to PoC.. This way of implementation mitigates
> performance panalty compared to purly duplicate orignial CMO.
>
> Reported-by: kernel test robot <lkp@intel.com>
I assume the Reported-by tag was added due to the sparse warning in v1?
Since this patch fixes a hardware erratum rather than an issue reported
by the robot, I don't think we need this tag here.
Generally, we don't add Reported-by for fixing robot warnings across
patch versions.
Regards,
Kuan-Wei
next prev parent reply other threads:[~2026-01-01 8:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-29 3:36 [PATCH v2] arm64: errata: Workaround for SI L1 downstream coherency issue Lucas Wei
2026-01-01 8:27 ` Kuan-Wei Chiu [this message]
2026-01-01 18:55 ` Marc Zyngier
2026-01-07 16:33 ` Will Deacon
2026-01-07 17:55 ` Robin Murphy
2026-01-08 15:18 ` Will Deacon
2026-01-08 16:13 ` Jason Gunthorpe
2026-01-08 16:41 ` Robin Murphy
2026-01-08 16:54 ` Jason Gunthorpe
2026-01-07 16:22 ` Will Deacon
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=aVYv4bf8BVW8b-Sf@google.com \
--to=visitorckw@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lucaswei@google.com \
--cc=marscheng@google.com \
--cc=sjadavani@google.com \
--cc=stable@vger.kernel.org \
--cc=visitorckw@google.com \
--cc=will@kernel.org \
/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.