[PATCH v2 00/16] Add RISC-V big-endian target support

[PATCH v2 00/16] Add RISC-V big-endian target support

[Djordje Todorovic]

This series adds big-endian (BE) RISC-V target support to QEMU,
covering both softmmu and linux-user emulation for riscv32be and
riscv64be.
 
The RISC-V ISA supports big-endian operation via the mstatus SBE/MBE/UBE
bits. While instructions are always little-endian, data accesses follow
the configured endianness. This series implements the necessary QEMU
infrastructure.

Furthermore, MIPS announced cores with BE configuration:
  https://mips.com/products/hardware/i8500/

Patches 01-03: Build system and config for new BE targets
Patches 04-07: Core emulation fixes (instruction fetch, boot ROM, ELF
               loading, fw_dynamic endianness)
Patches 08-11: Linux-user BE targets and vDSO handling
Patch  12:     Set SBE/MBE mstatus bits at CPU reset
Patch  13:     Fix PTE A/D atomic update endianness in page table walker
Patch  14:     Clean up instruction fetch to use MO_LE directly
Patch  15:     Fix virtio-mmio legacy device register endianness
Patch  16:     Add riscv32be and riscv64be to SysEmuTarget

Djordje Todorovic (9):
  meson: Add BE RISCV targets
  config/targets: Add BE RISCV softmmu targets
  config/devices: Add BE riscv configs
  target/riscv: Ensure LE instruction fetching
  hw/riscv: Ensure bootrom has correct endianess
  hw/riscv: Ensure proper ELF endian expectation
  hw/riscv: Check endianness for fw_dynamic fields
  config/targets: Add RISC-V userspace targets
  arch/riscv: Set UBE bit on BE target

djtodoro (7):
  config/targets: Add missing fields to BE linux-user targets
  linux-user/riscv: Disable vDSO for big-endian targets
  target/riscv: Set SBE and MBE bits at CPU reset for BE targets
  target/riscv: Fix PTE A/D atomic update endianness
  target/riscv: Use MO_LE for instruction fetch
  hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops
  qapi: Add riscv32be and riscv64be to SysEmuTarget

 configs/devices/riscv32be-softmmu/default.mak | 15 +++++++
 configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++
 configs/targets/riscv32be-linux-user.mak      | 11 +++++
 configs/targets/riscv32be-softmmu.mak         |  8 ++++
 configs/targets/riscv64be-linux-user.mak      | 11 +++++
 configs/targets/riscv64be-softmmu.mak         |  8 ++++
 hw/riscv/boot.c                               | 41 ++++++++++++++++---
 hw/virtio/virtio-mmio.c                       |  2 +-
 include/hw/riscv/boot.h                       |  5 +++
 linux-user/riscv/target_elf.h                 | 10 ++++-
 meson.build                                   |  7 +++-
 qapi/machine.json                             |  3 +-
 target/riscv/cpu.c                            |  3 ++
 target/riscv/cpu_bits.h                       |  2 +
 target/riscv/cpu_helper.c                     |  9 ++--
 target/riscv/translate.c                      | 16 ++++----
 16 files changed, 145 insertions(+), 22 deletions(-)
 create mode 100644 configs/devices/riscv32be-softmmu/default.mak
 create mode 100644 configs/devices/riscv64be-softmmu/default.mak
 create mode 100644 configs/targets/riscv32be-linux-user.mak
 create mode 100644 configs/targets/riscv32be-softmmu.mak
 create mode 100644 configs/targets/riscv64be-linux-user.mak
 create mode 100644 configs/targets/riscv64be-softmmu.mak

-- 
2.34.1

[PATCH v2 03/16] config/devices: Add BE riscv configs

[Djordje Todorovic]

Add new configs for BE RISCV softmmu targets.
---
 configs/devices/riscv32be-softmmu/default.mak | 15 +++++++++++++++
 configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++++++++++
 2 files changed, 31 insertions(+)
 create mode 100644 configs/devices/riscv32be-softmmu/default.mak
 create mode 100644 configs/devices/riscv64be-softmmu/default.mak

diff --git a/configs/devices/riscv32be-softmmu/default.mak b/configs/devices/riscv32be-softmmu/default.mak
new file mode 100644
index 0000000000..d847bd5692
--- /dev/null
+++ b/configs/devices/riscv32be-softmmu/default.mak
@@ -0,0 +1,15 @@
+# Default configuration for riscv32-softmmu
+
+# Uncomment the following lines to disable these optional devices:
+#
+#CONFIG_PCI_DEVICES=n
+CONFIG_SEMIHOSTING=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
+
+# Boards:
+#
+CONFIG_SPIKE=y
+CONFIG_SIFIVE_E=y
+CONFIG_SIFIVE_U=y
+CONFIG_RISCV_VIRT=y
+CONFIG_OPENTITAN=y
diff --git a/configs/devices/riscv64be-softmmu/default.mak b/configs/devices/riscv64be-softmmu/default.mak
new file mode 100644
index 0000000000..bc69301fa4
--- /dev/null
+++ b/configs/devices/riscv64be-softmmu/default.mak
@@ -0,0 +1,16 @@
+# Default configuration for riscv64-softmmu
+
+# Uncomment the following lines to disable these optional devices:
+#
+#CONFIG_PCI_DEVICES=n
+CONFIG_SEMIHOSTING=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
+
+# Boards:
+#
+CONFIG_SPIKE=y
+CONFIG_SIFIVE_E=y
+CONFIG_SIFIVE_U=y
+CONFIG_RISCV_VIRT=y
+CONFIG_MICROCHIP_PFSOC=y
+CONFIG_SHAKTI_C=y
-- 
2.34.1

[PATCH v2 02/16] config/targets: Add BE RISCV softmmu targets

[Djordje Todorovic]

Add new RISCV softmmu targets that define TARGET_BIG_ENDIAN=1
---
 configs/targets/riscv32be-softmmu.mak | 8 ++++++++
 configs/targets/riscv64be-softmmu.mak | 8 ++++++++
 2 files changed, 16 insertions(+)
 create mode 100644 configs/targets/riscv32be-softmmu.mak
 create mode 100644 configs/targets/riscv64be-softmmu.mak

diff --git a/configs/targets/riscv32be-softmmu.mak b/configs/targets/riscv32be-softmmu.mak
new file mode 100644
index 0000000000..27c7467a43
--- /dev/null
+++ b/configs/targets/riscv32be-softmmu.mak
@@ -0,0 +1,8 @@
+TARGET_ARCH=riscv32
+TARGET_BASE_ARCH=riscv
+TARGET_SUPPORTS_MTTCG=y
+TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-32bit-virtual.xml
+TARGET_NEED_FDT=y
+TARGET_BIG_ENDIAN=y
+TARGET_LONG_BITS=32
+TARGET_NOT_USING_LEGACY_LDST_PHYS_API=y
diff --git a/configs/targets/riscv64be-softmmu.mak b/configs/targets/riscv64be-softmmu.mak
new file mode 100644
index 0000000000..528ecea2f8
--- /dev/null
+++ b/configs/targets/riscv64be-softmmu.mak
@@ -0,0 +1,8 @@
+TARGET_ARCH=riscv64
+TARGET_BASE_ARCH=riscv
+TARGET_SUPPORTS_MTTCG=y
+TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-64bit-virtual.xml
+TARGET_NEED_FDT=y
+TARGET_BIG_ENDIAN=y
+TARGET_LONG_BITS=64
+TARGET_NOT_USING_LEGACY_LDST_PHYS_API=y
-- 
2.34.1

[PATCH v2 01/16] meson: Add BE RISCV targets

[Djordje Todorovic]

Add options to compile riscv64be-softmmu and riscv32be-softmmu
---
 meson.build | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 8c6c0a9a32..41ad38d184 100644
