mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Magnus Lindholm <linmag7@gmail.com>
To: davem@davemloft.net, andreas@gaisler.com
Cc: sam@ravnborg.org, sparclinux@vger.kernel.org,
	linux-kernel@vger.kernel.org, linmag7@gmail.com
Subject: [PATCH v2 0/2] sparc32: SuperSPARC SMP synchronization fixes
Date: Thu, 17 Sep 2026 09:57:03 +0200	[thread overview]
Message-ID: <20260917075842.784996-1-linmag7@gmail.com> (raw)

Fill two gaps in the SuperSPARC/Viking SMP synchronization paths.

This series is based on the three sparc32 relocatable-kernel fixes which
honour and derive phys_base and advertise the relocatable image. It does
not include those prerequisite patches.

These patches can be found here:
Link: https://lore.kernel.org/sparclinux/20260816075141.3489194-1-linmag7@gmail.com/T/#t

The SuperSPARC Family User's Manual requires software to keep at most one
Demap operation in progress across the system. It also says that an MBus
system must ask every processor which can retain a stale translation to
perform its own local Demap [1, sections 8.5.3 and 9.8.2]. The Sun-4M
architecture specification likewise describes SRMMU flushing as local to
a module [2, section 7.1.4]. Patch 1 serializes each complete shootdown on
sun4m and invokes remote CPUs one at a time. sun4d already serializes its
Viking Demap operations.

SuperSPARC maintains I-cache coherence by snooping, so no remote processor
needs to be told about modified instructions. FLUSH is still required on the
processor that wrote them: the store buffer is not snooped, so FLUSH is what
pushes them into the coherent hierarchy [1, sections 7.4 and 10.2.5; 3,
section A.8.2]. Patch 2 supplies that local FLUSH on two Viking paths that
performed none at all, viking_flush_sig_insns() was an empty stub, and
flush_icache_range() was defined as do { } while (0).

Tested on a dual-CPU sun4m SPARCstation 20, TI SuperSPARC-II with
Viking/MXCC:

  - boot to multi-user with both CPUs online;
  - 200,000 concurrent mprotect iterations over a shared address space
    (patch 1);
  - 40,000 executable-code rewrites, each replacement executed on the
    writing CPU and on the other CPU, with each CPU taking a turn as the
    writer (patch 2).

An earlier revision measured a stale instruction on the first rewrite with
no flush at all, but that was on a kernel predating this series, where the
whole Viking icache path was inert. On a patched kernel the same control is
intermittent, so it is not offered as evidence for anything here; the
argument for the shape of patch 2 is in its changelog.

Changes in v2:

  - patch 2 no longer cross-calls remote CPUs. Hardware snooping maintains
    instruction-cache coherence on the other processors; both FLUSH
    operations are now local. Callers modifying live text must arrange
    safe execution during the update. A later cross-call cannot prevent an
    old instruction from executing before it arrives, and cannot by itself
    make an otherwise unsafe concurrent text modification safe.
  - patch 2 no longer routes Viking sig_insns through the SMP wrapper, so
    that path retains the local-only behaviour mainline already had.
  - patch 1 is unchanged. It is a TLB shootdown: MBus cache coherence does not
    make a peer discard a virtual TLB entry, so each processor must still
    demap its own.

[1] SuperSPARC Family STP1020 & STP1090 Series User's Manual,
    Revision 1.0, April 1994.
[2] Sun-4M System Architecture, Specification 950-1373-01,
    Revision 50, July 19, 1991.
[3] SuperSPARC II Addendum, Revision 1.3, December 1994.

Magnus Lindholm (2):
  sparc32: serialize SuperSPARC demap operations
  sparc32: synchronize SuperSPARC instruction updates

 arch/sparc/include/asm/cacheflush_32.h |   2 +-
 arch/sparc/mm/srmmu.c                  |  98 +++++++++++++++++++++++++
 arch/sparc/mm/viking.S                 |   5 +
 3 files changed, 104 insertions(+), 1 deletion(-)

-- 
2.43.0

             reply	other threads:[~2026-09-17  7:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17  7:57 Magnus Lindholm [this message]
2026-09-17  7:57 ` [PATCH v2 1/2] sparc32: serialize SuperSPARC demap operations Magnus Lindholm
2026-09-17  7:57 ` [PATCH v2 2/2] sparc32: synchronize SuperSPARC instruction updates Magnus Lindholm

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=20260917075842.784996-1-linmag7@gmail.com \
    --to=linmag7@gmail.com \
    --cc=andreas@gaisler.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sparclinux@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®