[GIT PULL] RISC-V updates for v6.18-rc1

[GIT PULL] RISC-V updates for v6.18-rc1

[Paul Walmsley]

[-- Attachment #1: Type: text/plain, Size: 10844 bytes --]

Linus,

The following changes since commit a03ee11b8f850bd008226c6d392da24163dfb56e:

  riscv: Fix sparse warning about different address spaces (2025-09-05 15:33:52 -0600)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux tags/riscv-for-linus-6.18-mw1

for you to fetch changes up to 0b0ca959d20689fece038954bbf1d7b14c0b11c3:

  riscv: errata: Fix the PAUSE Opcode for MIPS P8700 (2025-09-19 10:33:56 -0600)

----------------------------------------------------------------
RISC-V updates for the v6.18 merge window (part one)

First set of RISC-V updates for the v6.18 merge window, including:

- Replacement of __ASSEMBLY__ with __ASSEMBLER__ in header files (other
  architectures have already merged this type of cleanup)

- The introduction of ioremap_wc() for RISC-V

- Cleanup of the RISC-V kprobes code to use mostly-extant macros rather than
  open code

- A RISC-V kprobes unit test

- An architecture-specific endianness swap macro set implementation,
  leveraging some dedicated RISC-V instructions for this purpose if they
  are available

- The ability to identity and communicate to userspace the presence of a
  MIPS P8700-specific ISA extension, and to leverage its MIPS-specific PAUSE
  implementation in cpu_relax()

- Several other miscellaneous cleanups

----------------------------------------------------------------
Aleksa Paunovic (5):
      dt-bindings: riscv: Add xmipsexectl ISA extension description
      riscv: Add xmipsexectl as a vendor extension
      riscv: Add xmipsexectl instructions
      riscv: hwprobe: Add MIPS vendor extension probing
      riscv: hwprobe: Document MIPS xmipsexectl vendor extension

Alexandre Ghiti (3):
      riscv: Fix typo EXRACT -> EXTRACT
      riscv: Strengthen duplicate and inconsistent definition of RV_X()
      riscv: Move all duplicate insn parsing macros into asm/insn.h

Andrew Davis (1):
      riscv: sbi: Switch to new sys-off handler API

Bala-Vignesh-Reddy (1):
      selftests: riscv: Add README for RISC-V KSelfTest

Chunyan Zhang (2):
      raid6: riscv: Clean up unused header file inclusion
      raid6: riscv: replace one load with a move to speed up the caculation

Clément Léger (1):
      riscv: cpufeature: add validation for zfa, zfh and zfhmin

Djordje Todorovic (1):
      riscv: errata: Fix the PAUSE Opcode for MIPS P8700

Guo Ren (Alibaba DAMO Academy) (1):
      riscv: Move vendor errata definitions to new header

Heinrich Schuchardt (1):
      RISC-V: ACPI: enable parsing the BGRT table

Ignacio Encinas (1):
      riscv: introduce asm/swab.h

Jessica Liu (1):
      riscv: mmap(): use unsigned offset type in riscv_sys_mmap

Junhui Liu (2):
      riscv: mm: Return intended SATP mode for noXlvl options
      riscv: mm: Use mmu-type from FDT to limit SATP mode

Liao Yuanhong (1):
      drivers/perf: riscv: Remove redundant ternary operators

Masahiro Yamada (1):
      riscv: pi: use 'targets' instead of extra-y in Makefile

Nam Cao (12):
      riscv: Add kprobes KUnit test
      riscv: kprobes: Move branch_rs2_idx to insn.h
      riscv: kprobes: Move branch_funct3 to insn.h
      riscv: kprobes: Remove duplication of RV_EXTRACT_JTYPE_IMM
      riscv: kprobes: Remove duplication of RV_EXTRACT_RS1_REG
      riscv: kprobes: Remove duplication of RV_EXTRACT_BTYPE_IMM
      riscv: kprobes: Remove duplication of RVC_EXTRACT_JTYPE_IMM
      riscv: kprobes: Remove duplication of RVC_EXTRACT_C2_RS1_REG
      riscv: kprobes: Remove duplication of RVC_EXTRACT_BTYPE_IMM
      riscv: kprobes: Remove duplication of RV_EXTRACT_RD_REG
      riscv: kprobes: Remove duplication of RV_EXTRACT_UTYPE_IMM
      riscv: kprobes: Remove duplication of RV_EXTRACT_ITYPE_IMM

Pu Lehui (1):
      riscv: Enable ARCH_HAVE_NMI_SAFE_CMPXCHG

Thomas Huth (2):
      riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ in uapi headers
      riscv: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-uapi headers

Yunhui Cui (2):
      riscv: introduce ioremap_wc()
      perf: riscv: skip empty batches in counter start

 Documentation/arch/riscv/hwprobe.rst               |   9 +
 .../devicetree/bindings/riscv/extensions.yaml      |   6 +
 arch/riscv/Kconfig                                 |   1 +
 arch/riscv/Kconfig.errata                          |  23 +++
 arch/riscv/Kconfig.vendor                          |  13 ++
 arch/riscv/errata/Makefile                         |   1 +
 arch/riscv/errata/mips/Makefile                    |   5 +
 arch/riscv/errata/mips/errata.c                    |  67 ++++++
 arch/riscv/include/asm/alternative-macros.h        |  12 +-
 arch/riscv/include/asm/alternative.h               |   5 +-
 arch/riscv/include/asm/asm-extable.h               |   6 +-
 arch/riscv/include/asm/asm.h                       |  10 +-
 arch/riscv/include/asm/assembler.h                 |   2 +-
 arch/riscv/include/asm/barrier.h                   |   4 +-
 arch/riscv/include/asm/cache.h                     |   4 +-
 arch/riscv/include/asm/cmpxchg.h                   |   3 +-
 arch/riscv/include/asm/cpu_ops_sbi.h               |   2 +-
 arch/riscv/include/asm/csr.h                       |   4 +-
 arch/riscv/include/asm/current.h                   |   4 +-
 arch/riscv/include/asm/errata_list.h               |  38 ++--
 arch/riscv/include/asm/errata_list_vendors.h       |  29 +++
 arch/riscv/include/asm/ftrace.h                    |   6 +-
 arch/riscv/include/asm/gpr-num.h                   |   6 +-
 arch/riscv/include/asm/hwprobe.h                   |   3 +-
 arch/riscv/include/asm/image.h                     |   4 +-
 arch/riscv/include/asm/insn-def.h                  |   8 +-
 arch/riscv/include/asm/insn.h                      | 216 +++++++++++++++++--
 arch/riscv/include/asm/io.h                        |   4 +
 arch/riscv/include/asm/jump_label.h                |   4 +-
 arch/riscv/include/asm/kasan.h                     |   2 +-
 arch/riscv/include/asm/kgdb.h                      |   4 +-
 arch/riscv/include/asm/mmu.h                       |   4 +-
 arch/riscv/include/asm/page.h                      |   4 +-
 arch/riscv/include/asm/pgtable.h                   |   5 +-
 arch/riscv/include/asm/processor.h                 |   4 +-
 arch/riscv/include/asm/ptrace.h                    |   4 +-
 arch/riscv/include/asm/scs.h                       |   4 +-
 arch/riscv/include/asm/set_memory.h                |   4 +-
 arch/riscv/include/asm/swab.h                      |  87 ++++++++
 arch/riscv/include/asm/thread_info.h               |   4 +-
 arch/riscv/include/asm/vdso.h                      |   4 +-
 arch/riscv/include/asm/vdso/getrandom.h            |   4 +-
 arch/riscv/include/asm/vdso/gettimeofday.h         |   4 +-
 arch/riscv/include/asm/vdso/processor.h            |   7 +-
 arch/riscv/include/asm/vdso/vsyscall.h             |   4 +-
 arch/riscv/include/asm/vendor_extensions/mips.h    |  37 ++++
 .../include/asm/vendor_extensions/mips_hwprobe.h   |  22 ++
 arch/riscv/include/asm/vendorid_list.h             |   1 +
 arch/riscv/include/uapi/asm/hwprobe.h              |   1 +
 arch/riscv/include/uapi/asm/kvm.h                  |   2 +-
 arch/riscv/include/uapi/asm/ptrace.h               |   4 +-
 arch/riscv/include/uapi/asm/sigcontext.h           |   4 +-
 arch/riscv/include/uapi/asm/vendor/mips.h          |   3 +
 arch/riscv/kernel/acpi.c                           |   3 +
 arch/riscv/kernel/alternative.c                    |   5 +
 arch/riscv/kernel/cpufeature.c                     |   6 +-
 arch/riscv/kernel/entry.S                          |   1 +
 arch/riscv/kernel/machine_kexec_file.c             |   2 +-
 arch/riscv/kernel/pi/Makefile                      |   2 +-
 arch/riscv/kernel/pi/cmdline_early.c               |   4 +-
 arch/riscv/kernel/pi/fdt_early.c                   |  40 ++++
 arch/riscv/kernel/pi/pi.h                          |   1 +
 arch/riscv/kernel/probes/simulate-insn.c           |  94 ++-------
 arch/riscv/kernel/sbi.c                            |   4 +-
 arch/riscv/kernel/sys_hwprobe.c                    |  18 +-
 arch/riscv/kernel/sys_riscv.c                      |   2 +-
 arch/riscv/kernel/tests/Kconfig.debug              |  12 ++
 arch/riscv/kernel/tests/Makefile                   |   1 +
 arch/riscv/kernel/tests/kprobes/Makefile           |   1 +
 arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S | 229 +++++++++++++++++++++
 arch/riscv/kernel/tests/kprobes/test-kprobes.c     |  56 +++++
 arch/riscv/kernel/tests/kprobes/test-kprobes.h     |  24 +++
 arch/riscv/kernel/traps_misaligned.c               | 144 +------------
 arch/riscv/kernel/vector.c                         |   2 +-
 arch/riscv/kernel/vendor_extensions.c              |  10 +
 arch/riscv/kernel/vendor_extensions/Makefile       |   2 +
 arch/riscv/kernel/vendor_extensions/mips.c         |  22 ++
 arch/riscv/kernel/vendor_extensions/mips_hwprobe.c |  23 +++
 arch/riscv/kvm/vcpu_insn.c                         | 128 +-----------
 arch/riscv/mm/init.c                               |  12 +-
 drivers/perf/riscv_pmu_sbi.c                       |   8 +-
 lib/raid6/recov_rvv.c                              |   2 -
 lib/raid6/rvv.c                                    |  63 +++---
 tools/arch/riscv/include/asm/csr.h                 |   6 +-
 tools/arch/riscv/include/asm/vdso/processor.h      |   4 +-
 tools/testing/selftests/riscv/README               |  24 +++
 86 files changed, 1147 insertions(+), 530 deletions(-)
 create mode 100644 arch/riscv/errata/mips/Makefile
 create mode 100644 arch/riscv/errata/mips/errata.c
 create mode 100644 arch/riscv/include/asm/errata_list_vendors.h
 create mode 100644 arch/riscv/include/asm/swab.h
 create mode 100644 arch/riscv/include/asm/vendor_extensions/mips.h
 create mode 100644 arch/riscv/include/asm/vendor_extensions/mips_hwprobe.h
 create mode 100644 arch/riscv/include/uapi/asm/vendor/mips.h
 create mode 100644 arch/riscv/kernel/tests/kprobes/Makefile
 create mode 100644 arch/riscv/kernel/tests/kprobes/test-kprobes-asm.S
 create mode 100644 arch/riscv/kernel/tests/kprobes/test-kprobes.c
 create mode 100644 arch/riscv/kernel/tests/kprobes/test-kprobes.h
 create mode 100644 arch/riscv/kernel/vendor_extensions/mips.c
 create mode 100644 arch/riscv/kernel/vendor_extensions/mips_hwprobe.c
 create mode 100644 tools/testing/selftests/riscv/README

    text	   data	    bss	    dec		    hex	filename
12772113	6174082	 419253	19365448	1277e48	vmlinux.rv64.orig
12839941	6181502	 419253	19440696	128a438	vmlinux.rv64
11725507	5994510	 404229	18124246	1148dd6	vmlinux.rv64_nosmp.orig
11788867	6000158	 404229	18193254	1159b66	vmlinux.rv64_nosmp
11723502	4702818	 309629	16735949	 ff5ecd	vmlinux.rv32.orig
11771062	4703702	 309629	16784393	1001c09	vmlinux.rv32
 2612497	 761072	 119048	 3492617	 354b09	vmlinux.nommu_virt.orig
 2615066	 758584	 119048	 3492698	 354b5a	vmlinux.nommu_virt

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[pr-tracker-bot]

The pull request you sent on Mon, 29 Sep 2025 02:00:17 -0600 (MDT):

> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux tags/riscv-for-linus-6.18-mw1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cb7e3669c683669d93139184adff68a7d9000536

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Ben Dooks]

