[PATCH 0/2] hw/riscv/virt.c: change default CPU to 'max'

[PATCH 0/2] hw/riscv/virt.c: change default CPU to 'max'

[Daniel Henrique Barboza]

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(-)

-- 
2.49.0

[PATCH 1/2] target/riscv/tcg: make 'max' cpu rva23s64 compliant

[Daniel Henrique Barboza]

The 'max' CPU includes all available extensions we implement, but at
this moment it is not rva23s64 compliant due to missing checks that
the parent profile (rva22s64) does.

Users might expect that the a CPU called 'max' CPU will also compatible
with our latest S mode profile. Let's make it official.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
---
 target/riscv/tcg/tcg-cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 5aef9eef36..cd489ae35b 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -1486,6 +1486,8 @@ static void riscv_init_max_cpu_extensions(Object *obj)
     if (cpu->cfg.ext_smdbltrp) {
         isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_smdbltrp), false);
     }
+
+    object_property_set_bool(obj, "rva23s64", true, NULL);
 }
 
 static bool riscv_cpu_has_max_extensions(Object *cpu_obj)
-- 
2.49.0

Re: [PATCH 1/2] target/riscv/tcg: make 'max' cpu rva23s64 compliant

[Alistair Francis]

On Sat, Apr 5, 2025 at 1:29 AM Daniel Henrique Barboza
<dbarboza@ventanamicro.com> wrote:
>
> The 'max' CPU includes all available extensions we implement, but at
> this moment it is not rva23s64 compliant due to missing checks that
> the parent profile (rva22s64) does.
>
> Users might expect that the a CPU called 'max' CPU will also compatible
> with our latest S mode profile. Let's make it official.
>
> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>

Reviewed-by: Alistair Francis <alistair.francis@wdc.com>

Alistair

> ---
>  target/riscv/tcg/tcg-cpu.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index 5aef9eef36..cd489ae35b 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -1486,6 +1486,8 @@ static void riscv_init_max_cpu_extensions(Object *obj)
>      if (cpu->cfg.ext_smdbltrp) {
>          isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_smdbltrp), false);
>      }
> +
> +    object_property_set_bool(obj, "rva23s64", true, NULL);
>  }
>
>  static bool riscv_cpu_has_max_extensions(Object *cpu_obj)
> --
> 2.49.0
>
>

[PATCH 2/2] hw/riscv/virt.c: change default CPU to 'max'

[Daniel Henrique Barboza]

In [1], minute 44, we have a hint from a Canonical kernel developer that
the next Ubuntu LTS will be RVA23 compliant. If this really comes to
pass, the 'virt' CPU won't run it by default - we'll need to either use
'rva23s64' or 'max' CPUs instead because rv64 is not RVA23 compliant.
Other distros will follow suit eventually, given that RISC-V profiles
provides the most stable ABI to build a distro in the RISC-V land.

This exposes a long standing issue with the current rv64 CPU: it doesn't
represent anything in particular. Extensions were added in it as time
went by and we ended up with a CPU that has a random set of extensions.

Changing the default 'virt' CPU to 'max' gives users a guarantee that
the board will always run with the latest features/profile available in
QEMU, which is the intention of most regular users. Using 'max' as
default CPU is done by other QEMU archs like aarch64 so we'll be more
compatible with everyone else.

Note that this change does not affect existing scripts that are using
the rv64 CPU, e.g. a command line like "-cpu rv64,v=true" will work the
same after this patch.

[1] https://fosdem.org/2025/schedule/event/fosdem-2025-6031-risc-v-hardware-where-are-we-/

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
---
 hw/riscv/virt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index c9d255d8a8..ff7a122bef 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -1920,7 +1920,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
     mc->desc = "RISC-V VirtIO board";
     mc->init = virt_machine_init;
     mc->max_cpus = VIRT_CPUS_MAX;
