[{"id":3678637,"web_url":"http://patchwork.ozlabs.org/comment/3678637/","msgid":"<8fda6a95-3a39-489f-9be0-8895c5016835@linaro.org>","list_archive_url":null,"date":"2026-04-17T10:14:12","subject":"Re: [PATCH v7 2/6] target/riscv: Add big-endian CPU property","submitter":{"id":85046,"url":"http://patchwork.ozlabs.org/api/people/85046/","name":"Philippe Mathieu-Daudé","email":"philmd@linaro.org"},"content":"On 17/4/26 12:03, Djordje Todorovic wrote:\n> Add a \"big-endian\" boolean property to the RISC-V CPU configuration,\n> defaulting to false (little-endian). When enabled, this models a\n> big-endian-only RISC-V implementation as described in section 3.1.6.5\n> of the RISC-V Privileged Specification (\"Memory Endianness\"), where\n> the MSTATUS MBE/SBE/UBE bits are hardwired to 1.\n> \n> This is a static, per-CPU hardware configuration option, not a runtime\n> switch. It is intended for modeling RISC-V CPU variants whose data\n> endianness is fixed to big-endian at the hardware level. Instructions\n> remain little-endian regardless, per the RISC-V ISA specification.\n> \n> When cfg.big_endian is set, riscv_cpu_reset_hold() writes 1 into the\n> MSTATUS UBE/SBE/MBE fields; otherwise it writes 0. The assignment is\n> done with set_field() so the reset value is deterministic on both\n> cold and warm reset, rather than depending on the pre-reset state.\n> The MBE/SBE/UBE bits are not included in the writable mask of any\n> mstatus/mstatush/sstatus CSR write path, so the value chosen at reset\n> effectively hardwires them. The actual effect of those bits on data\n> accesses, page-table walks and boot code is implemented by the\n> subsequent patches in this series.\n> \n> Also update the disassembler comment to clarify that BFD_ENDIAN_LITTLE\n> is correct because RISC-V instructions are always little-endian per\n> the ISA specification.\n> \n> No upstream CPU currently defaults to big-endian; the property can be\n> enabled from the command line, e.g.:\n> \n> -cpu ,big-endian=on\n> \n> Signed-off-by: Djordje Todorovic \n> Reviewed-by: Chao Liu \n> ---\n> docs/system/target-riscv.rst | 24 ++++++++++++++++++++++++\n> target/riscv/cpu.c | 11 ++++++-----\n> target/riscv/cpu_cfg_fields.h.inc | 1 +\n> 3 files changed, 31 insertions(+), 5 deletions(-)\n> \n> diff --git a/docs/system/target-riscv.rst b/docs/system/target-riscv.rst\n> index 3ad5d1ddaf..7798184ebe 100644\n> --- a/docs/system/target-riscv.rst\n> +++ b/docs/system/target-riscv.rst\n> @@ -95,3 +95,27 @@ the images they need.\n> * ``-bios ``\n> \n> Tells QEMU to load the specified file as the firmware.\n> +\n> +RISC-V CPU endianness\n> +---------------------\n> +\n> +The RISC-V ISA specifies that instruction fetches are always little-endian,\n> +while data accesses can be either little-endian or big-endian under control\n> +of the MSTATUS ``MBE``/``SBE``/``UBE`` bits (see section 3.1.6.5, \"Memory\n> +Endianness\", in the RISC-V Privileged Specification).\n> +\n> +QEMU implements the full data-endianness behaviour described by those bits.\n> +In addition, the RISC-V CPU object exposes a ``big-endian`` boolean property\n> +which models a big-endian-only hardware implementation, where the\n> +``MBE``/``SBE``/``UBE`` bits are hardwired to 1. When the property is set,\n> +the CPU is reset with all three bits initialised to 1, so the guest starts\n> +executing in big-endian data mode from the reset vector. The property is a\n> +static, per-CPU hardware configuration option and is not meant to be toggled\n> +at runtime.\n> +\n> +The property can be enabled from the command line, for example::\n> +\n> + -cpu ,big-endian=on\n> +\n> +No upstream CPU model currently defaults to big-endian; the property is\n> +provided so that big-endian-only RISC-V CPU variants can be modelled.\n\nThis doc ...\n\n> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c\n> index e56470a374..c39500cb3f 100644\n> --- a/target/riscv/cpu.c\n> +++ b/target/riscv/cpu.c\n> @@ -716,6 +716,9 @@ static void riscv_cpu_reset_hold(Object *obj, ResetType type)\n> env->mstatus = set_field(env->mstatus, MSTATUS_MDT, 1);\n> }\n> }\n> + env->mstatus = set_field(env->mstatus, MSTATUS_MBE, cpu->cfg.big_endian);\n> + env->mstatus = set_field(env->mstatus, MSTATUS_SBE, cpu->cfg.big_endian);\n> + env->mstatus = set_field(env->mstatus, MSTATUS_UBE, cpu->cfg.big_endian);\n> env->mcause = 0;\n> env->miclaim = MIP_SGEIP;\n> env->pc = env->resetvec;\n> @@ -803,11 +806,8 @@ static void riscv_cpu_disas_set_info(const CPUState *s, disassemble_info *info)\n> info->target_info = &cpu->cfg;\n> \n> /*\n> - * A couple of bits in MSTATUS set the endianness:\n> - * - MSTATUS_UBE (User-mode),\n> - * - MSTATUS_SBE (Supervisor-mode),\n> - * - MSTATUS_MBE (Machine-mode)\n> - * but we don't implement that yet.\n> + * RISC-V instructions are always little-endian, regardless of the\n> + * data endianness configured via MSTATUS UBE/SBE/MBE bits.\n> */\n> info->endian = BFD_ENDIAN_LITTLE;\n> \n> @@ -2641,6 +2641,7 @@ RISCVCPUImpliedExtsRule *riscv_multi_ext_implied_rules[] = {\n> \n> static const Property riscv_cpu_properties[] = {\n> DEFINE_PROP_BOOL(\"debug\", RISCVCPU, cfg.debug, true),\n> + DEFINE_PROP_BOOL(\"big-endian\", RISCVCPU, cfg.big_endian, false),\n\n... and exposing the CPU property should be in a distinct patch, placed\nlast (just before the test). Otherwise the series isn't bisect-able.\n\nOK for the other changes (introducing cfg::big_endian) in this patch.\n\n> \n> {.name = \"pmu-mask\", .info = &prop_pmu_mask},\n> {.name = \"pmu-num\", .info = &prop_pmu_num}, /* Deprecated */\n> diff --git a/target/riscv/cpu_cfg_fields.h.inc b/target/riscv/cpu_cfg_fields.h.inc\n> index 70ec650abf..51436daabf 100644\n> --- a/target/riscv/cpu_cfg_fields.h.inc\n> +++ b/target/riscv/cpu_cfg_fields.h.inc\n> @@ -154,6 +154,7 @@ BOOL_FIELD(ext_xmipscbop)\n> BOOL_FIELD(ext_xmipscmov)\n> BOOL_FIELD(ext_xmipslsp)\n> \n> +BOOL_FIELD(big_endian)\n> BOOL_FIELD(mmu)\n> BOOL_FIELD(pmp)\n> BOOL_FIELD(debug)","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256\n header.s=google header.b=x91wMKk/;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)"],"Received":["from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fxrNF2SdZz1yDF\n\tfor ; Fri, 17 Apr 2026 20:14:53 +1000 (AEST)","from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from )\n\tid 1wDgDN-0006Q8-Ju; Fri, 17 Apr 2026 06:14:21 -0400","from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from ) id 1wDgDL-0006Ps-OQ\n for qemu-devel@nongnu.org; Fri, 17 Apr 2026 06:14:19 -0400","from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)\n (Exim 4.90_1) (envelope-from ) id 1wDgDJ-000122-TZ\n for qemu-devel@nongnu.org; Fri, 17 Apr 2026 06:14:19 -0400","by mail-wr1-x42b.google.com with SMTP id\n ffacd0b85a97d-43d43e09de5so278514f8f.1\n for ; Fri, 17 Apr 2026 03:14:17 -0700 (PDT)","from [192.168.69.228] (88-187-86-199.subs.proxad.net.\n [88.187.86.199]) by smtp.gmail.com with ESMTPSA id\n ffacd0b85a97d-43fe4cb13a0sm3492270f8f.8.2026.04.17.03.14.13\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Fri, 17 Apr 2026 03:14:14 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=linaro.org; s=google; t=1776420856; x=1777025656; darn=nongnu.org;\n h=content-transfer-encoding:in-reply-to:from:references:cc:to\n :content-language:subject:user-agent:mime-version:date:message-id\n :from:to:cc:subject:date:message-id:reply-to;\n bh=k33/9nrABq1Qa6/alBsId1LxOaZ5spKdpRIQfsn+1dw=;\n b=x91wMKk/d2dtk6UZmWIpADthD6t5Aas048lfgHBmRL+4DdBAXk36gAWNAxj+4j+GWL\n nSUrq5q318XNwrFnoHNMQNqqyXA7/aALd4yR4M+QkRKndxAMO3JWK3j8wNNCU6nuc6/P\n jbIyepFnTCMATh6Q2eaew/I1PZydIr4fPbdZp6kcCSA5GDb3ge7TZqZlUFql94e2KGpE\n etO4gFBgo9PL33adsX3ueXI5VBQ/74gx+pRVVlK5q0Qqg5PcvQJaxO1ns2KFXKLChZee\n qhfSx2GRzKshkNgB6syhVlf67I29iZ+XTDzPupBJxiAQdkXB6xQUAcd7OkjExdp6MIWu\n nf7g==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776420856; x=1777025656;\n h=content-transfer-encoding:in-reply-to:from:references:cc:to\n :content-language:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=k33/9nrABq1Qa6/alBsId1LxOaZ5spKdpRIQfsn+1dw=;\n b=XW2SD0vve4+Ehmwr8oUS2IvwxiwmJfwIwrpoZb7GII16KACZS2JX1GPXHJ3sSui3jY\n 89mkCZd5glcWEI9FCEgFgnzb/Jws+W7GXbhoq9DYrEuzhx31hZiZyQWAvUjoOhdM37el\n m2fUSqZWGz4c2W09GcynrkOlfHDVkBlaH64m5eEo5/dJveSKIC4kp5G9veUxT3sSZKoO\n ksSKELm9iWHpHxeLvmwWNGEbPNVPdqciKGob0Twuk0+K+ph+AuYYalVQyjMjVrDgUnfW\n d82Fs7IZW9bkNC3o0bnkDciNs6illvD33zLFTAuqib+LPT1II1xukXiBQE3rcxOjOHbD\n Dnqg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+1rVQOGKAMMEIkfYmxIEBOxI/f9IlqvQrF9BgSV6Pfo0pdOoUWcatAx7oQqR5NXR74VxZIEXalssXN@nongnu.org","X-Gm-Message-State":"AOJu0YwPi5PcWmnNvEXceW+jazs5jhAPfjJIlN6hJD7am8glgCE65Pp8\n LdwYVhxiS7kWEO3hPJljozRd4tqyS2CAH300DwMGzG6EdCUax4mS/avFltjgSnmLt18=","X-Gm-Gg":"AeBDies1pnXE8hc9L5rDJ7+WJALsJ+Wb57dlSE9MMddtDMCRpfWB0jLeWkQhPZkYzdB\n z1VactsQ8rPdglZbcUCmdoewgSpM7MfKTnrZXDIBsuyPRtQk0wvo3MRNWR/lWTJdBz39Cy9zscY\n XJsSalRVqK5sb+akOX0WP7qsW8pm7hxdYoIRyKEqk94VJ5G8Cr4N24KqPfU/HlAUighfUjobXZW\n pvcirAm7hcer10bFH+QMxYVfpfN0Dkrtqkt+Au55/n/vi+2stJSMyKgBhcmwCKmLuS4HPp4xYkX\n HunBAY00FzAdjFGw6H5voKujCFAEbkQCvOCVHrm/cHCEKdn9+fgTYV5zCazqKurycpgKA5O09Ky\n 1oMez7dWRaMNxDVU3j89WJFTYxCynis9exOzGG+crP+J0QpP+P+ipzCLLJYwjOuT8SQhYptZQAL\n h76wek/6PqceNDtcjZYL+Vg7aVwIgIiYQQnvYXonQlB5jzQvpcW2V+uKOIKxyE5vA7Fg7dTsoJl\n zcAgmjHCOzxNzg=","X-Received":"by 2002:a05:6000:1a8e:b0:43d:30af:a173 with SMTP id\n ffacd0b85a97d-43fe3dbd824mr3324471f8f.5.1776420855711;\n Fri, 17 Apr 2026 03:14:15 -0700 (PDT)","Message-ID":"<8fda6a95-3a39-489f-9be0-8895c5016835@linaro.org>","Date":"Fri, 17 Apr 2026 12:14:12 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v7 2/6] target/riscv: Add big-endian CPU property","Content-Language":"en-US","To":"Djordje Todorovic ,\n \"qemu-devel@nongnu.org\" ","Cc":"\"qemu-riscv@nongnu.org\" ,\n \"cfu@mips.com\" , \"mst@redhat.com\" ,\n \"marcel.apfelbaum@gmail.com\" ,\n \"dbarboza@ventanamicro.com\" ,\n \"alistair23@gmail.com\" ,\n \"thuth@redhat.com\" , Chao Liu ","References":"<20260417100302.162260-1-djordje.todorovic@htecgroup.com>\n <20260417100302.162260-3-djordje.todorovic@htecgroup.com>","From":"=?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= ","In-Reply-To":"<20260417100302.162260-3-djordje.todorovic@htecgroup.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","Received-SPF":"pass client-ip=2a00:1450:4864:20::42b;\n envelope-from=philmd@linaro.org; helo=mail-wr1-x42b.google.com","X-Spam_score_int":"-20","X-Spam_score":"-2.1","X-Spam_bar":"--","X-Spam_report":"(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,\n DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,\n SPF_PASS=-0.001 autolearn=ham autolearn_force=no","X-Spam_action":"no action","X-BeenThere":"qemu-devel@nongnu.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"qemu development ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org","Sender":"qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org"}}]