On 29/09/2025 09:00, Paul Walmsley wrote:
> Linus,
> 
> The following changes since commit a03ee11b8f850bd008226c6d392da24163dfb56e:
> 
>    riscv: Fix sparse warning about different address spaces (2025-09-05 15:33:52 -0600)


Is there any chance some of the big-endian work we did is getting in
for this round?

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Linus Torvalds]

On Tue, 30 Sept 2025 at 00:25, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>
> Is there any chance some of the big-endian work we did is getting in
> for this round?

Oh Christ. Is somebody seriously working on BE support in 2025?

WHY?

Seriously, that sounds like just *stupid*. Is there some actual real
reason for this, or is it more of the "RISC-V is used in academic
design classes and so people just want to do endianness for academic
reasons"?

Because I'd be more than happy to just draw a line in the sand and say
"New endianness problems are somebody ELSES problem", and tell people
to stop being silly.

Let's not complicate things for no good reason. And there is *NO*
reason to add new endianness.

RISC-V is enough of a mess with the millions of silly configuration
issues already. Don't make it even worse.

Tell people to just talk to their therapists instead.  That's *much*
more productive.

Really.

             Linus

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Linus Torvalds]

On Tue, 30 Sept 2025 at 09:04, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Oh Christ. Is somebody seriously working on BE support in 2025?

