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 <dbarb...@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 <ajo...@ventanamicro.com>

Reply via email to