-    mc->default_cpu_type = TYPE_RISCV_CPU_BASE;
+    mc->default_cpu_type = TYPE_RISCV_CPU_MAX;
     mc->block_default_type = IF_VIRTIO;
     mc->no_cdrom = 1;
     mc->pci_allow_0_address = true;
-- 
2.49.0

Re: [PATCH 2/2] hw/riscv/virt.c: change default CPU to 'max'

[Richard Henderson]

On 4/4/25 08:27, Daniel Henrique Barboza wrote:
> Using 'max' as
> default CPU is done by other QEMU archs like aarch64 so we'll be more
> compatible with everyone else.

This isn't true.  qemu-system-aarch64 -M virt defaults to cortex-a15 (for hysterical 
raisins), which is completely and totally useless.  Which means that one must always pass 
a -cpu option to qemu-system-aarch64.

Moreover, -cpu max has zero migration guarantees, so anyone who wants to be able to 
reliably migrate is encouraged to use a real cpu model.

I suppose, for throwaway VMs, -cpu max is a decent default.  But there's a lot to be said 
for not specifying a default at all.


r~

Re: [PATCH 2/2] hw/riscv/virt.c: change default CPU to 'max'

[Alistair Francis]

On Sat, Apr 5, 2025 at 9:02 AM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 4/4/25 08:27, Daniel Henrique Barboza wrote:
> > Using 'max' as
> > default CPU is done by other QEMU archs like aarch64 so we'll be more
> > compatible with everyone else.
>
> This isn't true.  qemu-system-aarch64 -M virt defaults to cortex-a15 (for hysterical
> raisins), which is completely and totally useless.  Which means that one must always pass
> a -cpu option to qemu-system-aarch64.
>
> Moreover, -cpu max has zero migration guarantees, so anyone who wants to be able to
> reliably migrate is encouraged to use a real cpu model.
>
> I suppose, for throwaway VMs, -cpu max is a decent default.  But there's a lot to be said
> for not specifying a default at all.

I agree. If we aren't going to specify a default machine, why specify
a default CPU?

It probably makes sense to deprecate the default CPU for non-vendor
machines and then force users to pick their own CPU. That should start
in 10.1 so it's a release offset from the removal of the default
machine.

Then maybe think about even removing rv32/rv64 CPUs and push people to
the profiles, as it's a lot clearer what they are getting.

Alistair

>
>
> r~
>

Re: [PATCH 2/2] hw/riscv/virt.c: change default CPU to 'max'

[Philippe Mathieu-Daudé]

On 7/4/25 01:31, Alistair Francis wrote:
> On Sat, Apr 5, 2025 at 9:02 AM Richard Henderson
> <richard.henderson@linaro.org> wrote:
>>
>> On 4/4/25 08:27, Daniel Henrique Barboza wrote:
>>> Using 'max' as
>>> default CPU is done by other QEMU archs like aarch64 so we'll be more
>>> compatible with everyone else.
>>
>> This isn't true.  qemu-system-aarch64 -M virt defaults to cortex-a15 (for hysterical
>> raisins), which is completely and totally useless.  Which means that one must always pass
>> a -cpu option to qemu-system-aarch64.
>>
>> Moreover, -cpu max has zero migration guarantees, so anyone who wants to be able to
>> reliably migrate is encouraged to use a real cpu model.
>>
>> I suppose, for throwaway VMs, -cpu max is a decent default.  But there's a lot to be said
>> for not specifying a default at all.
> 
> I agree. If we aren't going to specify a default machine, why specify
> a default CPU?
> 
> It probably makes sense to deprecate the default CPU for non-vendor
> machines and then force users to pick their own CPU. That should start
> in 10.1 so it's a release offset from the removal of the default
> machine.

IMHO this is the sanest things to do.

> Then maybe think about even removing rv32/rv64 CPUs and push people to
> the profiles, as it's a lot clearer what they are getting.
> 
> Alistair
> 
>>
>>
>> r~
>>
> 