Ok, I just googled this, and I am putting my foot down:

 WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V

The documented "reasoning" for that craziness is too stupid for words,
but since riscv.org did put it in words, I'll just quote those words
here:

 "There are still applications where the way data is stored matters,
such as the protocols that move data across the Internet, which are
defined as big-endian. So when a little-endian system needs to inspect
or modify a network packet, it has to swap the big-endian values to
little-endian and back, a process that can take as many as 10-20
instructions on a RISC-V target which doesn’t implement the Zbb
extension"

In other words, it is suggesting that RISC-V add a big-endian mode due to

 (a) internet protocols - where byte swapping is not an issue

 (b) using "some RISC-V implementations don't do the existing Zbb
extension" as an excuse

This is plain insanity. First off, even if byte swapping was a real
cost for networking - it's not, the real costs tend to be all in
memory subsystems - just implement the damn Zbb extension.

Don't go "we're too incompetent to implement Zbb, so we're now asking
that EVERYBODY ELSE feel the pain of a much *worse* extension and
fragmenting RISC-V further".

I'm hoping this is some April fools joke, but that page is dated
"March 10, 2025". Close, but not close enough.

This is the kind of silly stuff that just makes RISC-V look bad.

Ben - I'm afraid that that page has "further reading" pointing to codethink.