--- a/meson.build
+++ b/meson.build
@@ -55,6 +55,11 @@ supported_cpus = ['ppc64', 's390x', 'riscv64', 'x86_64',
 
 cpu = host_machine.cpu_family()
 
+# Unify riscv64be to riscv64.
+if cpu == 'riscv64be'
+  cpu = 'riscv64'
+endif
+
 target_dirs = config_host['TARGET_DIRS'].split()
 
 # type of binaries to build
@@ -281,7 +286,7 @@ elif cpu == 'ppc64'
 elif cpu == 'mips64'
   kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', 'mips64el-softmmu']
 elif cpu == 'riscv64'
-  kvm_targets = ['riscv64-softmmu']
+  kvm_targets = ['riscv32-softmmu', 'riscv64-softmmu', 'riscv32be-softmmu', 'riscv64be-softmmu']
 elif cpu == 'loongarch64'
   kvm_targets = ['loongarch64-softmmu']
 else
-- 
2.34.1

Re: [PATCH v2 01/16] meson: Add BE RISCV targets

[Thomas Huth]

On 25/02/2026 11.20, Djordje Todorovic wrote:
> Add options to compile riscv64be-softmmu and riscv32be-softmmu
> ---
>   meson.build | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 8c6c0a9a32..41ad38d184 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -55,6 +55,11 @@ supported_cpus = ['ppc64', 's390x', 'riscv64', 'x86_64',
>   
>   cpu = host_machine.cpu_family()
>   
> +# Unify riscv64be to riscv64.
> +if cpu == 'riscv64be'
> +  cpu = 'riscv64'
> +endif
> +
>   target_dirs = config_host['TARGET_DIRS'].split()
>   
>   # type of binaries to build
> @@ -281,7 +286,7 @@ elif cpu == 'ppc64'
>   elif cpu == 'mips64'
>     kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', 'mips64el-softmmu']
>   elif cpu == 'riscv64'
> -  kvm_targets = ['riscv64-softmmu']
> +  kvm_targets = ['riscv32-softmmu', 'riscv64-softmmu', 'riscv32be-softmmu', 'riscv64be-softmmu']

I really dislike the idea of having yet another target like mips where we 
have 4 different flavours (32/64 bits x big/little endian). That increases 
the compile- and testing time a lot. Couldn't you do it the ppc64 way? The 
ppc64-softmmu target can handle both, big and little endian, no need for a 
separate binary here. And we are going the same way with microblaze now - 
the microblaze target recently got support for little endian, so we can 
finally get rid of the microblazeel target now.

  Thanks,
   Thomas

Re: [PATCH v2 01/16] meson: Add BE RISCV targets

[Chao Liu]

On Wed, Feb 25, 2026 at 11:39:50AM +0100, Thomas Huth wrote:
> On 25/02/2026 11.20, Djordje Todorovic wrote:
> > Add options to compile riscv64be-softmmu and riscv32be-softmmu
> > ---
> >   meson.build | 7 ++++++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 8c6c0a9a32..41ad38d184 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -55,6 +55,11 @@ supported_cpus = ['ppc64', 's390x', 'riscv64', 'x86_64',
> >   cpu = host_machine.cpu_family()
> > +# Unify riscv64be to riscv64.
> > +if cpu == 'riscv64be'
> > +  cpu = 'riscv64'
> > +endif
> > +
> >   target_dirs = config_host['TARGET_DIRS'].split()
> >   # type of binaries to build
> > @@ -281,7 +286,7 @@ elif cpu == 'ppc64'
> >   elif cpu == 'mips64'
> >     kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', 'mips64el-softmmu']
> >   elif cpu == 'riscv64'
> > -  kvm_targets = ['riscv64-softmmu']
> > +  kvm_targets = ['riscv32-softmmu', 'riscv64-softmmu', 'riscv32be-softmmu', 'riscv64be-softmmu']
> 
> I really dislike the idea of having yet another target like mips where we
> have 4 different flavours (32/64 bits x big/little endian). That increases
> the compile- and testing time a lot. Couldn't you do it the ppc64 way? The
+1

Additionally, since upstream Linux does not yet support big-endian
RISC-V, I'd suggest focusing on the softmmu big-endian implementation
within the existing riscv32/riscv64 targets first.

Thanks,
Chao

> ppc64-softmmu target can handle both, big and little endian, no need for a
> separate binary here. And we are going the same way with microblaze now -
> the microblaze target recently got support for little endian, so we can
> finally get rid of the microblazeel target now.
> 
>  Thanks,
>   Thomas
> 
> 

Re: [PATCH v2 01/16] meson: Add BE RISCV targets

[Daniel P. Berrangé]

On Wed, Feb 25, 2026 at 11:39:50AM +0100, Thomas Huth wrote:
> On 25/02/2026 11.20, Djordje Todorovic wrote:
> > Add options to compile riscv64be-softmmu and riscv32be-softmmu
> > ---
> >   meson.build | 7 ++++++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 8c6c0a9a32..41ad38d184 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -55,6 +55,11 @@ supported_cpus = ['ppc64', 's390x', 'riscv64', 'x86_64',
> >   cpu = host_machine.cpu_family()
> > +# Unify riscv64be to riscv64.
> > +if cpu == 'riscv64be'
> > +  cpu = 'riscv64'
> > +endif
> > +
> >   target_dirs = config_host['TARGET_DIRS'].split()
> >   # type of binaries to build
> > @@ -281,7 +286,7 @@ elif cpu == 'ppc64'
> >   elif cpu == 'mips64'
> >     kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', 'mips64el-softmmu']
> >   elif cpu == 'riscv64'
> > -  kvm_targets = ['riscv64-softmmu']
> > +  kvm_targets = ['riscv32-softmmu', 'riscv64-softmmu', 'riscv32be-softmmu', 'riscv64be-softmmu']
> 
> I really dislike the idea of having yet another target like mips where we
> have 4 different flavours (32/64 bits x big/little endian). That increases
> the compile- and testing time a lot. Couldn't you do it the ppc64 way? The
> ppc64-softmmu target can handle both, big and little endian, no need for a
> separate binary here. And we are going the same way with microblaze now -
> the microblaze target recently got support for little endian, so we can
> finally get rid of the microblazeel target now.

Also with the ongoing work to make a single QEMU binary that can
support any target, it feels like any problems with handling big
and little endian in a single binary will need to be solved
regardless, so if practical we should align with that direction
from the start.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH v2 01/16] meson: Add BE RISCV targets

[Alistair Francis]

On Wed, Feb 25, 2026 at 10:30 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Wed, Feb 25, 2026 at 11:39:50AM +0100, Thomas Huth wrote:
> > On 25/02/2026 11.20, Djordje Todorovic wrote:
> > > Add options to compile riscv64be-softmmu and riscv32be-softmmu
> > > ---
> > >   meson.build | 7 ++++++-
> > >   1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meson.build b/meson.build
> > > index 8c6c0a9a32..41ad38d184 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -55,6 +55,11 @@ supported_cpus = ['ppc64', 's390x', 'riscv64', 'x86_64',
> > >   cpu = host_machine.cpu_family()
> > > +# Unify riscv64be to riscv64.
> > > +if cpu == 'riscv64be'
> > > +  cpu = 'riscv64'
> > > +endif
> > > +
> > >   target_dirs = config_host['TARGET_DIRS'].split()
> > >   # type of binaries to build
> > > @@ -281,7 +286,7 @@ elif cpu == 'ppc64'
> > >   elif cpu == 'mips64'
> > >     kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', 'mips64el-softmmu']
> > >   elif cpu == 'riscv64'
> > > -  kvm_targets = ['riscv64-softmmu']
> > > +  kvm_targets = ['riscv32-softmmu', 'riscv64-softmmu', 'riscv32be-softmmu', 'riscv64be-softmmu']

We really don't want a 32-bit KVM target at all

> >
> > I really dislike the idea of having yet another target like mips where we
> > have 4 different flavours (32/64 bits x big/little endian). That increases
> > the compile- and testing time a lot. Couldn't you do it the ppc64 way? The
> > ppc64-softmmu target can handle both, big and little endian, no need for a
> > separate binary here. And we are going the same way with microblaze now -
> > the microblaze target recently got support for little endian, so we can
> > finally get rid of the microblazeel target now.
>
> Also with the ongoing work to make a single QEMU binary that can
> support any target, it feels like any problems with handling big
> and little endian in a single binary will need to be solved
> regardless, so if practical we should align with that direction
> from the start.

Exactly. We are working towards a single RISC-V  binary for all bit
lengths. Big endian would have to start out included in the existing
builds

Alistair

>
>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>

Re: [PATCH v2 01/16] meson: Add BE RISCV targets

[Daniel P. Berrangé]

On Wed, Feb 25, 2026 at 10:20:25AM +0000, Djordje Todorovic wrote:
> Add options to compile riscv64be-softmmu and riscv32be-softmmu
> ---
>  meson.build | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index 8c6c0a9a32..41ad38d184 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -55,6 +55,11 @@ supported_cpus = ['ppc64', 's390x', 'riscv64', 'x86_64',
>  
>  cpu = host_machine.cpu_family()
>  
> +# Unify riscv64be to riscv64.
> +if cpu == 'riscv64be'
> +  cpu = 'riscv64'
> +endif
> +
>  target_dirs = config_host['TARGET_DIRS'].split()
>  
>  # type of binaries to build
> @@ -281,7 +286,7 @@ elif cpu == 'ppc64'
>  elif cpu == 'mips64'
>    kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', 'mips64el-softmmu']
>  elif cpu == 'riscv64'
> -  kvm_targets = ['riscv64-softmmu']
> +  kvm_targets = ['riscv32-softmmu', 'riscv64-softmmu', 'riscv32be-softmmu', 'riscv64be-softmmu']

The suibject says its adding "BE" targets, but this is also adding
a 32-bit little endian target.

Does KVM, actually support running riscv32 guests on a riscv64
host ?  If so, this change to add 32-bit KVM should likely be
done as its own commit separate from this big endian series.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

[PATCH v2 05/16] hw/riscv: Ensure bootrom has correct endianess

[Djordje Todorovic]

---
 hw/riscv/boot.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index e5490beda0..dc9f8a7327 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -31,6 +31,7 @@
 #include "system/qtest.h"
 #include "system/kvm.h"
 #include "system/reset.h"
+#include "exec/tswap.h"
 
 #include <libfdt.h>
 
@@ -439,10 +440,24 @@ void riscv_setup_rom_reset_vec(MachineState *machine, RISCVHartArrayState *harts
     uint32_t start_addr_hi32 = 0x00000000;
     uint32_t fdt_load_addr_hi32 = 0x00000000;
 
+    start_addr = tswap32(start_addr);
+    fdt_load_addr = tswap32(fdt_load_addr);
+
     if (!riscv_is_32bit(harts)) {
-        start_addr_hi32 = start_addr >> 32;
-        fdt_load_addr_hi32 = fdt_load_addr >> 32;
+        start_addr_hi32 = tswap32(start_addr >> 32);
+        fdt_load_addr_hi32 = tswap32(fdt_load_addr >> 32);
+    
+         if (target_needs_bswap()) {
+            uint32_t temp = start_addr;
+            start_addr = start_addr_hi32;
+            start_addr_hi32 = temp;
+
+            temp = fdt_load_addr;
+            fdt_load_addr = fdt_load_addr_hi32;
+            fdt_load_addr_hi32 = temp;
+        }
     }
+
     /* reset vector */
     uint32_t reset_vec[10] = {
         0x00000297,                  /* 1:  auipc  t0, %pcrel_hi(fw_dyn) */
-- 
2.34.1

[PATCH v2 06/16] hw/riscv: Ensure proper ELF endian expectation

[Djordje Todorovic]

load_elf_ram_sym has a `big_endian` paramater that notifies
it if the loaded elf file is expected to be LE or BE. This
paramater needs to be set based on target endianess to ensure
proper elf loading.
---
 hw/riscv/boot.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index dc9f8a7327..6dab521a6b 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -166,7 +166,8 @@ hwaddr riscv_load_firmware(const char *firmware_filename,
 
     if (load_elf_ram_sym(firmware_filename, NULL, NULL, NULL,
                          &firmware_entry, NULL, &firmware_end, NULL,
-                         0, EM_RISCV, 1, 0, NULL, true, sym_cb) > 0) {
+                         TARGET_BIG_ENDIAN ? ELFDATA2MSB : ELFDATA2LSB,
+                         EM_RISCV, 1, 0, NULL, true, sym_cb) > 0) {
         *firmware_load_addr = firmware_entry;
         return firmware_end;
     }
@@ -248,8 +249,9 @@ void riscv_load_kernel(MachineState *machine,
      */
     kernel_size = load_elf_ram_sym(kernel_filename, NULL, NULL, NULL, NULL,
                                    &info->image_low_addr, &info->image_high_addr,
-                                   NULL, ELFDATA2LSB, EM_RISCV,
-                                   1, 0, NULL, true, sym_cb);
+                                   NULL,
+                                   TARGET_BIG_ENDIAN ? ELFDATA2MSB : ELFDATA2LSB,
+                                   EM_RISCV, 1, 0, NULL, true, sym_cb);
     if (kernel_size > 0) {
         info->kernel_size = kernel_size;
         goto out;
-- 
2.34.1

Re: [PATCH v2 06/16] hw/riscv: Ensure proper ELF endian expectation

[Philippe Mathieu-Daudé]

On 25/2/26 11:20, Djordje Todorovic wrote:
> load_elf_ram_sym has a `big_endian` paramater that notifies
> it if the loaded elf file is expected to be LE or BE. This
> paramater needs to be set based on target endianess to ensure
> proper elf loading.
> ---
>   hw/riscv/boot.c | 8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> index dc9f8a7327..6dab521a6b 100644
> --- a/hw/riscv/boot.c
> +++ b/hw/riscv/boot.c
> @@ -166,7 +166,8 @@ hwaddr riscv_load_firmware(const char *firmware_filename,
>   
>       if (load_elf_ram_sym(firmware_filename, NULL, NULL, NULL,
>                            &firmware_entry, NULL, &firmware_end, NULL,
> -                         0, EM_RISCV, 1, 0, NULL, true, sym_cb) > 0) {
> +                         TARGET_BIG_ENDIAN ? ELFDATA2MSB : ELFDATA2LSB,
> +                         EM_RISCV, 1, 0, NULL, true, sym_cb) > 0) {
>           *firmware_load_addr = firmware_entry;
>           return firmware_end;
>       }
> @@ -248,8 +249,9 @@ void riscv_load_kernel(MachineState *machine,
>        */
>       kernel_size = load_elf_ram_sym(kernel_filename, NULL, NULL, NULL, NULL,
>                                      &info->image_low_addr, &info->image_high_addr,
> -                                   NULL, ELFDATA2LSB, EM_RISCV,
> -                                   1, 0, NULL, true, sym_cb);
> +                                   NULL,
> +                                   TARGET_BIG_ENDIAN ? ELFDATA2MSB : ELFDATA2LSB,
> +                                   EM_RISCV, 1, 0, NULL, true, sym_cb);

See commit c36ec3a9655 ("hw/microblaze/s3adsp1800: Explicit CPU
endianness") and around.

[PATCH v2 04/16] target/riscv: Ensure LE instruction fetching

[Djordje Todorovic]

With the insroduction of BE RISCV target, instruction fetching
needs to always expect instructions to be LE encoded as specified
by the RISCV specification.
---
 target/riscv/translate.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index f687c75fe4..67dfb5f1c0 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -23,6 +23,8 @@
 #include "exec/helper-proto.h"
 #include "exec/helper-gen.h"
 #include "exec/target_page.h"
+#include "exec/tswap.h"
+
 #include "exec/translator.h"
 #include "accel/tcg/cpu-ldst.h"
 #include "exec/translation-block.h"
@@ -302,7 +304,7 @@ static void gen_goto_tb(DisasContext *ctx, unsigned tb_slot_idx,
                         target_long diff)
 {
     target_ulong dest = ctx->base.pc_next + diff;
-
+    
      /*
       * Under itrigger, instruction executes one by one like singlestep,
       * direct block chain benefits will be small.
@@ -617,7 +619,7 @@ static void gen_ctr_jal(DisasContext *ctx, int rd, target_ulong imm)
 static void gen_jal(DisasContext *ctx, int rd, target_ulong imm)
 {
     TCGv succ_pc = dest_gpr(ctx, rd);
-
+    
     /* check misaligned: */
     if (!riscv_cpu_allow_16bit_insn(ctx->cfg_ptr,
                                     ctx->priv_ver,
@@ -1253,13 +1255,13 @@ static void decode_opc(CPURISCVState *env, DisasContext *ctx)
          * real one is 2 or 4 bytes. Instruction preload wouldn't trigger
          * additional page fault.
          */
-        opcode = translator_ldl(env, &ctx->base, ctx->base.pc_next);
+        opcode = tswap32(translator_ldl(env, &ctx->base, ctx->base.pc_next));
     } else {
         /*
          * For unaligned pc, instruction preload may trigger additional
          * page fault so we only load 2 bytes here.
          */
-        opcode = (uint32_t) translator_lduw(env, &ctx->base, ctx->base.pc_next);
+        opcode = (uint32_t) tswap16(translator_lduw(env, &ctx->base, ctx->base.pc_next));
     }
     ctx->ol = ctx->xl;
 
@@ -1278,9 +1280,9 @@ static void decode_opc(CPURISCVState *env, DisasContext *ctx)
     } else {
         if (!pc_is_4byte_align) {
             /* Load last 2 bytes of instruction here */
-            opcode = deposit32(opcode, 16, 16,
-                               translator_lduw(env, &ctx->base,
-                                               ctx->base.pc_next + 2));
+            uint16_t opcode_hi = translator_lduw(env, &ctx->base,
+                                                 ctx->base.pc_next + 2);
+            opcode = deposit32(opcode, 16, 16, tswap16(opcode_hi));
         }
         ctx->opcode = opcode;
 
@@ -1396,6 +1398,7 @@ static void riscv_tr_translate_insn(DisasContextBase *dcbase, CPUState *cpu)
             if (page_ofs > TARGET_PAGE_SIZE - MAX_INSN_LEN) {
                 uint16_t next_insn =
                     translator_lduw(env, &ctx->base, ctx->base.pc_next);
+                next_insn = tswap16(next_insn);
                 int len = insn_len(next_insn);
 
                 if (!translator_is_same_page(&ctx->base, ctx->base.pc_next + len - 1)) {
-- 
2.34.1

Re: [PATCH v2 04/16] target/riscv: Ensure LE instruction fetching

[Philippe Mathieu-Daudé]

On 25/2/26 11:20, Djordje Todorovic wrote:
> With the insroduction of BE RISCV target, instruction fetching
> needs to always expect instructions to be LE encoded as specified
> by the RISCV specification.
> ---
>   target/riscv/translate.c | 17 ++++++++++-------
>   1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index f687c75fe4..67dfb5f1c0 100644
> --- a/target/riscv/translate.c
> +++ b/target/riscv/translate.c
> @@ -23,6 +23,8 @@
>   #include "exec/helper-proto.h"
>   #include "exec/helper-gen.h"
>   #include "exec/target_page.h"
> +#include "exec/tswap.h"
> +
>   #include "exec/translator.h"
>   #include "accel/tcg/cpu-ldst.h"
>   #include "exec/translation-block.h"
> @@ -302,7 +304,7 @@ static void gen_goto_tb(DisasContext *ctx, unsigned tb_slot_idx,
>                           target_long diff)
>   {
>       target_ulong dest = ctx->base.pc_next + diff;
> -
> +
>        /*
>         * Under itrigger, instruction executes one by one like singlestep,
>         * direct block chain benefits will be small.
> @@ -617,7 +619,7 @@ static void gen_ctr_jal(DisasContext *ctx, int rd, target_ulong imm)
>   static void gen_jal(DisasContext *ctx, int rd, target_ulong imm)
>   {
>       TCGv succ_pc = dest_gpr(ctx, rd);
> -
> +
>       /* check misaligned: */
>       if (!riscv_cpu_allow_16bit_insn(ctx->cfg_ptr,
>                                       ctx->priv_ver,
> @@ -1253,13 +1255,13 @@ static void decode_opc(CPURISCVState *env, DisasContext *ctx)
>            * real one is 2 or 4 bytes. Instruction preload wouldn't trigger
>            * additional page fault.
>            */
> -        opcode = translator_ldl(env, &ctx->base, ctx->base.pc_next);
> +        opcode = tswap32(translator_ldl(env, &ctx->base, ctx->base.pc_next));
>       } else {
>           /*
>            * For unaligned pc, instruction preload may trigger additional
>            * page fault so we only load 2 bytes here.
>            */
> -        opcode = (uint32_t) translator_lduw(env, &ctx->base, ctx->base.pc_next);
> +        opcode = (uint32_t) tswap16(translator_lduw(env, &ctx->base, ctx->base.pc_next));
>       }
>       ctx->ol = ctx->xl;
>   
> @@ -1278,9 +1280,9 @@ static void decode_opc(CPURISCVState *env, DisasContext *ctx)
>       } else {
>           if (!pc_is_4byte_align) {
>               /* Load last 2 bytes of instruction here */
> -            opcode = deposit32(opcode, 16, 16,
> -                               translator_lduw(env, &ctx->base,
> -                                               ctx->base.pc_next + 2));
> +            uint16_t opcode_hi = translator_lduw(env, &ctx->base,
> +                                                 ctx->base.pc_next + 2);
> +            opcode = deposit32(opcode, 16, 16, tswap16(opcode_hi));
>           }
>           ctx->opcode = opcode;
>   
> @@ -1396,6 +1398,7 @@ static void riscv_tr_translate_insn(DisasContextBase *dcbase, CPUState *cpu)
>               if (page_ofs > TARGET_PAGE_SIZE - MAX_INSN_LEN) {
>                   uint16_t next_insn =
>                       translator_lduw(env, &ctx->base, ctx->base.pc_next);
> +                next_insn = tswap16(next_insn);
>                   int len = insn_len(next_insn);
>   
>                   if (!translator_is_same_page(&ctx->base, ctx->base.pc_next + len - 1)) {

Per commit a31f16bdd4a ("target/riscv: Inline translator_ld[uw,l,q]
calls") you shouldn't need that.

This series base branch is outdated.

[PATCH v2 09/16] arch/riscv: Set UBE bit on BE target

[Djordje Todorovic]

When the RISC-V target is built as big-endian, ensure that is signaled
in mstatus via UBE bit.
---
 target/riscv/cpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index e95eea0249..0e24f2cbcd 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -716,6 +716,9 @@ static void riscv_cpu_reset_hold(Object *obj, ResetType type)
             env->mstatus = set_field(env->mstatus, MSTATUS_MDT, 1);
         }
     }
+#if defined(TARGET_BIG_ENDIAN)
+    env->mstatus |= MSTATUS_UBE;
+#endif
     env->mcause = 0;
     env->miclaim = MIP_SGEIP;
     env->pc = env->resetvec;
-- 
2.34.1

Re: [PATCH v2 09/16] arch/riscv: Set UBE bit on BE target

[Philippe Mathieu-Daudé]

On 25/2/26 11:20, Djordje Todorovic wrote:
> When the RISC-V target is built as big-endian, ensure that is signaled
> in mstatus via UBE bit.
> ---
>   target/riscv/cpu.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index e95eea0249..0e24f2cbcd 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -716,6 +716,9 @@ static void riscv_cpu_reset_hold(Object *obj, ResetType type)
>               env->mstatus = set_field(env->mstatus, MSTATUS_MDT, 1);
>           }
>       }
> +#if defined(TARGET_BIG_ENDIAN)
> +    env->mstatus |= MSTATUS_UBE;
> +#endif

You should update mo_endian_env() instead IMO.

[PATCH v2 07/16] hw/riscv: Check endianness for fw_dynamic fields

[Djordje Todorovic]

For riscvbe target, the fields for OpenSBI's fw_payload
need to be in target endian.
---
 hw/riscv/boot.c         | 14 ++++++++++++++
 include/hw/riscv/boot.h |  5 +++++
 2 files changed, 19 insertions(+)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index 6dab521a6b..f13264a87f 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -396,19 +396,33 @@ void riscv_rom_copy_firmware_info(MachineState *machine,
     size_t dinfo_len;
 
     if (riscv_is_32bit(harts)) {
+#if TARGET_BIG_ENDIAN
+        dinfo32.magic = cpu_to_be32(FW_DYNAMIC_INFO_MAGIC_VALUE);
+        dinfo32.version = cpu_to_be32(FW_DYNAMIC_INFO_VERSION);
+        dinfo32.next_mode = cpu_to_be32(FW_DYNAMIC_INFO_NEXT_MODE_S);
+        dinfo32.next_addr = cpu_to_be32(kernel_entry);
+#else
         dinfo32.magic = cpu_to_le32(FW_DYNAMIC_INFO_MAGIC_VALUE);
         dinfo32.version = cpu_to_le32(FW_DYNAMIC_INFO_VERSION);
         dinfo32.next_mode = cpu_to_le32(FW_DYNAMIC_INFO_NEXT_MODE_S);
         dinfo32.next_addr = cpu_to_le32(kernel_entry);
+#endif
         dinfo32.options = 0;
         dinfo32.boot_hart = 0;
         dinfo_ptr = &dinfo32;
         dinfo_len = sizeof(dinfo32);
     } else {
+#if TARGET_BIG_ENDIAN
+        dinfo64.magic = cpu_to_be64(FW_DYNAMIC_INFO_MAGIC_VALUE);
+        dinfo64.version = cpu_to_be64(FW_DYNAMIC_INFO_VERSION);
+        dinfo64.next_mode = cpu_to_be64(FW_DYNAMIC_INFO_NEXT_MODE_S);
+        dinfo64.next_addr = cpu_to_be64(kernel_entry);
+#else
         dinfo64.magic = cpu_to_le64(FW_DYNAMIC_INFO_MAGIC_VALUE);
         dinfo64.version = cpu_to_le64(FW_DYNAMIC_INFO_VERSION);
         dinfo64.next_mode = cpu_to_le64(FW_DYNAMIC_INFO_NEXT_MODE_S);
         dinfo64.next_addr = cpu_to_le64(kernel_entry);
+#endif
         dinfo64.options = 0;
         dinfo64.boot_hart = 0;
         dinfo_ptr = &dinfo64;
diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
index f00b3ca122..6a6b796eee 100644
--- a/include/hw/riscv/boot.h
+++ b/include/hw/riscv/boot.h
@@ -24,8 +24,13 @@
 #include "hw/core/loader.h"
 #include "hw/riscv/riscv_hart.h"
 
+#if TARGET_BIG_ENDIAN
+#define RISCV32_BIOS_BIN    "opensbi-riscv32be-generic-fw_dynamic.bin"
+#define RISCV64_BIOS_BIN    "opensbi-riscv64be-generic-fw_dynamic.bin"
+#else
 #define RISCV32_BIOS_BIN    "opensbi-riscv32-generic-fw_dynamic.bin"
 #define RISCV64_BIOS_BIN    "opensbi-riscv64-generic-fw_dynamic.bin"
+#endif
 
 typedef struct RISCVBootInfo {
     ssize_t kernel_size;
-- 
2.34.1

Re: [PATCH v2 07/16] hw/riscv: Check endianness for fw_dynamic fields

[Alistair Francis]

On Wed, Feb 25, 2026 at 8:20 PM Djordje Todorovic
<Djordje.Todorovic@htecgroup.com> wrote:
>
> For riscvbe target, the fields for OpenSBI's fw_payload
> need to be in target endian.
> ---
>  hw/riscv/boot.c         | 14 ++++++++++++++
>  include/hw/riscv/boot.h |  5 +++++
>  2 files changed, 19 insertions(+)
>
> diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
> index 6dab521a6b..f13264a87f 100644
> --- a/hw/riscv/boot.c
> +++ b/hw/riscv/boot.c
> @@ -396,19 +396,33 @@ void riscv_rom_copy_firmware_info(MachineState *machine,
>      size_t dinfo_len;
>
>      if (riscv_is_32bit(harts)) {
> +#if TARGET_BIG_ENDIAN

This will need to be done without adding any TARGET_BIG_ENDIAN macros.
We don't want to have custom built binaries

Alistair

> +        dinfo32.magic = cpu_to_be32(FW_DYNAMIC_INFO_MAGIC_VALUE);
> +        dinfo32.version = cpu_to_be32(FW_DYNAMIC_INFO_VERSION);
> +        dinfo32.next_mode = cpu_to_be32(FW_DYNAMIC_INFO_NEXT_MODE_S);
> +        dinfo32.next_addr = cpu_to_be32(kernel_entry);
> +#else
>          dinfo32.magic = cpu_to_le32(FW_DYNAMIC_INFO_MAGIC_VALUE);
>          dinfo32.version = cpu_to_le32(FW_DYNAMIC_INFO_VERSION);
>          dinfo32.next_mode = cpu_to_le32(FW_DYNAMIC_INFO_NEXT_MODE_S);
>          dinfo32.next_addr = cpu_to_le32(kernel_entry);
> +#endif
>          dinfo32.options = 0;
>          dinfo32.boot_hart = 0;
>          dinfo_ptr = &dinfo32;
>          dinfo_len = sizeof(dinfo32);
>      } else {
> +#if TARGET_BIG_ENDIAN
> +        dinfo64.magic = cpu_to_be64(FW_DYNAMIC_INFO_MAGIC_VALUE);
> +        dinfo64.version = cpu_to_be64(FW_DYNAMIC_INFO_VERSION);
> +        dinfo64.next_mode = cpu_to_be64(FW_DYNAMIC_INFO_NEXT_MODE_S);
> +        dinfo64.next_addr = cpu_to_be64(kernel_entry);
> +#else
>          dinfo64.magic = cpu_to_le64(FW_DYNAMIC_INFO_MAGIC_VALUE);
>          dinfo64.version = cpu_to_le64(FW_DYNAMIC_INFO_VERSION);
>          dinfo64.next_mode = cpu_to_le64(FW_DYNAMIC_INFO_NEXT_MODE_S);
>          dinfo64.next_addr = cpu_to_le64(kernel_entry);
> +#endif
>          dinfo64.options = 0;
>          dinfo64.boot_hart = 0;
>          dinfo_ptr = &dinfo64;
> diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
> index f00b3ca122..6a6b796eee 100644
> --- a/include/hw/riscv/boot.h
> +++ b/include/hw/riscv/boot.h
> @@ -24,8 +24,13 @@
>  #include "hw/core/loader.h"
>  #include "hw/riscv/riscv_hart.h"
>
> +#if TARGET_BIG_ENDIAN
> +#define RISCV32_BIOS_BIN    "opensbi-riscv32be-generic-fw_dynamic.bin"
> +#define RISCV64_BIOS_BIN    "opensbi-riscv64be-generic-fw_dynamic.bin"
> +#else
>  #define RISCV32_BIOS_BIN    "opensbi-riscv32-generic-fw_dynamic.bin"
>  #define RISCV64_BIOS_BIN    "opensbi-riscv64-generic-fw_dynamic.bin"
> +#endif
>
>  typedef struct RISCVBootInfo {
>      ssize_t kernel_size;
> --
> 2.34.1

Re: [PATCH v2 07/16] hw/riscv: Check endianness for fw_dynamic fields

[Philippe Mathieu-Daudé]

On 27/2/26 00:32, Alistair Francis wrote:
> On Wed, Feb 25, 2026 at 8:20 PM Djordje Todorovic
> <Djordje.Todorovic@htecgroup.com> wrote:
>>
>> For riscvbe target, the fields for OpenSBI's fw_payload
>> need to be in target endian.
>> ---
>>   hw/riscv/boot.c         | 14 ++++++++++++++
>>   include/hw/riscv/boot.h |  5 +++++
>>   2 files changed, 19 insertions(+)
>>
>> diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
>> index 6dab521a6b..f13264a87f 100644
>> --- a/hw/riscv/boot.c
>> +++ b/hw/riscv/boot.c
>> @@ -396,19 +396,33 @@ void riscv_rom_copy_firmware_info(MachineState *machine,
>>       size_t dinfo_len;
>>
>>       if (riscv_is_32bit(harts)) {
>> +#if TARGET_BIG_ENDIAN
> 
> This will need to be done without adding any TARGET_BIG_ENDIAN macros.
> We don't want to have custom built binaries

Indeed. You should check the HART endianness.

An useful exercise is to consider a system with 2 HARTs running
in different endianness. QEMU should be able to run that setup.

> 
> Alistair

[PATCH v2 08/16] config/targets: Add RISC-V userspace targets

[Djordje Todorovic]

This commit adds necessary tagets to build Qemu for RISC-V userspace
emulation.
---
 configs/targets/riscv32be-linux-user.mak | 7 +++++++
 configs/targets/riscv64be-linux-user.mak | 7 +++++++
 2 files changed, 14 insertions(+)
 create mode 100644 configs/targets/riscv32be-linux-user.mak
 create mode 100644 configs/targets/riscv64be-linux-user.mak

diff --git a/configs/targets/riscv32be-linux-user.mak b/configs/targets/riscv32be-linux-user.mak
new file mode 100644
index 0000000000..bca84945d9
--- /dev/null
+++ b/configs/targets/riscv32be-linux-user.mak
@@ -0,0 +1,7 @@
+TARGET_ARCH=riscv32
+TARGET_BASE_ARCH=riscv
+TARGET_ABI_DIR=riscv
+TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-32bit-virtual.xml
+CONFIG_SEMIHOSTING=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
+TARGET_BIG_ENDIAN=y
diff --git a/configs/targets/riscv64be-linux-user.mak b/configs/targets/riscv64be-linux-user.mak
new file mode 100644
index 0000000000..ff4fade9ef
--- /dev/null
+++ b/configs/targets/riscv64be-linux-user.mak
@@ -0,0 +1,7 @@
+TARGET_ARCH=riscv64
+TARGET_BASE_ARCH=riscv
+TARGET_ABI_DIR=riscv
+TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-64bit-virtual.xml
+CONFIG_SEMIHOSTING=y
+CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
+TARGET_BIG_ENDIAN=y
-- 
2.34.1

Re: [PATCH v2 08/16] config/targets: Add RISC-V userspace targets

[Philippe Mathieu-Daudé]

On 25/2/26 11:20, Djordje Todorovic wrote:
> This commit adds necessary tagets to build Qemu for RISC-V userspace
> emulation.
> ---
>   configs/targets/riscv32be-linux-user.mak | 7 +++++++
>   configs/targets/riscv64be-linux-user.mak | 7 +++++++
>   2 files changed, 14 insertions(+)
>   create mode 100644 configs/targets/riscv32be-linux-user.mak
>   create mode 100644 configs/targets/riscv64be-linux-user.mak
> 
> diff --git a/configs/targets/riscv32be-linux-user.mak b/configs/targets/riscv32be-linux-user.mak
> new file mode 100644
> index 0000000000..bca84945d9
> --- /dev/null
> +++ b/configs/targets/riscv32be-linux-user.mak
> @@ -0,0 +1,7 @@
> +TARGET_ARCH=riscv32
> +TARGET_BASE_ARCH=riscv
> +TARGET_ABI_DIR=riscv
> +TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml gdb-xml/riscv-64bit-fpu.xml gdb-xml/riscv-32bit-virtual.xml
> +CONFIG_SEMIHOSTING=y
> +CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
> +TARGET_BIG_ENDIAN=y

See commit 91fc6d8101d ("linux-user/microblaze: Fix little-endianness
binary") and its references.

[PATCH v2 12/16] target/riscv: Set SBE and MBE bits at CPU reset for BE targets

[Djordje Todorovic]

From: djtodoro <djordje.todorovic@htecgroup.com>

Define MSTATUS_SBE (bit 36) and MSTATUS_MBE (bit 37) and set them alongside MSTATUS_UBE at CPU reset for big-endian targets.
---
 target/riscv/cpu.c      | 2 +-
 target/riscv/cpu_bits.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 0e24f2cbcd..c446cae75f 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -717,7 +717,7 @@ static void riscv_cpu_reset_hold(Object *obj, ResetType type)
         }
     }
 #if defined(TARGET_BIG_ENDIAN)
-    env->mstatus |= MSTATUS_UBE;
+    env->mstatus |= MSTATUS_UBE | MSTATUS_SBE | MSTATUS_MBE;
 #endif
     env->mcause = 0;
     env->miclaim = MIP_SGEIP;
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index b62dd82fe7..3f146a43fe 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -629,6 +629,8 @@
 #define MSTATUS_SPELP       0x00800000 /* zicfilp */
 #define MSTATUS_SDT         0x01000000
 #define MSTATUS_MPELP       0x020000000000 /* zicfilp */
+#define MSTATUS_SBE         0x1000000000ULL
+#define MSTATUS_MBE         0x2000000000ULL
 #define MSTATUS_GVA         0x4000000000ULL
 #define MSTATUS_MPV         0x8000000000ULL
 #define MSTATUS_MDT         0x40000000000ULL /* Smdbltrp extension */
-- 
2.34.1

[PATCH v2 11/16] linux-user/riscv: Disable vDSO for big-endian targets

[Djordje Todorovic]

From: djtodoro <djordje.todorovic@htecgroup.com>

---
 linux-user/riscv/target_elf.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/linux-user/riscv/target_elf.h b/linux-user/riscv/target_elf.h
index dbbfdf54d3..6f416ac3e2 100644
--- a/linux-user/riscv/target_elf.h
+++ b/linux-user/riscv/target_elf.h
@@ -12,10 +12,16 @@
 
 #ifdef TARGET_RISCV32
 #define ELF_CLASS               ELFCLASS32
-#define VDSO_HEADER             "vdso-32.c.inc"
 #else
 #define ELF_CLASS               ELFCLASS64
-#define VDSO_HEADER             "vdso-64.c.inc"
+#endif
+
+#if !TARGET_BIG_ENDIAN
+# ifdef TARGET_RISCV32
+#  define VDSO_HEADER            "vdso-32.c.inc"
+# else
+#  define VDSO_HEADER            "vdso-64.c.inc"
+# endif
 #endif
 
 #define HAVE_ELF_HWCAP          1
-- 
2.34.1

Re: [PATCH v2 11/16] linux-user/riscv: Disable vDSO for big-endian targets

[Alistair Francis]

On Wed, Feb 25, 2026 at 8:20 PM Djordje Todorovic
<Djordje.Todorovic@htecgroup.com> wrote:
>

Why?

Alistair

> From: djtodoro <djordje.todorovic@htecgroup.com>
>
> ---
>  linux-user/riscv/target_elf.h | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/linux-user/riscv/target_elf.h b/linux-user/riscv/target_elf.h
> index dbbfdf54d3..6f416ac3e2 100644
> --- a/linux-user/riscv/target_elf.h
> +++ b/linux-user/riscv/target_elf.h
> @@ -12,10 +12,16 @@
>
>  #ifdef TARGET_RISCV32
>  #define ELF_CLASS               ELFCLASS32
> -#define VDSO_HEADER             "vdso-32.c.inc"
>  #else
>  #define ELF_CLASS               ELFCLASS64
> -#define VDSO_HEADER             "vdso-64.c.inc"
> +#endif
> +
> +#if !TARGET_BIG_ENDIAN
> +# ifdef TARGET_RISCV32
> +#  define VDSO_HEADER            "vdso-32.c.inc"
> +# else
> +#  define VDSO_HEADER            "vdso-64.c.inc"
> +# endif
>  #endif
>
>  #define HAVE_ELF_HWCAP          1
> --
> 2.34.1

Re: [PATCH v2 11/16] linux-user/riscv: Disable vDSO for big-endian targets

[Philippe Mathieu-Daudé]

On 27/2/26 00:33, Alistair Francis wrote:
> On Wed, Feb 25, 2026 at 8:20 PM Djordje Todorovic
> <Djordje.Todorovic@htecgroup.com> wrote:
>>
> 
> Why?

I suppose we need to rename linux-user/riscv/vdso-32.so
-> linux-user/riscv/vdso-32le.so and build / commit the
vdso-32be.so equivalent. Similarly for 64-bit.

> 
> Alistair
> 
>> From: djtodoro <djordje.todorovic@htecgroup.com>
>>
>> ---
>>   linux-user/riscv/target_elf.h | 10 ++++++++--
>>   1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/linux-user/riscv/target_elf.h b/linux-user/riscv/target_elf.h
>> index dbbfdf54d3..6f416ac3e2 100644
>> --- a/linux-user/riscv/target_elf.h
>> +++ b/linux-user/riscv/target_elf.h
>> @@ -12,10 +12,16 @@
>>
>>   #ifdef TARGET_RISCV32
>>   #define ELF_CLASS               ELFCLASS32
>> -#define VDSO_HEADER             "vdso-32.c.inc"
>>   #else
>>   #define ELF_CLASS               ELFCLASS64
>> -#define VDSO_HEADER             "vdso-64.c.inc"
>> +#endif
>> +
>> +#if !TARGET_BIG_ENDIAN
>> +# ifdef TARGET_RISCV32
>> +#  define VDSO_HEADER            "vdso-32.c.inc"
>> +# else
>> +#  define VDSO_HEADER            "vdso-64.c.inc"
>> +# endif
>>   #endif
>>
>>   #define HAVE_ELF_HWCAP          1
>> --
>> 2.34.1

[PATCH v2 10/16] config/targets: Add missing fields to BE linux-user targets

[Djordje Todorovic]

From: djtodoro <djordje.todorovic@htecgroup.com>

---
 configs/targets/riscv32be-linux-user.mak | 4 ++++
 configs/targets/riscv64be-linux-user.mak | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/configs/targets/riscv32be-linux-user.mak b/configs/targets/riscv32be-linux-user.mak
index bca84945d9..4654eb41ed 100644
--- a/configs/targets/riscv32be-linux-user.mak
+++ b/configs/targets/riscv32be-linux-user.mak
@@ -5,3 +5,7 @@ TARGET_XML_FILES= gdb-xml/riscv-32bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml gdb-xm
 CONFIG_SEMIHOSTING=y
 CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
 TARGET_BIG_ENDIAN=y
+TARGET_SYSTBL_ABI=32
+TARGET_SYSTBL_ABI=common,32,riscv,memfd_secret
+TARGET_SYSTBL=syscall.tbl
+TARGET_LONG_BITS=32
diff --git a/configs/targets/riscv64be-linux-user.mak b/configs/targets/riscv64be-linux-user.mak
index ff4fade9ef..4217d172c4 100644
--- a/configs/targets/riscv64be-linux-user.mak
+++ b/configs/targets/riscv64be-linux-user.mak
@@ -5,3 +5,7 @@ TARGET_XML_FILES= gdb-xml/riscv-64bit-cpu.xml gdb-xml/riscv-32bit-fpu.xml gdb-xm
 CONFIG_SEMIHOSTING=y
 CONFIG_ARM_COMPATIBLE_SEMIHOSTING=y
 TARGET_BIG_ENDIAN=y
+TARGET_SYSTBL_ABI=64
+TARGET_SYSTBL_ABI=common,64,riscv,rlimit,memfd_secret
+TARGET_SYSTBL=syscall.tbl
+TARGET_LONG_BITS=64
-- 
2.34.1

[PATCH v2 15/16] hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops

[Djordje Todorovic]

From: djtodoro <djordje.todorovic@htecgroup.com>

The virtio-mmio transport registers are always little-endian per spec.
DEVICE_NATIVE_ENDIAN caused a double byte-swap on BE targets, making
the kernel see a swapped magic value.
---
 hw/virtio/virtio-mmio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-mmio.c b/hw/virtio/virtio-mmio.c
index 0b0412b22f..92ff793d2c 100644
--- a/hw/virtio/virtio-mmio.c
+++ b/hw/virtio/virtio-mmio.c
@@ -527,7 +527,7 @@ static void virtio_mmio_write(void *opaque, hwaddr offset, uint64_t value,
 static const MemoryRegionOps virtio_legacy_mem_ops = {
     .read = virtio_mmio_read,
     .write = virtio_mmio_write,
-    .endianness = DEVICE_NATIVE_ENDIAN,
+    .endianness = DEVICE_LITTLE_ENDIAN,
 };
 
 static const MemoryRegionOps virtio_mem_ops = {
-- 
2.34.1

[PATCH v2 13/16] target/riscv: Fix PTE A/D atomic update endianness

[Djordje Todorovic]

From: djtodoro <djordje.todorovic@htecgroup.com>

Use tswap32/tswap64 instead of hardcoded cpu_to_le32/le64 for PTE
atomic compare-and-swap updates, so the encoding matches how PTEs
are read via address_space_ldl/ldq (target endian).
---
 target/riscv/cpu_helper.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index dd6c861a90..f6990b2dfa 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -37,6 +37,7 @@
 #include "debug.h"
 #include "pmp.h"
 #include "qemu/plugin.h"
+#include "exec/tswap.h"
 
 int riscv_env_mmu_index(CPURISCVState *env, bool ifetch)
 {
@@ -1567,11 +1568,11 @@ static int get_physical_address(CPURISCVState *env, hwaddr *physical,
             target_ulong *pte_pa = qemu_map_ram_ptr(mr->ram_block, addr1);
             target_ulong old_pte;
             if (riscv_cpu_sxl(env) == MXL_RV32) {
-                old_pte = qatomic_cmpxchg((uint32_t *)pte_pa, cpu_to_le32(pte), cpu_to_le32(updated_pte));
-                old_pte = le32_to_cpu(old_pte);
+                old_pte = qatomic_cmpxchg((uint32_t *)pte_pa, tswap32(pte), tswap32(updated_pte));
+                old_pte = tswap32(old_pte);
             } else {
-                old_pte = qatomic_cmpxchg(pte_pa, cpu_to_le64(pte), cpu_to_le64(updated_pte));
-                old_pte = le64_to_cpu(old_pte);
+                old_pte = qatomic_cmpxchg(pte_pa, tswap64(pte), tswap64(updated_pte));
+                old_pte = tswap64(old_pte);
             }
             if (old_pte != pte) {
                 goto restart;
-- 
2.34.1

Re: [PATCH v2 13/16] target/riscv: Fix PTE A/D atomic update endianness

[Philippe Mathieu-Daudé]

On 25/2/26 11:20, Djordje Todorovic wrote:
> From: djtodoro <djordje.todorovic@htecgroup.com>
> 
> Use tswap32/tswap64 instead of hardcoded cpu_to_le32/le64 for PTE
> atomic compare-and-swap updates, so the encoding matches how PTEs
> are read via address_space_ldl/ldq (target endian).
> ---
>   target/riscv/cpu_helper.c | 9 +++++----
>   1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index dd6c861a90..f6990b2dfa 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -37,6 +37,7 @@
>   #include "debug.h"
>   #include "pmp.h"
>   #include "qemu/plugin.h"
> +#include "exec/tswap.h"
>   
>   int riscv_env_mmu_index(CPURISCVState *env, bool ifetch)
>   {
> @@ -1567,11 +1568,11 @@ static int get_physical_address(CPURISCVState *env, hwaddr *physical,
>               target_ulong *pte_pa = qemu_map_ram_ptr(mr->ram_block, addr1);

Should we use address_space_ld[l/q]_le() with the HART AS (via @env)
here instead of accessing the RAMBlock manually?

>               target_ulong old_pte;
>               if (riscv_cpu_sxl(env) == MXL_RV32) {
> -                old_pte = qatomic_cmpxchg((uint32_t *)pte_pa, cpu_to_le32(pte), cpu_to_le32(updated_pte));
> -                old_pte = le32_to_cpu(old_pte);
> +                old_pte = qatomic_cmpxchg((uint32_t *)pte_pa, tswap32(pte), tswap32(updated_pte));
> +                old_pte = tswap32(old_pte);
>               } else {
> -                old_pte = qatomic_cmpxchg(pte_pa, cpu_to_le64(pte), cpu_to_le64(updated_pte));
> -                old_pte = le64_to_cpu(old_pte);
> +                old_pte = qatomic_cmpxchg(pte_pa, tswap64(pte), tswap64(updated_pte));
> +                old_pte = tswap64(old_pte);
>               }
>               if (old_pte != pte) {
>                   goto restart;

[PATCH v2 14/16] target/riscv: Use MO_LE for instruction fetch

[Djordje Todorovic]

From: djtodoro <djordje.todorovic@htecgroup.com>

RISC-V instructions are always little-endian. Use translator_ldl_end
and translator_lduw_end with MO_LE instead of tswap on translator_ldl
results.
---
 target/riscv/translate.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 67dfb5f1c0..57dfc68220 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -23,8 +23,6 @@
 #include "exec/helper-proto.h"
 #include "exec/helper-gen.h"
 #include "exec/target_page.h"
-#include "exec/tswap.h"
-
 #include "exec/translator.h"
 #include "accel/tcg/cpu-ldst.h"
 #include "exec/translation-block.h"
@@ -1255,13 +1253,13 @@ static void decode_opc(CPURISCVState *env, DisasContext *ctx)
          * real one is 2 or 4 bytes. Instruction preload wouldn't trigger
          * additional page fault.
          */
-        opcode = tswap32(translator_ldl(env, &ctx->base, ctx->base.pc_next));
+        opcode = translator_ldl_end(env, &ctx->base, ctx->base.pc_next, MO_LE);
     } else {
         /*
          * For unaligned pc, instruction preload may trigger additional
          * page fault so we only load 2 bytes here.
          */
-        opcode = (uint32_t) tswap16(translator_lduw(env, &ctx->base, ctx->base.pc_next));
+        opcode = (uint32_t) translator_lduw_end(env, &ctx->base, ctx->base.pc_next, MO_LE);
     }
     ctx->ol = ctx->xl;
 
@@ -1280,9 +1278,9 @@ static void decode_opc(CPURISCVState *env, DisasContext *ctx)
     } else {
         if (!pc_is_4byte_align) {
             /* Load last 2 bytes of instruction here */
-            uint16_t opcode_hi = translator_lduw(env, &ctx->base,
-                                                 ctx->base.pc_next + 2);
-            opcode = deposit32(opcode, 16, 16, tswap16(opcode_hi));
+            uint16_t opcode_hi = translator_lduw_end(env, &ctx->base,
+                                                     ctx->base.pc_next + 2, MO_LE);
+            opcode = deposit32(opcode, 16, 16, opcode_hi);
         }
         ctx->opcode = opcode;
 
@@ -1397,8 +1395,7 @@ static void riscv_tr_translate_insn(DisasContextBase *dcbase, CPUState *cpu)
 
             if (page_ofs > TARGET_PAGE_SIZE - MAX_INSN_LEN) {
                 uint16_t next_insn =
-                    translator_lduw(env, &ctx->base, ctx->base.pc_next);
-                next_insn = tswap16(next_insn);
+                    translator_lduw_end(env, &ctx->base, ctx->base.pc_next, MO_LE);
                 int len = insn_len(next_insn);
 
                 if (!translator_is_same_page(&ctx->base, ctx->base.pc_next + len - 1)) {
-- 
2.34.1

Re: [PATCH v2 14/16] target/riscv: Use MO_LE for instruction fetch

[Philippe Mathieu-Daudé]

On 25/2/26 11:20, Djordje Todorovic wrote:
> From: djtodoro <djordje.todorovic@htecgroup.com>
> 
> RISC-V instructions are always little-endian. Use translator_ldl_end
> and translator_lduw_end with MO_LE instead of tswap on translator_ldl
> results.

OK, but this contradicts your previous own patch in this series:
[PATCH v2 04/16] target/riscv: Ensure LE instruction fetching

Squash them?

> ---
>   target/riscv/translate.c | 15 ++++++---------
>   1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index 67dfb5f1c0..57dfc68220 100644
> --- a/target/riscv/translate.c
> +++ b/target/riscv/translate.c
> @@ -23,8 +23,6 @@
>   #include "exec/helper-proto.h"
>   #include "exec/helper-gen.h"
>   #include "exec/target_page.h"
> -#include "exec/tswap.h"
> -
>   #include "exec/translator.h"
>   #include "accel/tcg/cpu-ldst.h"
>   #include "exec/translation-block.h"
> @@ -1255,13 +1253,13 @@ static void decode_opc(CPURISCVState *env, DisasContext *ctx)
>            * real one is 2 or 4 bytes. Instruction preload wouldn't trigger
>            * additional page fault.
>            */
> -        opcode = tswap32(translator_ldl(env, &ctx->base, ctx->base.pc_next));
> +        opcode = translator_ldl_end(env, &ctx->base, ctx->base.pc_next, MO_LE);
>       } else {
>           /*
>            * For unaligned pc, instruction preload may trigger additional
>            * page fault so we only load 2 bytes here.
>            */
> -        opcode = (uint32_t) tswap16(translator_lduw(env, &ctx->base, ctx->base.pc_next));
> +        opcode = (uint32_t) translator_lduw_end(env, &ctx->base, ctx->base.pc_next, MO_LE);
>       }
>       ctx->ol = ctx->xl;
>   
> @@ -1280,9 +1278,9 @@ static void decode_opc(CPURISCVState *env, DisasContext *ctx)
>       } else {
>           if (!pc_is_4byte_align) {
>               /* Load last 2 bytes of instruction here */
> -            uint16_t opcode_hi = translator_lduw(env, &ctx->base,
> -                                                 ctx->base.pc_next + 2);
> -            opcode = deposit32(opcode, 16, 16, tswap16(opcode_hi));
> +            uint16_t opcode_hi = translator_lduw_end(env, &ctx->base,
> +                                                     ctx->base.pc_next + 2, MO_LE);
> +            opcode = deposit32(opcode, 16, 16, opcode_hi);
>           }
>           ctx->opcode = opcode;
>   
> @@ -1397,8 +1395,7 @@ static void riscv_tr_translate_insn(DisasContextBase *dcbase, CPUState *cpu)
>   
>               if (page_ofs > TARGET_PAGE_SIZE - MAX_INSN_LEN) {
>                   uint16_t next_insn =
> -                    translator_lduw(env, &ctx->base, ctx->base.pc_next);
> -                next_insn = tswap16(next_insn);
> +                    translator_lduw_end(env, &ctx->base, ctx->base.pc_next, MO_LE);
>                   int len = insn_len(next_insn);
>   
>                   if (!translator_is_same_page(&ctx->base, ctx->base.pc_next + len - 1)) {

[PATCH v2 16/16] qapi: Add riscv32be and riscv64be to SysEmuTarget

[Djordje Todorovic]

From: djtodoro <djordje.todorovic@htecgroup.com>

---
 qapi/machine.json | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/qapi/machine.json b/qapi/machine.json
index 907cb25f75..b62b8a1896 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -38,7 +38,8 @@
   'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'hppa', 'i386',
              'loongarch64', 'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
              'mips64el', 'mipsel', 'or1k', 'ppc',
-             'ppc64', 'riscv32', 'riscv64', 'rx', 's390x', 'sh4',
+             'ppc64', 'riscv32', 'riscv32be', 'riscv64', 'riscv64be',
+             'rx', 's390x', 'sh4',
              'sh4eb', 'sparc', 'sparc64', 'tricore',
              'x86_64', 'xtensa', 'xtensaeb' ] }
 
-- 
2.34.1

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Mohamed Mediouni]

> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> 
> This series adds big-endian (BE) RISC-V target support to QEMU,
> covering both softmmu and linux-user emulation for riscv32be and
> riscv64be.
Hello,

There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?

Thank you,
-Mohamed 
> 
> The RISC-V ISA supports big-endian operation via the mstatus SBE/MBE/UBE
> bits. While instructions are always little-endian, data accesses follow
> the configured endianness. This series implements the necessary QEMU
> infrastructure.
> 
> Furthermore, MIPS announced cores with BE configuration:
>  https://mips.com/products/hardware/i8500/
> 
> Patches 01-03: Build system and config for new BE targets
> Patches 04-07: Core emulation fixes (instruction fetch, boot ROM, ELF
>               loading, fw_dynamic endianness)
> Patches 08-11: Linux-user BE targets and vDSO handling
> Patch  12:     Set SBE/MBE mstatus bits at CPU reset
> Patch  13:     Fix PTE A/D atomic update endianness in page table walker
> Patch  14:     Clean up instruction fetch to use MO_LE directly
> Patch  15:     Fix virtio-mmio legacy device register endianness
> Patch  16:     Add riscv32be and riscv64be to SysEmuTarget
> 
> Djordje Todorovic (9):
>  meson: Add BE RISCV targets
>  config/targets: Add BE RISCV softmmu targets
>  config/devices: Add BE riscv configs
>  target/riscv: Ensure LE instruction fetching
>  hw/riscv: Ensure bootrom has correct endianess
>  hw/riscv: Ensure proper ELF endian expectation
>  hw/riscv: Check endianness for fw_dynamic fields
>  config/targets: Add RISC-V userspace targets
>  arch/riscv: Set UBE bit on BE target
> 
> djtodoro (7):
>  config/targets: Add missing fields to BE linux-user targets
>  linux-user/riscv: Disable vDSO for big-endian targets
>  target/riscv: Set SBE and MBE bits at CPU reset for BE targets
>  target/riscv: Fix PTE A/D atomic update endianness
>  target/riscv: Use MO_LE for instruction fetch
>  hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops
>  qapi: Add riscv32be and riscv64be to SysEmuTarget
> 
> configs/devices/riscv32be-softmmu/default.mak | 15 +++++++
> configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++
> configs/targets/riscv32be-linux-user.mak      | 11 +++++
> configs/targets/riscv32be-softmmu.mak         |  8 ++++
> configs/targets/riscv64be-linux-user.mak      | 11 +++++
> configs/targets/riscv64be-softmmu.mak         |  8 ++++
> hw/riscv/boot.c                               | 41 ++++++++++++++++---
> hw/virtio/virtio-mmio.c                       |  2 +-
> include/hw/riscv/boot.h                       |  5 +++
> linux-user/riscv/target_elf.h                 | 10 ++++-
> meson.build                                   |  7 +++-
> qapi/machine.json                             |  3 +-
> target/riscv/cpu.c                            |  3 ++
> target/riscv/cpu_bits.h                       |  2 +
> target/riscv/cpu_helper.c                     |  9 ++--
> target/riscv/translate.c                      | 16 ++++----
> 16 files changed, 145 insertions(+), 22 deletions(-)
> create mode 100644 configs/devices/riscv32be-softmmu/default.mak
> create mode 100644 configs/devices/riscv64be-softmmu/default.mak
> create mode 100644 configs/targets/riscv32be-linux-user.mak
> create mode 100644 configs/targets/riscv32be-softmmu.mak
> create mode 100644 configs/targets/riscv64be-linux-user.mak
> create mode 100644 configs/targets/riscv64be-softmmu.mak
> 
> -- 
> 2.34.1
> 

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Alistair Francis]

On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
<mohamed@unpredictable.fr> wrote:
>
>
>
> > On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> >
> > This series adds big-endian (BE) RISC-V target support to QEMU,
> > covering both softmmu and linux-user emulation for riscv32be and
> > riscv64be.
> Hello,
>
> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?

Agreed. We really need upstream Linux support before user mode

>
> Thank you,
> -Mohamed
> >
> > The RISC-V ISA supports big-endian operation via the mstatus SBE/MBE/UBE
> > bits. While instructions are always little-endian, data accesses follow
> > the configured endianness. This series implements the necessary QEMU
> > infrastructure.

How are you testing this?

Alistair

> >
> > Furthermore, MIPS announced cores with BE configuration:
> >  https://mips.com/products/hardware/i8500/
> >
> > Patches 01-03: Build system and config for new BE targets
> > Patches 04-07: Core emulation fixes (instruction fetch, boot ROM, ELF
> >               loading, fw_dynamic endianness)
> > Patches 08-11: Linux-user BE targets and vDSO handling
> > Patch  12:     Set SBE/MBE mstatus bits at CPU reset
> > Patch  13:     Fix PTE A/D atomic update endianness in page table walker
> > Patch  14:     Clean up instruction fetch to use MO_LE directly
> > Patch  15:     Fix virtio-mmio legacy device register endianness
> > Patch  16:     Add riscv32be and riscv64be to SysEmuTarget
> >
> > Djordje Todorovic (9):
> >  meson: Add BE RISCV targets
> >  config/targets: Add BE RISCV softmmu targets
> >  config/devices: Add BE riscv configs
> >  target/riscv: Ensure LE instruction fetching
> >  hw/riscv: Ensure bootrom has correct endianess
> >  hw/riscv: Ensure proper ELF endian expectation
> >  hw/riscv: Check endianness for fw_dynamic fields
> >  config/targets: Add RISC-V userspace targets
> >  arch/riscv: Set UBE bit on BE target
> >
> > djtodoro (7):
> >  config/targets: Add missing fields to BE linux-user targets
> >  linux-user/riscv: Disable vDSO for big-endian targets
> >  target/riscv: Set SBE and MBE bits at CPU reset for BE targets
> >  target/riscv: Fix PTE A/D atomic update endianness
> >  target/riscv: Use MO_LE for instruction fetch
> >  hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops
> >  qapi: Add riscv32be and riscv64be to SysEmuTarget
> >
> > configs/devices/riscv32be-softmmu/default.mak | 15 +++++++
> > configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++
> > configs/targets/riscv32be-linux-user.mak      | 11 +++++
> > configs/targets/riscv32be-softmmu.mak         |  8 ++++
> > configs/targets/riscv64be-linux-user.mak      | 11 +++++
> > configs/targets/riscv64be-softmmu.mak         |  8 ++++
> > hw/riscv/boot.c                               | 41 ++++++++++++++++---
> > hw/virtio/virtio-mmio.c                       |  2 +-
> > include/hw/riscv/boot.h                       |  5 +++
> > linux-user/riscv/target_elf.h                 | 10 ++++-
> > meson.build                                   |  7 +++-
> > qapi/machine.json                             |  3 +-
> > target/riscv/cpu.c                            |  3 ++
> > target/riscv/cpu_bits.h                       |  2 +
> > target/riscv/cpu_helper.c                     |  9 ++--
> > target/riscv/translate.c                      | 16 ++++----
> > 16 files changed, 145 insertions(+), 22 deletions(-)
> > create mode 100644 configs/devices/riscv32be-softmmu/default.mak
> > create mode 100644 configs/devices/riscv64be-softmmu/default.mak
> > create mode 100644 configs/targets/riscv32be-linux-user.mak
> > create mode 100644 configs/targets/riscv32be-softmmu.mak
> > create mode 100644 configs/targets/riscv64be-linux-user.mak
> > create mode 100644 configs/targets/riscv64be-softmmu.mak
> >
> > --
> > 2.34.1
> >
>

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Conor Dooley]

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

On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
> <mohamed@unpredictable.fr> wrote:
> >
> >
> >
> > > On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> > >
> > > This series adds big-endian (BE) RISC-V target support to QEMU,
> > > covering both softmmu and linux-user emulation for riscv32be and
> > > riscv64be.
> > Hello,
> >
> > There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
> > support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
> 
> Agreed. We really need upstream Linux support before user mode

On that front, Ben posted patches for it and Linus was really really not
enthused when he became aware of it:
https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
Even without Linus' take, I feel like there's absolutely no chance of
upstream support without meaningful shipping hardware that requires
big endian support, because basically everyone else was also opposed to
adding it...

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

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Alistair Francis]

On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
> > On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
> > <mohamed@unpredictable.fr> wrote:
> > >
> > >
> > >
> > > > On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> > > >
> > > > This series adds big-endian (BE) RISC-V target support to QEMU,
> > > > covering both softmmu and linux-user emulation for riscv32be and
> > > > riscv64be.
> > > Hello,
> > >
> > > There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
> > > support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
> >
> > Agreed. We really need upstream Linux support before user mode
>
> On that front, Ben posted patches for it and Linus was really really not
> enthused when he became aware of it:
> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
> Even without Linus' take, I feel like there's absolutely no chance of
> upstream support without meaningful shipping hardware that requires
> big endian support, because basically everyone else was also opposed to
> adding it...

Yeah... I saw that.

A few thoughts, just because Linus doesn't like it doesn't mean QEMU
can't support it. But I am hesitant to support BE considering the lack
of ecosystem support everywhere else.

There are a bunch of changes in this series that could easily go into
QEMU. They aren't intrusive and just involve changing or using helper
functions to handle endianness. I think those could be split out and
go upstream, reducing the size of this series and reducing the
maintenance burden of out of tree patches.

The core BE support is a different problem. But if softmmu works in
the existing binaries then maybe it's worth accepting. linux user mode
is a whole other problem that we probably won't be able to accept.

Alistair

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Thomas Huth]

On 27/02/2026 01.56, Alistair Francis wrote:
> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
>>
>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>> <mohamed@unpredictable.fr> wrote:
>>>>
>>>>
>>>>
>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
>>>>>
>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>> riscv64be.
>>>> Hello,
>>>>
>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
>>>
>>> Agreed. We really need upstream Linux support before user mode
>>
>> On that front, Ben posted patches for it and Linus was really really not
>> enthused when he became aware of it:
>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
>> Even without Linus' take, I feel like there's absolutely no chance of
>> upstream support without meaningful shipping hardware that requires
>> big endian support, because basically everyone else was also opposed to
>> adding it...
> 
> Yeah... I saw that.
> 
> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
> can't support it. But I am hesitant to support BE considering the lack
> of ecosystem support everywhere else.
> 
> There are a bunch of changes in this series that could easily go into
> QEMU. They aren't intrusive and just involve changing or using helper
> functions to handle endianness. I think those could be split out and
> go upstream, reducing the size of this series and reducing the
> maintenance burden of out of tree patches.
> 
> The core BE support is a different problem. But if softmmu works in
> the existing binaries then maybe it's worth accepting.

FWIW, have a look at the changes that Philippe did in target/microblaze/ in 
the past two years, he merged the both endianness flavours there so it can 
now be handled in one binary! If you do something similar with riscv, it 
hopefully should not be too intrusive.

  Thomas

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Djordje Todorovic]

On 2/27/26 10:27, Thomas Huth wrote:
> CAUTION: This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender 
> and know the content is safe.
>
>
> On 27/02/2026 01.56, Alistair Francis wrote:
>> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
>>>
>>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>>> <mohamed@unpredictable.fr> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic 
>>>>>> <Djordje.Todorovic@htecgroup.com> wrote:
>>>>>>
>>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>>> riscv64be.
>>>>> Hello,
>>>>>
>>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is 
>>>>> to not
>>>>> support it unless we’re sure that it can get to Linux upstream 
>>>>> (for the linux-user mode)?
>>>>
>>>> Agreed. We really need upstream Linux support before user mode
>>>
>>> On that front, Ben posted patches for it and Linus was really really 
>>> not
>>> enthused when he became aware of it:
>>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk 
>>>
>>> Even without Linus' take, I feel like there's absolutely no chance of
>>> upstream support without meaningful shipping hardware that requires
>>> big endian support, because basically everyone else was also opposed to
>>> adding it...
>>
>> Yeah... I saw that.
>>
>> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
>> can't support it. But I am hesitant to support BE considering the lack
>> of ecosystem support everywhere else.
>>
>> There are a bunch of changes in this series that could easily go into
>> QEMU. They aren't intrusive and just involve changing or using helper
>> functions to handle endianness. I think those could be split out and
>> go upstream, reducing the size of this series and reducing the
>> maintenance burden of out of tree patches.
>>
>> The core BE support is a different problem. But if softmmu works in
>> the existing binaries then maybe it's worth accepting.
>
> FWIW, have a look at the changes that Philippe did in 
> target/microblaze/ in
> the past two years, he merged the both endianness flavours there so it 
> can
> now be handled in one binary! If you do something similar with riscv, it
> hopefully should not be too intrusive.
>
>  Thomas
>
Hi Thomas,

Yes, sure, thanks for the advice, I will try to follow that part for 
riscv as well!

Thanks a lot!
Djordje

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Djordje Todorovic]

On 2/27/26 01:56, Alistair Francis wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>> <mohamed@unpredictable.fr> wrote:
>>>>
>>>>
>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
>>>>>
>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>> riscv64be.
>>>> Hello,
>>>>
>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
>>> Agreed. We really need upstream Linux support before user mode
>> On that front, Ben posted patches for it and Linus was really really not
>> enthused when he became aware of it:
>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
>> Even without Linus' take, I feel like there's absolutely no chance of
>> upstream support without meaningful shipping hardware that requires
>> big endian support, because basically everyone else was also opposed to
>> adding it...
> Yeah... I saw that.
>
> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
> can't support it. But I am hesitant to support BE considering the lack
> of ecosystem support everywhere else.


Please be aware that MIPS will ship hardware based on riscv BE

soon: https://mips.com/products/hardware/i8500/


Thanks,
Djordje


> There are a bunch of changes in this series that could easily go into
> QEMU. They aren't intrusive and just involve changing or using helper
> functions to handle endianness. I think those could be split out and
> go upstream, reducing the size of this series and reducing the
> maintenance burden of out of tree patches.
>
> The core BE support is a different problem. But if softmmu works in
> the existing binaries then maybe it's worth accepting. linux user mode
> is a whole other problem that we probably won't be able to accept.
>
> Alistair

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Conor Dooley]

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

On Fri, Feb 27, 2026 at 12:42:21PM +0000, Djordje Todorovic wrote:
> 
> On 2/27/26 01:56, Alistair Francis wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> >
> >
> > On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley <conor@kernel.org> wrote:
> >> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
> >>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
> >>> <mohamed@unpredictable.fr> wrote:
> >>>>
> >>>>
> >>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
> >>>>>
> >>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
> >>>>> covering both softmmu and linux-user emulation for riscv32be and
> >>>>> riscv64be.
> >>>> Hello,
> >>>>
> >>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
> >>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
> >>> Agreed. We really need upstream Linux support before user mode
> >> On that front, Ben posted patches for it and Linus was really really not
> >> enthused when he became aware of it:
> >> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
> >> Even without Linus' take, I feel like there's absolutely no chance of
> >> upstream support without meaningful shipping hardware that requires
> >> big endian support, because basically everyone else was also opposed to
> >> adding it...
> > Yeah... I saw that.
> >
> > A few thoughts, just because Linus doesn't like it doesn't mean QEMU
> > can't support it. But I am hesitant to support BE considering the lack
> > of ecosystem support everywhere else.
> 
> 
> Please be aware that MIPS will ship hardware based on riscv BE
> 
> soon: https://mips.com/products/hardware/i8500/

Not the meaning of "hardware" I was using, as this appears to be a core
complex IP rather than physical hardware? Do you know of any devices,
outside of a MIPS test chip or w/e, that are going to use this IP?

On the linux support front, the devils advocate take would be that
people should just run this core in LE mode, but that's a bridge to be
crossed when someone produces an SoC using that core complex and on
another mailing list!

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

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Djordje Todorovic]

On 2/27/26 13:56, Conor Dooley wrote:
> On Fri, Feb 27, 2026 at 12:42:21PM +0000, Djordje Todorovic wrote:
>> On 2/27/26 01:56, Alistair Francis wrote:
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>>
>>>
>>> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley<conor@kernel.org> wrote:
>>>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>>>> <mohamed@unpredictable.fr> wrote:
>>>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic<Djordje.Todorovic@htecgroup.com> wrote:
>>>>>>>
>>>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>>>> riscv64be.
>>>>>> Hello,
>>>>>>
>>>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>>>>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
>>>>> Agreed. We really need upstream Linux support before user mode
>>>> On that front, Ben posted patches for it and Linus was really really not
>>>> enthused when he became aware of it:
>>>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
>>>> Even without Linus' take, I feel like there's absolutely no chance of
>>>> upstream support without meaningful shipping hardware that requires
>>>> big endian support, because basically everyone else was also opposed to
>>>> adding it...
>>> Yeah... I saw that.
>>>
>>> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
>>> can't support it. But I am hesitant to support BE considering the lack
>>> of ecosystem support everywhere else.
>> Please be aware that MIPS will ship hardware based on riscv BE
>>
>> soon:https://mips.com/products/hardware/i8500/
> Not the meaning of "hardware" I was using, as this appears to be a core
> complex IP rather than physical hardware? Do you know of any devices,
> outside of a MIPS test chip or w/e, that are going to use this IP?
>
> On the linux support front, the devils advocate take would be that
> people should just run this core in LE mode, but that's a bridge to be
> crossed when someone produces an SoC using that core complex and on
> another mailing list!

Yes, you are right, the i8500 is an IP. And I can share for now that 
QEMU and FPGA

board with the i8500 bitfile are the targets for testing of RISC-V BE 
software.


Best regards,
Djordje

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Philippe Mathieu-Daudé]

Hi Djordje,

On 27/2/26 15:24, Djordje Todorovic wrote:
> On 2/27/26 13:56, Conor Dooley wrote:
>> On Fri, Feb 27, 2026 at 12:42:21PM +0000, Djordje Todorovic wrote:
>>> On 2/27/26 01:56, Alistair Francis wrote:
>>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>>>
>>>>
>>>> On Fri, Feb 27, 2026 at 9:47 AM Conor Dooley<conor@kernel.org> wrote:
>>>>> On Fri, Feb 27, 2026 at 09:30:00AM +1000, Alistair Francis wrote:
>>>>>> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
>>>>>> <mohamed@unpredictable.fr> wrote:
>>>>>>>> On 25. Feb 2026, at 11:20, Djordje Todorovic<Djordje.Todorovic@htecgroup.com> wrote:
>>>>>>>>
>>>>>>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>>>>>>> covering both softmmu and linux-user emulation for riscv32be and
>>>>>>>> riscv64be.
>>>>>>> Hello,
>>>>>>>
>>>>>>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>>>>>>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
>>>>>> Agreed. We really need upstream Linux support before user mode
>>>>> On that front, Ben posted patches for it and Linus was really really not
>>>>> enthused when he became aware of it:
>>>>> https://lore.kernel.org/linux-riscv/066d70c7-b0a7-45e5-9337-17901bc95664@codethink.co.uk
>>>>> Even without Linus' take, I feel like there's absolutely no chance of
>>>>> upstream support without meaningful shipping hardware that requires
>>>>> big endian support, because basically everyone else was also opposed to
>>>>> adding it...
>>>> Yeah... I saw that.
>>>>
>>>> A few thoughts, just because Linus doesn't like it doesn't mean QEMU
>>>> can't support it. But I am hesitant to support BE considering the lack
>>>> of ecosystem support everywhere else.
>>> Please be aware that MIPS will ship hardware based on riscv BE
>>>
>>> soon:https://mips.com/products/hardware/i8500/
>> Not the meaning of "hardware" I was using, as this appears to be a core
>> complex IP rather than physical hardware? Do you know of any devices,
>> outside of a MIPS test chip or w/e, that are going to use this IP?
>>
>> On the linux support front, the devils advocate take would be that
>> people should just run this core in LE mode, but that's a bridge to be
>> crossed when someone produces an SoC using that core complex and on
>> another mailing list!
> 
> Yes, you are right, the i8500 is an IP. And I can share for now that
> QEMU and FPGA
> 
> board with the i8500 bitfile are the targets for testing of RISC-V BE
> software.

Just to clarify, as explained by Thomas elsewhere in this thread, we
are not opposed to have QEMU runs big-endian RISCV cores, and indeed
what guest runs shouldn't be a blocker (Linux support is convenient
for testing, but as long as you provide any other guest firmware code
we can run, we are happy). What we do not want is to add a new binary.
Endianness is a runtime variant. If implemented correctly, the current
binaries should be able to have the HARTs running any endianness. See
the recent changes in qemu-system-microblaze for example. Other targets
are going to get their endianness unified (but it will take time).

Regards,

Phil.

Re: [PATCH v2 00/16] Add RISC-V big-endian target support

[Djordje Todorovic]

On 2/27/26 00:30, Alistair Francis wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On Wed, Feb 25, 2026 at 9:39 PM Mohamed Mediouni
> <mohamed@unpredictable.fr> wrote:
>>
>>
>>> On 25. Feb 2026, at 11:20, Djordje Todorovic <Djordje.Todorovic@htecgroup.com> wrote:
>>>
>>> This series adds big-endian (BE) RISC-V target support to QEMU,
>>> covering both softmmu and linux-user emulation for riscv32be and
>>> riscv64be.
>> Hello,
>>
>> There’s no Linux RISC-V big endian. Maybe the right thing to do is to not
>> support it unless we’re sure that it can get to Linux upstream (for the linux-user mode)?
> Agreed. We really need upstream Linux support before user mode
>
>> Thank you,
>> -Mohamed
>>> The RISC-V ISA supports big-endian operation via the mstatus SBE/MBE/UBE
>>> bits. While instructions are always little-endian, data accesses follow
>>> the configured endianness. This series implements the necessary QEMU
>>> infrastructure.
> How are you testing this?

Hi Alistair,

Thanks for your comments!


Even though the SW ecosystem is not complete/mature, there is

pretty decent support in GNU toolchain for riscv big-endian already.

GNU GCC, binutils, etc. are pretty okay. I am now working on the

upstreaming process of riscv big-endian in LLVM project, and compiler

part is already merged -- almost done with LLD (LLVM based linker)

and LLDB (LLVM based debugger) as well.


Furthermore, I have also implemented:

1) basic linux support

   https://github.com/djtodoro/linux/commits/riscv-be-proposal/

2) as well as some basic CI support for basic cases:

   https://github.com/djtodoro/riscv-be-test-suite

so qemu is tested against these two as well.


At the end, we do see that even on GNU GCC mailing list,

people are seeking for at least basic support in qemu for

riscv big-endian target, since the testing will become much

easier, since GNU Sym does support it, but it is not robust

enough (as qemu).


Thanks,
Djordje

> Alistair
>
>>> Furthermore, MIPS announced cores with BE configuration:
>>>   https://mips.com/products/hardware/i8500/
>>>
>>> Patches 01-03: Build system and config for new BE targets
>>> Patches 04-07: Core emulation fixes (instruction fetch, boot ROM, ELF
>>>                loading, fw_dynamic endianness)
>>> Patches 08-11: Linux-user BE targets and vDSO handling
>>> Patch  12:     Set SBE/MBE mstatus bits at CPU reset
>>> Patch  13:     Fix PTE A/D atomic update endianness in page table walker
>>> Patch  14:     Clean up instruction fetch to use MO_LE directly
>>> Patch  15:     Fix virtio-mmio legacy device register endianness
>>> Patch  16:     Add riscv32be and riscv64be to SysEmuTarget
>>>
>>> Djordje Todorovic (9):
>>>   meson: Add BE RISCV targets
>>>   config/targets: Add BE RISCV softmmu targets
>>>   config/devices: Add BE riscv configs
>>>   target/riscv: Ensure LE instruction fetching
>>>   hw/riscv: Ensure bootrom has correct endianess
>>>   hw/riscv: Ensure proper ELF endian expectation
>>>   hw/riscv: Check endianness for fw_dynamic fields
>>>   config/targets: Add RISC-V userspace targets
>>>   arch/riscv: Set UBE bit on BE target
>>>
>>> djtodoro (7):
>>>   config/targets: Add missing fields to BE linux-user targets
>>>   linux-user/riscv: Disable vDSO for big-endian targets
>>>   target/riscv: Set SBE and MBE bits at CPU reset for BE targets
>>>   target/riscv: Fix PTE A/D atomic update endianness
>>>   target/riscv: Use MO_LE for instruction fetch
>>>   hw/virtio: Use DEVICE_LITTLE_ENDIAN for virtio-mmio legacy ops
>>>   qapi: Add riscv32be and riscv64be to SysEmuTarget
>>>
>>> configs/devices/riscv32be-softmmu/default.mak | 15 +++++++
>>> configs/devices/riscv64be-softmmu/default.mak | 16 ++++++++
>>> configs/targets/riscv32be-linux-user.mak      | 11 +++++
>>> configs/targets/riscv32be-softmmu.mak         |  8 ++++
>>> configs/targets/riscv64be-linux-user.mak      | 11 +++++
>>> configs/targets/riscv64be-softmmu.mak         |  8 ++++
>>> hw/riscv/boot.c                               | 41 ++++++++++++++++---
>>> hw/virtio/virtio-mmio.c                       |  2 +-
>>> include/hw/riscv/boot.h                       |  5 +++
>>> linux-user/riscv/target_elf.h                 | 10 ++++-
>>> meson.build                                   |  7 +++-
>>> qapi/machine.json                             |  3 +-
>>> target/riscv/cpu.c                            |  3 ++
>>> target/riscv/cpu_bits.h                       |  2 +
>>> target/riscv/cpu_helper.c                     |  9 ++--
>>> target/riscv/translate.c                      | 16 ++++----
>>> 16 files changed, 145 insertions(+), 22 deletions(-)
>>> create mode 100644 configs/devices/riscv32be-softmmu/default.mak
>>> create mode 100644 configs/devices/riscv64be-softmmu/default.mak
>>> create mode 100644 configs/targets/riscv32be-linux-user.mak
>>> create mode 100644 configs/targets/riscv32be-softmmu.mak
>>> create mode 100644 configs/targets/riscv64be-linux-user.mak
>>> create mode 100644 configs/targets/riscv64be-softmmu.mak
>>>
>>> --
>>> 2.34.1
>>>