Re: [PATCH 2/2] hw/riscv/virt.c: change default CPU to 'max'

[Andrew Jones]

On Fri, Apr 04, 2025 at 12:27:50PM -0300, Daniel Henrique Barboza wrote:
> In [1], minute 44, we have a hint from a Canonical kernel developer that
> the next Ubuntu LTS will be RVA23 compliant. If this really comes to
> pass, the 'virt' CPU won't run it by default - we'll need to either use
> 'rva23s64' or 'max' CPUs instead because rv64 is not RVA23 compliant.
> Other distros will follow suit eventually, given that RISC-V profiles
> provides the most stable ABI to build a distro in the RISC-V land.
> 
> This exposes a long standing issue with the current rv64 CPU: it doesn't
> represent anything in particular. Extensions were added in it as time
> went by and we ended up with a CPU that has a random set of extensions.
> 
> Changing the default 'virt' CPU to 'max' gives users a guarantee that
> the board will always run with the latest features/profile available in
> QEMU, which is the intention of most regular users. Using 'max' as
> default CPU is done by other QEMU archs like aarch64 so we'll be more
> compatible with everyone else.
> 
> Note that this change does not affect existing scripts that are using
> the rv64 CPU, e.g. a command line like "-cpu rv64,v=true" will work the
> same after this patch.
> 
> [1] https://fosdem.org/2025/schedule/event/fosdem-2025-6031-risc-v-hardware-where-are-we-/
> 
> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> ---
>  hw/riscv/virt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index c9d255d8a8..ff7a122bef 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -1920,7 +1920,7 @@ static void virt_machine_class_init(ObjectClass *oc, void *data)
>      mc->desc = "RISC-V VirtIO board";
>      mc->init = virt_machine_init;
>      mc->max_cpus = VIRT_CPUS_MAX;
> -    mc->default_cpu_type = TYPE_RISCV_CPU_BASE;
> +    mc->default_cpu_type = TYPE_RISCV_CPU_MAX;
>      mc->block_default_type = IF_VIRTIO;
>      mc->no_cdrom = 1;
>      mc->pci_allow_0_address = true;
> -- 
> 2.49.0
>

Reviewed-by: Andrew Jones <ajones@ventanamicro.com>

Re: [PATCH 0/2] hw/riscv/virt.c: change default CPU to 'max'

[Daniel Henrique Barboza]

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(-)
> 

Re: [PATCH 0/2] hw/riscv/virt.c: change default CPU to 'max'

[Alistair Francis]

On Tue, May 6, 2025 at 8:47 AM Daniel Henrique Barboza
<dbarboza@ventanamicro.com> wrote:
>
> 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.

I worry it will cause us grief in the future. I think if we are
changing it we should just drop any default.

With profiles now becoming popular it's easy for users to just pick a
profile CPU when starting the machine.

Alistair

>
>
> 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(-)
> >
>
>

Re: [PATCH 0/2] hw/riscv/virt.c: change default CPU to 'max'

[David Abdurachmanov]

On Mon, May 19, 2025 at 3:20 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, May 6, 2025 at 8:47 AM Daniel Henrique Barboza
> <dbarboza@ventanamicro.com> wrote:
> >
> > 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.
>
> I worry it will cause us grief in the future. I think if we are
> changing it we should just drop any default.
>
> With profiles now becoming popular it's easy for users to just pick a
> profile CPU when starting the machine.
>

Hi Alistair,

FYI the next virt-manager release will default to maximum CPU on riscv
if the guest type is QEMU. Basically if you are using libvirt/QEMU
(non-KVM guests) and setup VMs with virt-install it will get maximum
CPU.

See PR:
https://github.com/virt-manager/virt-manager/pull/784

Our current instructions in Fedora/RISCV set cpu to max too. This is
done by passing --cpu mode=maximum to virt-install command.

david