I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this
needs to stop.

The mainline kernel is for mainline development. Not for random
experiments that make the world a worse place.

And yes, we're open source, and that very much means that anybody is
more than welcome to try to prove me wrong.

If it turns out that BE RISC-V becomes a real thing that is relevant
and actually finds a place in the RISC-V ecosystem, then _of_course_
we should support it at that point in the mainline kernel.

But I really do think that it actually makes RISC-V only worse, and
that we should *not* actively help the fragmentation.

             Linus

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Eric Biggers]

On Tue, Sep 30, 2025 at 04:53:24PM -0700, Linus Torvalds wrote:
> On Tue, 30 Sept 2025 at 09:04, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Oh Christ. Is somebody seriously working on BE support in 2025?
> 
> Ok, I just googled this, and I am putting my foot down:
> 
>  WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V
> 
> The documented "reasoning" for that craziness is too stupid for words,
> but since riscv.org did put it in words, I'll just quote those words
> here:
> 
>  "There are still applications where the way data is stored matters,
> such as the protocols that move data across the Internet, which are
> defined as big-endian. So when a little-endian system needs to inspect
> or modify a network packet, it has to swap the big-endian values to
> little-endian and back, a process that can take as many as 10-20
> instructions on a RISC-V target which doesn’t implement the Zbb
> extension"
> 
> In other words, it is suggesting that RISC-V add a big-endian mode due to
> 
>  (a) internet protocols - where byte swapping is not an issue
> 
>  (b) using "some RISC-V implementations don't do the existing Zbb
> extension" as an excuse
> 
> This is plain insanity. First off, even if byte swapping was a real
> cost for networking - it's not, the real costs tend to be all in
> memory subsystems - just implement the damn Zbb extension.
> 
> Don't go "we're too incompetent to implement Zbb, so we're now asking
> that EVERYBODY ELSE feel the pain of a much *worse* extension and
> fragmenting RISC-V further".
> 
> I'm hoping this is some April fools joke, but that page is dated
> "March 10, 2025". Close, but not close enough.
> 
> This is the kind of silly stuff that just makes RISC-V look bad.
> 
> Ben - I'm afraid that that page has "further reading" pointing to codethink.
> 
> I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this
> needs to stop.
> 
> The mainline kernel is for mainline development. Not for random
> experiments that make the world a worse place.
> 
> And yes, we're open source, and that very much means that anybody is
> more than welcome to try to prove me wrong.
> 
> If it turns out that BE RISC-V becomes a real thing that is relevant
> and actually finds a place in the RISC-V ecosystem, then _of_course_
> we should support it at that point in the mainline kernel.
> 
> But I really do think that it actually makes RISC-V only worse, and
> that we should *not* actively help the fragmentation.

+1.  Please, let's not do big endian RISC-V kernels :(

This mistake was made for arm64, it's finally getting fixed.
See https://lore.kernel.org/r/20250919184025.15416-1-will@kernel.org/
Let's not make the same mistake again.

And as someone who works on optimized crypto and CRC code, the arm64 big
endian kernel support has always been really problematic.  It's rarely
tested, and code that produces incorrect outputs on arm64 big endian
regularly gets committed and released.  It sometimes gets fixed, but not
always; currently the arm64 SM3 and SM4 code produces incorrect outputs
on big endian in mainline.  (I don't really care enough to fix it, TBH.)

I recently added arm64 big endian to my own testing matrix.  But I look
forward to dropping that, as well as *not* having to start testing on
RISC-V big endian too...

Of course, that's just one example from my own experience.  There's a
lot more that CONFIG_CPU_BIG_ENDIAN creates problems for.

- Eric

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2531 bytes --]

On Tue, Sep 30, 2025 at 04:53:24PM -0700, Linus Torvalds wrote:
> On Tue, 30 Sept 2025 at 09:04, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Oh Christ. Is somebody seriously working on BE support in 2025?
> 
> Ok, I just googled this, and I am putting my foot down:
> 
>  WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V
> 
> The documented "reasoning" for that craziness is too stupid for words,
> but since riscv.org did put it in words, I'll just quote those words
> here:
> 
>  "There are still applications where the way data is stored matters,
> such as the protocols that move data across the Internet, which are
> defined as big-endian. So when a little-endian system needs to inspect
> or modify a network packet, it has to swap the big-endian values to
> little-endian and back, a process that can take as many as 10-20
> instructions on a RISC-V target which doesn’t implement the Zbb
> extension"
> 
> In other words, it is suggesting that RISC-V add a big-endian mode due to
> 
>  (a) internet protocols - where byte swapping is not an issue
> 
>  (b) using "some RISC-V implementations don't do the existing Zbb
> extension" as an excuse
> 
> This is plain insanity. First off, even if byte swapping was a real
> cost for networking - it's not, the real costs tend to be all in
> memory subsystems - just implement the damn Zbb extension.
> 
> Don't go "we're too incompetent to implement Zbb, so we're now asking
> that EVERYBODY ELSE feel the pain of a much *worse* extension and
> fragmenting RISC-V further".
> 
> I'm hoping this is some April fools joke, but that page is dated
> "March 10, 2025". Close, but not close enough.
> 
> This is the kind of silly stuff that just makes RISC-V look bad.
> 
> Ben - I'm afraid that that page has "further reading" pointing to codethink.
> 

