Hi Alistair,
I think we should push this upstream and see what happens. We'll have a full release cycle to undo the change in case we find unintended side effects. I'm fairly optimistic that this change will be a no-op for most users and will benefit us when we'll have to deal with RVA23 specific software. Thanks, Daniel On 4/4/25 12:27 PM, Daniel Henrique Barboza wrote:
Hi, The 'rv64' CPU, the default CPU for the 'virt' machine, is a strange CPU. It is a collection of extensions that were enabled/disabled as extensions were being added in TCG, and in the end we ended up with a CPU that we can't say exactly what it does. This is further aggravated by the distros move to support the RVA23 profile. Patch 2 has more details, but long story short: distros uses the 'virt' machine, and they'll start building on top of RVA23, and rv64 does not have RVA23 support. In short, distros will start to break in the default 'virt' CPU. Changing the default CPU to 'max' will not cause (intentional) user regressions: if the software runs in rv64 it will run in 'max' too given that we're adding more extensions as default instead of removing them. In my opinion this might be enough to avoid a deprecation cycle and we can do the change for 10.1. And yeah, patch 2 mentions the already old trope "and ARM does the same". This is intentional: I want RISC-V code and usability to be as close as possible to ARM and other archs to promote a more homogeneous experience when developing and using QEMU. Daniel Henrique Barboza (2): target/riscv/tcg: make 'max' cpu rva23s64 compliant hw/riscv/virt.c: change default CPU to 'max' hw/riscv/virt.c | 2 +- target/riscv/tcg/tcg-cpu.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-)
