On Thu, May 28, 2026 at 6:16 AM Philippe Mathieu-Daudé
<[email protected]> wrote:
>
> From: Djordje Todorovic <[email protected]>
>
> Now that the full big-endian data path is in place (runtime MSTATUS
> bits, boot code, and page-table walks), expose the "big-endian"
> property to users via DEFINE_PROP_BOOL and document it in
> docs/system/target-riscv.rst.
>
> Document that the property models fixed-endian hardware: it selects
> harts whose MBE/SBE/UBE fields are fixed to 1, and it does not model
> a mixed-endian implementation where software can toggle those bits at
> runtime.
>
> The property can be enabled from the command line, e.g.:
>
>     -cpu <cpu>,big-endian=on
>
> Signed-off-by: Djordje Todorovic <[email protected]>
> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>

Reviewed-by: Alistair Francis <[email protected]>

Alistair

> ---
>  docs/system/target-riscv.rst | 29 +++++++++++++++++++++++++++++
>  target/riscv/cpu.c           |  1 +
>  2 files changed, 30 insertions(+)
>
> diff --git a/docs/system/target-riscv.rst b/docs/system/target-riscv.rst
> index 3ad5d1ddafb..afd86ca2ba1 100644
> --- a/docs/system/target-riscv.rst
> +++ b/docs/system/target-riscv.rst
> @@ -95,3 +95,32 @@ the images they need.
>  * ``-bios <file>``
>
>  Tells QEMU to load the specified file as the firmware.
> +
> +RISC-V CPU endianness
> +---------------------
> +
> +The RISC-V ISA specifies that instruction fetches are always little-endian,
> +while data accesses can be either little-endian or big-endian under control
> +of the MSTATUS ``MBE``/``SBE``/``UBE`` bits (see section 3.1.6.5, "Memory
> +Endianness", in the RISC-V Privileged Specification).
> +
> +QEMU implements the full data-endianness behaviour described by those bits.
> +In addition, the RISC-V CPU object exposes a ``big-endian`` boolean property
> +which models a big-endian-only hardware implementation, where the
> +``MBE``/``SBE``/``UBE`` bits are hardwired to 1. When the property is set,
> +the CPU is reset with all three bits initialised to 1, so the guest starts
> +executing in big-endian data mode from the reset vector. The property is a
> +static, per-CPU hardware configuration option and is not meant to be toggled
> +at runtime.
> +
> +The property does not model a mixed-endian implementation where software can
> +toggle ``MBE``/``SBE``/``UBE`` at runtime. QEMU's RISC-V CPUs treat these
> +fields as fixed by the CPU configuration: they are reset to 0 by default and
> +to 1 when ``big-endian`` is enabled.
> +
> +The property can be enabled from the command line, for example::
> +
> +    -cpu <cpu>,big-endian=on
> +
> +No upstream CPU model currently defaults to big-endian; the property is
> +provided so that big-endian-only RISC-V CPU variants can be modelled.
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index fef424f2bf9..c8a41c57a57 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -2520,6 +2520,7 @@ RISCVCPUImpliedExtsRule 
> *riscv_multi_ext_implied_rules[] = {
>
>  static const Property riscv_cpu_properties[] = {
>      DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),
> +    DEFINE_PROP_BOOL("big-endian", RISCVCPU, cfg.big_endian, false),
>
>      {.name = "pmu-mask", .info = &prop_pmu_mask},
>      {.name = "pmu-num", .info = &prop_pmu_num}, /* Deprecated */
> --
> 2.53.0
>
>

Reply via email to