> I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this
> needs to stop.

Perhaps somewhat ironically, most of the instances of CONFIG_CPU_BIG_ENDIAN
that are already in the kernel are the Zbb specific implementations of
string manipulation functions. IIRC they got added to match the Zbb spec
appendices from which the implementations are sourced and speculatively
in case BE ever did get added. The kexec users are just a straight copy
from the arm64 kexec support. None of that was really done as a
deliberate attempt to add support for BE, in case that assuages concerns
you might have about the taste of the arch maintainers..

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Linus Torvalds]

On Wed, 1 Oct 2025 at 12:03, Conor Dooley <conor@kernel.org> wrote:
>
> None of that was really done as a deliberate attempt to add support
> for BE, in case that assuages concerns you might have about the taste
> of the arch maintainers..

Thanks, it does.

As others have mentioned, the arm64 support ends up being problematic
and people are actively trying to remove it.

BE is dead. There is one good reason to support it - legacy
architectures designed and implemented back in the days when it wasn't
dead _yet_.

But it's a huge pain, and the world has moved on. Dealing with BE with
any half-way modern infrastructure is a dead end, since things like
PCIe are all fundamentally little-endian.

If somebody really wants to create bad hardware in this day and age,
please do make it big-endian, and also add the following very
traditional features for sh*t-for-brains hardware:

 - virtually tagged caches

   You can't really claim to be worst-of-the-worst without virtually
tagged caches.

  Tears of joy as you debug cache alias issues and of flushing caches
on context switches.

 - only do aligned memory accesses

   Bonus point for not even faulting, and just loading and storing
garbage instead.

 - expose your pipeline details in the ISA

   Delayed branch slots or explicit instruction grouping is a great
way to show that you eat crayons for breakfast before you start
designing your hardware platform

 - extended memory windows

   It was good enough for 8-bit machines in order to address more
memory, and became a HIGHMEM.SYS staple in the DOS world, and then got
taken up by both x86 and arm in their 32-bit days as HIGHMEM support.

   It has decades of history, and an architecture cannot be called
truly awful if it doesn't support some kind of HIGHMEM crap.

 - register windows. It's like extended memory, but for your registers!

   Please make sure to also have hardware support for filling and
spilling them, but make it limited enough that system software has to
deal with faults at critical times. Nesting exceptions is joyful!

   Bonus points if they are rotating and overflowing them silently
just corrupts data. Keep those users on their toes!

 - in fact, require software fallbacks for pretty much anything unusual.

   TLB fills? They might only happen every ten or twenty instructions,
so make them fault to some software implementation to really show your
mad hardware skillz.

   denormals or any other FP precision issues? No, no, don't waste
hardware on getting it right, software people *LOVE* to clean up after
you.

   Remember: your mom picked up your dirty laundry from your floor,
and software people are like the super-moms of the world.

 - make exceptions asynchronous.

   That's another great way to make sure people stay on their toes.
Make sure machine check exceptions can happen in any context, so that
you are guaranteed to have a dead machine any time anything goes
wrong.

   But you should also take the non-maskability of NMI to heart, and
make sure that software cannot possibly write code that is truly
atomic. Because the NM is NMI is what makes it great!

   Floating point! Make sure that the special case you don't deal with
in hardware are also delayed so that the software people have extra
joy in trying to figure out just WTF happened. See the previous entry:
they live for that stuff.

I'm sure I've forgotten many other points. And I'm sure that hardware
people will figure it out!

              Linus

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Ben Dooks]

On 30/09/2025 17:04, Linus Torvalds wrote:
> On Tue, 30 Sept 2025 at 00:25, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>>
>> Is there any chance some of the big-endian work we did is getting in
>> for this round?
> 
> Oh Christ. Is somebody seriously working on BE support in 2025?
> 
> WHY?
> 
> Seriously, that sounds like just *stupid*. Is there some actual real
> reason for this, or is it more of the "RISC-V is used in academic
> design classes and so people just want to do endianness for academic
> reasons"?
> 
> Because I'd be more than happy to just draw a line in the sand and say
> "New endianness problems are somebody ELSES problem", and tell people
> to stop being silly.
> 
> Let's not complicate things for no good reason. And there is *NO*
> reason to add new endianness.

We first tackled big-endian support on ARM32 nearly 15 years ago, and 
drawing on that experience, we saw value in doing the same work on 
RISC-V as a way for newer engineers to gain hands-on experience 
contributing in the open.

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/).

