Message-ID: <alpine.DEB.2.21.2511090221080.25436@angie.orcam.me.uk>
Date: Sun, 9 Nov 2025 03:23:31 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Arnd Bergmann <arnd@...db.de>
cc: Andy Lutomirski <luto@...nel.org>, 
    Thomas Weißschuh <thomas.weissschuh@...utronix.de>, 
    Thomas Gleixner <tglx@...utronix.de>, 
    Vincenzo Frascino <vincenzo.frascino@....com>, 
    "David S . Miller" <davem@...emloft.net>, 
    Andreas Larsson <andreas@...sler.com>, 
    Nick Alcock <nick.alcock@...cle.com>, John Stultz <jstultz@...gle.com>, 
    Stephen Boyd <sboyd@...nel.org>, 
    John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, 
    shuah <shuah@...nel.org>, Catalin Marinas <catalin.marinas@....com>, 
    Will Deacon <will@...nel.org>, Theodore Ts'o <tytso@....edu>, 
    "Jason A . Donenfeld" <Jason@...c4.com>, 
    Russell King <linux@...linux.org.uk>, 
    Madhavan Srinivasan <maddy@...ux.ibm.com>, 
    Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, 
    Christophe Leroy <christophe.leroy@...roup.eu>, 
    Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>, 
    Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, 
    Alexander Gordeev <agordeev@...ux.ibm.com>, 
    Christian Borntraeger <borntraeger@...ux.ibm.com>, 
    Sven Schnelle <svens@...ux.ibm.com>, Shannon Nelson <sln@...main.com>, 
    Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
    sparclinux@...r.kernel.org, linux-kselftest@...r.kernel.org, 
    linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org, 
    loongarch@...ts.linux.dev, linux-mips@...r.kernel.org, 
    linux-s390@...r.kernel.org, Arnd Bergmann <arnd@...nel.org>
Subject: Re: [PATCH v5 00/34] sparc64: vdso: Switch to the generic vDSO
 library

On Sat, 8 Nov 2025, Arnd Bergmann wrote:

> On other architectures, I see that parisc (always aliasing) has stubbed
> out the vdso functions, while mips/loongson has limited the page size
> selection to never alias. A few other mips platforms can theoretically
> enable both small pages and vdso, but my guess is that in practice
> they don't use the vdso (mips32/ath79) or they use 16KB pages
> (rm, dec, ip22) based on the defconfig settings.

 Umm, I'd have to dive into the details (and I hardly have the resources 
at hand), but quite a bunch of MIPS microarchitectures suffer from cache 
aliases; some even have VIVT caches.  A quick check with a system I have 
running at my lab:

$ ldd /bin/true
        linux-vdso.so.1 =>  (0x77ff4000)
        libc.so.6 => /lib/libc.so.6 (0x77e50000)
        /lib/ld.so.1 (0x77fcc000)
$ getconf PAGESIZE
4096
$ dmesg | grep linesize
Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
MIPS secondary cache 512kB, 8-way, linesize 32 bytes.
$ 

Some microarchitectures have aliasing prevention implemented in hardware, 
e.g. with the MTI 24K core:

                 Table 6-31 Config7 Register Field Descriptions
-------------+---------------------------------------------+-------+---------
   Fields    |                                             |       |
------+------+                                             | Read/ |  Reset 
 Name | Bits |                Description                  | Write |  State
======+======+=============================================+=======+=========
      |      | Alias removed: This bit indicates that the  |       |
      |      | data cache is organized to avoid virtual    |       |
  AR  |  16  | aliasing problems.  This bit is only set if |   R   |  Based
      |      | the data cache config and MMU type would    |       |  on HW
      |      | normally cause aliasing - i.e., only for    |       | present
      |      | the 32KB data cache and TLB-based MMU.      |       |
------+------+---------------------------------------------+-------+---------

But this is entirely optional and not architecturally guaranteed; Config7 
is a vendor space register.

 DEC platforms have a selectable page size (for R4k CPUs; R3k CPUs have a 
PIPT write-through cache, so no issue with aliasing ever) and 4KiB is the 
common choice, but they never suffer from aliases as the hardware resolves 
them.  It's not completely transparent as with the 24K option shown above, 
as a virtual coherency exception is triggered instead, at separate levels 
for the I$ and D$ each, and we handle it in software:

$ getconf PAGESIZE
4096
$ dmesg | grep linesize
Primary instruction cache 16kB, VIPT, direct mapped, linesize 16 bytes.
Primary data cache 16kB, direct mapped, VIPT, cache aliases, linesize 16 bytes
Unified secondary cache 1024kB direct mapped, linesize 32 bytes.
$ uptime
 02:46:16  up 250 days,  4:03,  2 users,  load average: 0.01, 0.01, 0.00
$ cat /proc/cpuinfo
system type		: Digital DECstation 5000/2x0
machine			: Unknown
processor		: 0
cpu model		: R4400SC V4.0  FPU V0.0
BogoMIPS		: 59.60
wait instruction	: no
microsecond timers	: yes
tlb_entries		: 48
extra interrupt vector	: no
hardware watchpoint	: yes, count: 0, address/irw mask: []
isa			: mips1 mips2 mips3
ASEs implemented	:
Options implemented	: tlb 4kex 4k_cache fpu 32fpr cache_cdex_p cache_cdex_s llsc dc_aliases inclusive_pcaches nan_legacy
shadow register sets	: 1
kscratch registers	: 0
package			: 0
core			: 0
VCED exceptions		: 372522
VCEI exceptions		: 16922804

$ 

(see the figures at the bottom; uptime quoted for an idea of the rate, 
though the system hasn't been heavily loaded).  It is possible with the 
aid of S$, which is inclusive and PIPT.

 FWIW,

  Maciej

Powered by blists - more mailing lists