qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/3] target/riscv: Do not allow MXL_RV32 for TARGET_RISCV6


From: Akihiko Odaki
Subject: Re: [PATCH v2 1/3] target/riscv: Do not allow MXL_RV32 for TARGET_RISCV64
Date: Mon, 16 Oct 2023 13:19:53 +0900
User-agent: Mozilla Thunderbird

On 2023/10/16 13:07, Alistair Francis wrote:
On Mon, Oct 16, 2023 at 1:22 PM Akihiko Odaki <akihiko.odaki@daynix.com> wrote:



On 2023/10/16 10:51, Alistair Francis wrote:
On Sun, Oct 15, 2023 at 4:05 AM Daniel Henrique Barboza
<dbarboza@ventanamicro.com> wrote:



On 10/14/23 00:35, Akihiko Odaki wrote:
TARGET_RISCV64 does not have riscv-32bit-cpu.xml so it shouldn't accept
MXL_RV32.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---

Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>


    target/riscv/tcg/tcg-cpu.c | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index a28918ab30..e0cbc56320 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -161,10 +161,11 @@ static void riscv_cpu_validate_misa_mxl(RISCVCPU *cpu, 
Error **errp)
        case MXL_RV128:
            cc->gdb_core_xml_file = "riscv-64bit-cpu.xml";
            break;
-#endif
+#elif defined(TARGET_RISCV32)
        case MXL_RV32:
            cc->gdb_core_xml_file = "riscv-32bit-cpu.xml";
            break;
+#endif

This isn't the right fix. The idea is that riscv64-softmmu can run
32-bit CPUs, so we instead should include riscv-32bit-cpu.xml

In that case I can continue working on the previous version of this
series, but is it really true? I see no 32-bit CPUs enabled for
riscv64-softmmu. Is there a plan to enable them for riscv64-softmmu?

Yeah....

So last time I tried the 32-bit CPUs didn't work correctly. I didn't
figure out what the issue was, but the *idea* is to eventually enable
32-bit CPUs in the 64-bit builds.

Ok, then I'll push the previous version forward.

Daniel, you are concerned that moving misa_mxl_max to class to match with gdb_core_xml_file will result in an extra casts when fetching it and data when initializing the class.

I think the extra cast is fine since no fetch of misa_mxl_max happens in a hot path. Requiring data when initializing the class should also be fine since the proposed patch uses the class_data member of TypeInfo, which is currently free. Does it make sense?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]