Note some of the patches we are proposing also make the code better, 
such as swapping .word for .insn.

> RISC-V is enough of a mess with the millions of silly configuration
> issues already. Don't make it even worse.

This feels like the price you pay for making a flexible and free 
ecosystem to build cores. There is no single authority making you use 
every feature that might be specified (although Ubuntu's choice to move 
forward with RVA32 for future is a current pain for anyone who already 
has purchased hardware).

See initial reply for comment on MIPS. We also don't think this a huge 
change and given most projects we worked through had few (if any) issues 
with building big endian, we thought it was worth having an attempt at this.

> Tell people to just talk to their therapists instead.  That's *much*
> more productive.


Thanks, but that isn't helpful and is just making the kernel look more 
toxic. I am however going to wear the "I got ranted at by Linus and 
survived" tag with pride.


> Really.
> 
>               Linus
> 


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Olof Johansson]

On Thu, Oct 02, 2025 at 01:48:47PM +0100, Ben Dooks wrote:
> On 30/09/2025 17:04, Linus Torvalds wrote:
> > On Tue, 30 Sept 2025 at 00:25, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> > > 
> > > Is there any chance some of the big-endian work we did is getting in
> > > for this round?
> > 
> > Oh Christ. Is somebody seriously working on BE support in 2025?
> > 
> > WHY?
> > 
> > Seriously, that sounds like just *stupid*. Is there some actual real
> > reason for this, or is it more of the "RISC-V is used in academic
> > design classes and so people just want to do endianness for academic
> > reasons"?
> > 
> > Because I'd be more than happy to just draw a line in the sand and say
> > "New endianness problems are somebody ELSES problem", and tell people
> > to stop being silly.
> > 
> > Let's not complicate things for no good reason. And there is *NO*
> > reason to add new endianness.
> 
> We first tackled big-endian support on ARM32 nearly 15 years ago, and
> drawing on that experience, we saw value in doing the same work on RISC-V as
> a way for newer engineers to gain hands-on experience contributing in the
> open.

Getting new people going is great, but if you were around for that
one you also know just how little usage it saw over time -- the ARMv8
big endian enablment has been on (minimal) life support with just some
downstream usage in vendor kernels. Adding the burden for everybody to
maintain this work forever is the flip side of the coin here.

> 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.

While I'm not happy with the lack of upstreaming from the (mostly
Chinese) SoC vendors, and we should be encouraging more of them to
contribute directly, MIPS seems to be making choices that might have
long term burden for all of us. So far the slope is slippery on the
system side, but needing to worry about BE support seems to be stepping
over the line for me without some obvious clear use cases that make sense.

> Note some of the patches we are proposing also make the code better, such as
> swapping .word for .insn.
> 
> > RISC-V is enough of a mess with the millions of silly configuration
> > issues already. Don't make it even worse.
> 
> This feels like the price you pay for making a flexible and free ecosystem
> to build cores. There is no single authority making you use every feature
> that might be specified (although Ubuntu's choice to move forward with RVA32
> for future is a current pain for anyone who already has purchased hardware).

Just because the ecosystem is flexible, doesn't mean you need to encourage
and support everything that gets built.

> See initial reply for comment on MIPS. We also don't think this a huge
> change and given most projects we worked through had few (if any) issues
> with building big endian, we thought it was worth having an attempt at this.

To me, it's not about the initial effort but about the (forever) work of
keeping it going without regressions. Now everybody will need BE CI, etc.

> > Tell people to just talk to their therapists instead.  That's *much*
> > more productive.
> 
> 
> Thanks, but that isn't helpful and is just making the kernel look more
> toxic. I am however going to wear the "I got ranted at by Linus and
> survived" tag with pride.

Hey Ben -- you posted a *RFC* of the patches in December 2024. I replied
to those. So did Palmer. With exactly these concerns. Did we get a
response from you? Nope.

So, seems like Linus has better success being impolite. That's a bummer.

For the RFC thread, see https://lore.kernel.org/all/Z2XLS2HX2KqBJW6U@chonkvm.lixom.net/


-Olof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Ben Dooks]

