linux-kernel - Re: [GIT PULL] RISC-V updates for v6.18-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <93e895ce-2b81-c111-4423-cf7181cc2b45@kernel.org>
Date: Mon, 20 Oct 2025 17:31:25 -0600 (MDT)
From: Paul Walmsley <pjw@...nel.org>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
cc: Olof Johansson <olof@...om.net>, Ben Dooks <ben.dooks@...ethink.co.uk>, 
    Linus Torvalds <torvalds@...ux-foundation.org>, 
    Paul Walmsley <pjw@...nel.org>, linux-riscv@...ts.infradead.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] RISC-V updates for v6.18-rc1

On Wed, 8 Oct 2025, Maciej W. Rozycki wrote:

> On Thu, 2 Oct 2025, Olof Johansson wrote:
> 
> > > Now we’re starting to see commercial cores on the horizon that will have the
> > > ability to be endian configured at run-time. For example, MIPS (the company
> > > not the ISA) has announced they will be producing cores with configurable
> > > endian (https://mips.com/products/hardware/i8500/).
> > 
> > MIPS has been doing some not so awesome things to the RISC-V architecture
> > in the last year or so. They've published patchsets that make it seem
> > like that they seem to have taken some old MIPS designs and done the
> > bare minimal conversion over to RISC-V, since they need their own weird
> > system peripherals and hooks. Again, with the burden for everybody to
> > maintain because their hardware engineers couldn't bother to develop a
> > full proper RISC-V core.
> 
>  This is obviously a false image.  The most recent MIPS ISAs, such as the 
> microMIPSr6 or the nanoMIPS architecture, and consequently implementations 
> were absolutely RISC-V-like, with branch delay slots removed, conditional 
> moves replaced with conditional selects, floating-point condition codes 
> removed in favour to setting a general register, PC-relative instructions 
> added and overall being a variable-length compressed instruction set, up 
> to the point for some company engineers to become disgruntled with the ISA 
> "losing the MIPS spirit."  So it's not that they can't be bothered to make 
> a full proper RISC-V core, surely they can.

Olof is probably referring to support for extensions like Xmipsexectl:

  https://lore.kernel.org/linux-riscv/20250724-p8700-pause-v5-0-a6cbbe1c3412@htecgroup.com/

  https://mips.com/wp-content/uploads/2025/06/P8700_Programmers_Reference_Manual_Rev1.84_5-31-2025.pdf

Xmipsexectl is annoying for at least two reasons:

1. it is a non-conforming RISC-V extension, stepping on existing 
   standardized base RISC-V ISA opcode space; and

2. it brings over new barrier operations straight from the MIPS
   instruction set, rather than just using the standard RISC-V fences

Doing things like this runs additional ecosystem fragmentation risk, which 
impacts all of us, for little apparent gain.  Nevertheless we took these 
patches because their extension includes a custom PAUSE instruction 
variant, and it's understandable that MIPS might have finalized their 
design before Zihintpause.

I hope Xmipsexectl doesn't survive past P8700, and that we never see 
kernel patches to use those leftover MIPS barrier instructions.

>  NB I doubt it's about peripherals: dropping a different CPU into an 
> existing system is nothing new and does not require the ISAs involved to 
> be remotely similar to each other; cf. VAX vs Alpha for example.

This one isn't a hypothetical example either; see:

  https://lore.kernel.org/linux-riscv/20250924-riscv-time-mmio-v6-2-9c6158a14b37@htecgroup.com/


- Paul