Re: [PATCH 0/2] sparc32: fix SuperSPARC SMP synchronization

[Magnus Lindholm]

On Fri, Sep 4, 2026 at 7:54 AM Magnus Lindholm <linmag7@xxxxxxxxx> wrote:
>
> 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@xxxxxxxxx/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

Hi,

I'll send a v2 of this series soon, simplifying patch 2 to use only
a local FLUSH.

SuperSPARC maintains instruction-cache coherence through snooping.
The writer's FLUSH provides the local synchronization needed after
modifying instructions, including draining its store buffer. Remote
FLUSH cross-calls are unnecessary.

My earlier justification based on instructions already in a remote
CPU's pipeline was insufficient: a cross-call cannot prevent an old
instruction from executing before it arrives. Callers modifying live
text must themselves arrange safe execution during the update.

The v2 will retain the local FLUSH implementations for
flush_icache_range() and viking_flush_sig_insns(), while dropping
the remote cross-calls introduced by patch 2.

Patch 1's TLB demap serialization is unchanged. Cache snooping does
not invalidate another processor's TLB entries.

Thanks,
Magnus