On 02/10/2025 16:06, Olof Johansson wrote:
> On Thu, Oct 02, 2025 at 01:48:47PM +0100, Ben Dooks wrote:
>> On 30/09/2025 17:04, Linus Torvalds wrote:
>>> On Tue, 30 Sept 2025 at 00:25, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>>>>
>>>> Is there any chance some of the big-endian work we did is getting in
>>>> for this round?
>>>
>>> Oh Christ. Is somebody seriously working on BE support in 2025?
>>>
>>> WHY?
>>>
>>> Seriously, that sounds like just *stupid*. Is there some actual real
>>> reason for this, or is it more of the "RISC-V is used in academic
>>> design classes and so people just want to do endianness for academic
>>> reasons"?
>>>
>>> Because I'd be more than happy to just draw a line in the sand and say
>>> "New endianness problems are somebody ELSES problem", and tell people
>>> to stop being silly.
>>>
>>> Let's not complicate things for no good reason. And there is *NO*
>>> reason to add new endianness.
>>
>> We first tackled big-endian support on ARM32 nearly 15 years ago, and
>> drawing on that experience, we saw value in doing the same work on RISC-V as
>> a way for newer engineers to gain hands-on experience contributing in the
>> open.
> 
> Getting new people going is great, but if you were around for that
> one you also know just how little usage it saw over time -- the ARMv8
> big endian enablment has been on (minimal) life support with just some
> downstream usage in vendor kernels. Adding the burden for everybody to
> maintain this work forever is the flip side of the coin here.
> 
>> 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.
> 
> While I'm not happy with the lack of upstreaming from the (mostly
> Chinese) SoC vendors, and we should be encouraging more of them to
> contribute directly, MIPS seems to be making choices that might have
> long term burden for all of us. So far the slope is slippery on the
> system side, but needing to worry about BE support seems to be stepping
> over the line for me without some obvious clear use cases that make sense.
> 
>> Note some of the patches we are proposing also make the code better, such as
>> swapping .word for .insn.
>>
>>> RISC-V is enough of a mess with the millions of silly configuration
>>> issues already. Don't make it even worse.
>>
>> This feels like the price you pay for making a flexible and free ecosystem
>> to build cores. There is no single authority making you use every feature
>> that might be specified (although Ubuntu's choice to move forward with RVA32
>> for future is a current pain for anyone who already has purchased hardware).
> 
> Just because the ecosystem is flexible, doesn't mean you need to encourage
> and support everything that gets built.
> 
>> See initial reply for comment on MIPS. We also don't think this a huge
>> change and given most projects we worked through had few (if any) issues
>> with building big endian, we thought it was worth having an attempt at this.
> 
> To me, it's not about the initial effort but about the (forever) work of
> keeping it going without regressions. Now everybody will need BE CI, etc.
> 
>>> Tell people to just talk to their therapists instead.  That's *much*
>>> more productive.
>>
>>
>> Thanks, but that isn't helpful and is just making the kernel look more
>> toxic. I am however going to wear the "I got ranted at by Linus and
>> survived" tag with pride.
> 
> Hey Ben -- you posted a *RFC* of the patches in December 2024. I replied
> to those. So did Palmer. With exactly these concerns. Did we get a
> response from you? Nope.
> 
> So, seems like Linus has better success being impolite. That's a bummer.
> 
> For the RFC thread, see https://lore.kernel.org/all/Z2XLS2HX2KqBJW6U@chonkvm.lixom.net/

Sorry, didn't see that and would have replied if I had.


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

https://www.codethink.co.uk/privacy.html

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Theodore Ts'o]

On Thu, Oct 02, 2025 at 01:48:47PM +0100, Ben Dooks wrote:
> 
> We first tackled big-endian support on ARM32 nearly 15 years ago, and
> drawing on that experience, we saw value in doing the same work on RISC-V as
> a way for newer engineers to gain hands-on experience contributing in the
> open.

Given the cost to the Linux kernel ecosystem as a whole, is giving
newer engineers "practice" really worth it?  I'm not convinced it is.

> > RISC-V is enough of a mess with the millions of silly configuration
> > issues already. Don't make it even worse.
> 
> This feels like the price you pay for making a flexible and free ecosystem
> to build cores.

Just because the RISC-V ecosystem wants to have a flexible ecosystem
doesn't mean that Linux kernel ecosystem is obliged to be just as
flexible, no?

					- Ted

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Yury Norov]

