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, Magnus Lindholm <linmag7@gmail.com>
Subject: [PATCH 0/2] sparc32: fix SuperSPARC SMP synchronization
Date: Fri, 4 Sep 2026 07:53:04 +0200 [thread overview]
Message-ID: <20260904055359.327050-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, but FLUSH is still
required after modifying instructions. It drains the writer's unsnoopable
store buffer and clears local pipeline and prefetch state [1, sections 7.4
and 10.2.5; 3, section A.8.2]. Patch 2 executes FLUSH first on the writer
and then on remote CPUs.
The series was tested on a dual-CPU sun4m SPARCstation 20 with TI
SuperSPARC processors and Viking/MXCC:
- boot to multi-user with both CPUs online;
- 200,000 concurrent mprotect iterations over a shared address space;
- 12,000 executable-code rewrites checked on both CPUs;
- removing flush_icache_range() reproduced a stale instruction on the
first rewrite.
[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 | 120 ++++++++++++++++++++++++-
arch/sparc/mm/viking.S | 4 +
3 files changed, 123 insertions(+), 3 deletions(-)
base-commit: e6de5705a9f0d81f67bdb2917108784b5839cecd
--
2.43.0
next reply other threads:[~2026-09-04 5:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 5:53 Magnus Lindholm [this message]
2026-09-04 5:53 ` [PATCH 1/2] sparc32: serialize SuperSPARC demap operations Magnus Lindholm
2026-09-04 5:53 ` [PATCH 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=20260904055359.327050-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®