On Wed, Oct 01, 2025 at 11:33:21AM -0700, Eric Biggers wrote:
> On Tue, Sep 30, 2025 at 04:53:24PM -0700, Linus Torvalds wrote:
> > On Tue, 30 Sept 2025 at 09:04, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > Oh Christ. Is somebody seriously working on BE support in 2025?
> > 
> > Ok, I just googled this, and I am putting my foot down:
> > 
> >  WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V
> > 
> > The documented "reasoning" for that craziness is too stupid for words,
> > but since riscv.org did put it in words, I'll just quote those words
> > here:
> > 
> >  "There are still applications where the way data is stored matters,
> > such as the protocols that move data across the Internet, which are
> > defined as big-endian. So when a little-endian system needs to inspect
> > or modify a network packet, it has to swap the big-endian values to
> > little-endian and back, a process that can take as many as 10-20
> > instructions on a RISC-V target which doesn’t implement the Zbb
> > extension"
> > 
> > In other words, it is suggesting that RISC-V add a big-endian mode due to
> > 
> >  (a) internet protocols - where byte swapping is not an issue
> > 
> >  (b) using "some RISC-V implementations don't do the existing Zbb
> > extension" as an excuse
> > 
> > This is plain insanity. First off, even if byte swapping was a real
> > cost for networking - it's not, the real costs tend to be all in
> > memory subsystems - just implement the damn Zbb extension.
> > 
> > Don't go "we're too incompetent to implement Zbb, so we're now asking
> > that EVERYBODY ELSE feel the pain of a much *worse* extension and
> > fragmenting RISC-V further".
> > 
> > I'm hoping this is some April fools joke, but that page is dated
> > "March 10, 2025". Close, but not close enough.
> > 
> > This is the kind of silly stuff that just makes RISC-V look bad.
> > 
> > Ben - I'm afraid that that page has "further reading" pointing to codethink.
> > 
> > I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this
> > needs to stop.
> > 
> > The mainline kernel is for mainline development. Not for random
> > experiments that make the world a worse place.
> > 
> > And yes, we're open source, and that very much means that anybody is
> > more than welcome to try to prove me wrong.
> > 
> > If it turns out that BE RISC-V becomes a real thing that is relevant
> > and actually finds a place in the RISC-V ecosystem, then _of_course_
> > we should support it at that point in the mainline kernel.
> > 
> > But I really do think that it actually makes RISC-V only worse, and
> > that we should *not* actively help the fragmentation.
> 
> +1.  Please, let's not do big endian RISC-V kernels :(
> 
> This mistake was made for arm64, it's finally getting fixed.
> See https://lore.kernel.org/r/20250919184025.15416-1-will@kernel.org/
> Let's not make the same mistake again.
> 
> And as someone who works on optimized crypto and CRC code, the arm64 big
> endian kernel support has always been really problematic.  It's rarely
> tested, and code that produces incorrect outputs on arm64 big endian
> regularly gets committed and released.  It sometimes gets fixed, but not
> always; currently the arm64 SM3 and SM4 code produces incorrect outputs
> on big endian in mainline.  (I don't really care enough to fix it, TBH.)
> 
> I recently added arm64 big endian to my own testing matrix.  But I look
> forward to dropping that, as well as *not* having to start testing on
> RISC-V big endian too...
> 
> Of course, that's just one example from my own experience.  There's a
> lot more that CONFIG_CPU_BIG_ENDIAN creates problems for.

+2. I maintain bitops, and I routinely have to take endianess into
account.

I just realized that I didn't run BE kernels for at least 3 years, and
didn't ask my contributors to do it for even more. The last BE-related
fix for bitops I can recall is dated back to 2020:

81c4f4d924d5d009 ("lib: fix bitmap_parse() on 64-bit big endian archs").

Nobody ever reported BE bugs for the new code.

Maintenance burden is not just a word. Things are getting really tricky
when you have to keep BE compatibility in mind. And it's a special
torture to run an old arm or sparc VM in BE-32 against modern kernels.

But what really important is that dropping BE support will make codebase
overall cleaner and better.

Thanks,
Yury

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Maciej W. Rozycki]

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.

 The thing is based on my experience I'm fairly sure it's all just driven 
by company customers, which have their legacy MIPS code base or whatever 
and want to switch with minimum effort.  And for a hardware company to 
support a customer it's obviously easier to tweak hardware rather than 
software.

 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.

> While I'm not happy with the lack of upstreaming from the (mostly
> Chinese) SoC vendors, and we should be encouraging more of them to
> contribute directly, MIPS seems to be making choices that might have
> long term burden for all of us. So far the slope is slippery on the
> system side, but needing to worry about BE support seems to be stepping
> over the line for me without some obvious clear use cases that make sense.

 Whether we're going to accept things dumped onto us is another matter.  
There's plenty of code downstream that hasn't made it here, and going back 
to my examples, we've never got microMIPSr6 support in Linux even though 
it used to live downstream, and attempts continue being made to get this 
stuff upstreamed across the board.  We may or may not choose to accept 
bits that make our life tougher, and there have been precedents across 
free software, such as the RS6000/PowerPC GCC backend maintainer refusing 
to take changes adding support for the VLE instruction set.

 FYI and FWIW,

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Yao Zi]

Hi Paul, Palmer,

On Mon, Sep 29, 2025 at 02:00:17AM -0600, Paul Walmsley wrote:
> Linus,
> 
> The following changes since commit a03ee11b8f850bd008226c6d392da24163dfb56e:
> 
>   riscv: Fix sparse warning about different address spaces (2025-09-05 15:33:52 -0600)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux tags/riscv-for-linus-6.18-mw1
> 
> for you to fetch changes up to 0b0ca959d20689fece038954bbf1d7b14c0b11c3:
> 
>   riscv: errata: Fix the PAUSE Opcode for MIPS P8700 (2025-09-19 10:33:56 -0600)

...

> Guo Ren (Alibaba DAMO Academy) (1):
>       riscv: Move vendor errata definitions to new header

As already noted by Han Gao[1], it seems the second patch of series
"riscv: errata: Add ERRATA_THEAD_WRITE_ONCE fixup"[2] is included in the
pull request for 6.17-rc1, but not this one for 6.18-rc1. Is this
expected?

Best regards,
Yao Zi

[1]: https://lore.kernel.org/all/CAAT7Ki9_Vm0+v9RHpa2w-Bg3agJy2Tp4d6+tcPJ=M7XX3GV-7Q@mail.gmail.com/
[2]: https://lore.kernel.org/all/20250713155321.2064856-1-guoren@kernel.org/

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Paul Walmsley]

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv