qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Jones <ajones@ventanamicro.com>
To: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
	alistair.francis@wdc.com,  bmeng@tinylab.org,
	liweiwei@iscas.ac.cn, zhiwei_liu@linux.alibaba.com,
	 palmer@rivosinc.com
Subject: Re: [PATCH v7 03/16] target/riscv: add rv64i CPU
Date: Wed, 1 Nov 2023 10:02:15 +0100	[thread overview]
Message-ID: <20231101-f72b888f87063028f40c6e7a@orel> (raw)
In-Reply-To: <20231031203916.197332-4-dbarboza@ventanamicro.com>

On Tue, Oct 31, 2023 at 05:39:03PM -0300, Daniel Henrique Barboza wrote:
> We don't have any form of a 'bare bones' CPU. rv64, our default CPUs,
> comes with a lot of defaults. This is fine for most regular uses but
> it's not suitable when more control of what is actually loaded in the
> CPU is required.
> 
> A bare-bones CPU would be annoying to deal with if not by profile
> support, a way to load a multitude of extensions with a single flag. Profile
> support is going to be implemented shortly, so let's add a CPU for it.
> 
> The new 'rv64i' CPU will have only RVI loaded. It is inspired in the
> profile specification that dictates, for RVA22U64 [1]:
> 
> "RVA22U64 Mandatory Base
>  RV64I is the mandatory base ISA for RVA22U64"
> 
> And so it seems that RV64I is the mandatory base ISA for all profiles
> listed in [1], making it an ideal CPU to use with profile support.
> 
> rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features
> from pre-existent CPUs:
> 
> - it allows extensions to be enabled, like generic CPUs;
> - it will not inherit extension defaults, like vendor CPUs.
> 
> This is the minimum extension set to boot OpenSBI and buildroot using
> rv64i:
> 
> ./build/qemu-system-riscv64 -nographic -M virt \
>     -cpu rv64i,g=true,c=true,s=true,u=true
> 
> Our minimal riscv,isa in this case will be:
> 
>  # cat /proc/device-tree/cpus/cpu@0/riscv,isa
> rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd#
> 
> [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc
> 
> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> ---
>  target/riscv/cpu-qom.h |  2 ++
>  target/riscv/cpu.c     | 25 +++++++++++++++++++++++++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/target/riscv/cpu-qom.h b/target/riscv/cpu-qom.h
> index 7831e86d37..ea9a752280 100644
> --- a/target/riscv/cpu-qom.h
> +++ b/target/riscv/cpu-qom.h
> @@ -25,6 +25,7 @@
>  #define TYPE_RISCV_CPU "riscv-cpu"
>  #define TYPE_RISCV_DYNAMIC_CPU "riscv-dynamic-cpu"
>  #define TYPE_RISCV_VENDOR_CPU "riscv-vendor-cpu"
> +#define TYPE_RISCV_BARE_CPU "riscv-bare-cpu"
>  
>  #define RISCV_CPU_TYPE_SUFFIX "-" TYPE_RISCV_CPU
>  #define RISCV_CPU_TYPE_NAME(name) (name RISCV_CPU_TYPE_SUFFIX)
> @@ -35,6 +36,7 @@
>  #define TYPE_RISCV_CPU_BASE32           RISCV_CPU_TYPE_NAME("rv32")
>  #define TYPE_RISCV_CPU_BASE64           RISCV_CPU_TYPE_NAME("rv64")
>  #define TYPE_RISCV_CPU_BASE128          RISCV_CPU_TYPE_NAME("x-rv128")
> +#define TYPE_RISCV_CPU_RV64I            RISCV_CPU_TYPE_NAME("rv64i")
>  #define TYPE_RISCV_CPU_IBEX             RISCV_CPU_TYPE_NAME("lowrisc-ibex")
>  #define TYPE_RISCV_CPU_SHAKTI_C         RISCV_CPU_TYPE_NAME("shakti-c")
>  #define TYPE_RISCV_CPU_SIFIVE_E31       RISCV_CPU_TYPE_NAME("sifive-e31")
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 822970345c..98b2a4061a 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -544,6 +544,18 @@ static void rv128_base_cpu_init(Object *obj)
>      set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV57);
>  #endif
>  }
> +
> +static void rv64i_bare_cpu_init(Object *obj)
> +{
> +    CPURISCVState *env = &RISCV_CPU(obj)->env;
> +    riscv_cpu_set_misa(env, MXL_RV64, RVI);
> +
> +    /* Set latest version of privileged specification */
> +    env->priv_ver = PRIV_VERSION_LATEST;

The beauty of rv64i is we'll finally know exactly what we're configuring
when we select it and some set of extensions. With that in mind I think
we should also be explicit about which version of the priv spec is
implemented, but we can't just pick a version now, since we may need to
update it later. I think we have the following options:

 1. Expose priv version properties (v1_10_0, ...) and either require the
    user to select one or default to the latest. (Any versions we don't
    want to support for rv64i would error out if selected.)

 2. Add multiple rv64i base cpu types where the version is also specified
    in the name, e.g. rv64i_1_12_0, and then maybe have an rv64i alias
    which always points at the latest.

A nice thing about (1) is that we can expose the boolean version
properties in cpu model expansion. A nice thing about (2) is that the user
will either be forced to select an explicit version or, if we have the
alias, libvirt will convert 'rv64i' into its full name when storing it
in the XML. But, we can force the user to select a version with (1) too by
not providing a default. While that adds a burden of always having to
provide a version, it's not a big deal for a barebones cpu, since all
extensions necessary to create a useful cpu are also required. And,
profiles alleviate the burden. For example, rva22s64 mandates Ss1p12, so
that profile will automatically set the v1_12_0 property.

I think we should implement (1) without a default.

> +#ifndef CONFIG_USER_ONLY
> +    set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV57);

I think we should require the user provide one of sv39, sv48, ... rather
than have a default for this too. S-mode profiles will again automatically
set this to what it mandates, relieving the burden.

> +#endif
> +}
>  #else
>  static void rv32_base_cpu_init(Object *obj)
>  {
> @@ -1732,6 +1744,13 @@ void riscv_cpu_list(void)
>          .instance_init = initfn              \
>      }
>  
> +#define DEFINE_BARE_CPU(type_name, initfn) \
> +    {                                      \
> +        .name = type_name,                 \
> +        .parent = TYPE_RISCV_BARE_CPU,     \
> +        .instance_init = initfn            \
> +    }
> +
>  static const TypeInfo riscv_cpu_type_infos[] = {
>      {
>          .name = TYPE_RISCV_CPU,
> @@ -1754,6 +1773,11 @@ static const TypeInfo riscv_cpu_type_infos[] = {
>          .parent = TYPE_RISCV_CPU,
>          .abstract = true,
>      },
> +    {
> +        .name = TYPE_RISCV_BARE_CPU,
> +        .parent = TYPE_RISCV_CPU,
> +        .abstract = true,
> +    },
>      DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_ANY,      riscv_any_cpu_init),
>      DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_MAX,      riscv_max_cpu_init),
>  #if defined(TARGET_RISCV32)
> @@ -1770,6 +1794,7 @@ static const TypeInfo riscv_cpu_type_infos[] = {
>      DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_THEAD_C906,  rv64_thead_c906_cpu_init),
>      DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_VEYRON_V1,   rv64_veyron_v1_cpu_init),
>      DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE128,  rv128_base_cpu_init),
> +    DEFINE_BARE_CPU(TYPE_RISCV_CPU_RV64I, rv64i_bare_cpu_init),
>  #endif
>  };
>  
> -- 
> 2.41.0
>

Thanks,
drew


  reply	other threads:[~2023-11-01  9:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-31 20:39 [PATCH v7 00/16] rv64i CPU, RVA22U64 profile support Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 01/16] target/riscv: create TYPE_RISCV_VENDOR_CPU Daniel Henrique Barboza
2023-11-01  9:19   ` Andrew Jones
2023-10-31 20:39 ` [PATCH v7 02/16] target/riscv/tcg: do not use "!generic" CPU checks Daniel Henrique Barboza
2023-11-01  9:20   ` Andrew Jones
2023-10-31 20:39 ` [PATCH v7 03/16] target/riscv: add rv64i CPU Daniel Henrique Barboza
2023-11-01  9:02   ` Andrew Jones [this message]
2023-11-01  9:27     ` Daniel Henrique Barboza
2023-11-01  9:47       ` Andrew Jones
2023-10-31 20:39 ` [PATCH v7 04/16] target/riscv: add zicbop extension flag Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 05/16] target/riscv/tcg: add 'zic64b' support Daniel Henrique Barboza
2023-11-01  9:04   ` Andrew Jones
2023-10-31 20:39 ` [PATCH v7 06/16] riscv-qmp-cmds.c: expose named features in cpu_model_expansion Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 07/16] target/riscv: add rva22u64 profile definition Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 08/16] target/riscv/kvm: add 'rva22u64' flag as unavailable Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 09/16] target/riscv/tcg: add user flag for profile support Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 10/16] target/riscv/tcg: add MISA user options hash Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 11/16] target/riscv/tcg: add riscv_cpu_write_misa_bit() Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 12/16] target/riscv/tcg: handle profile MISA bits Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 13/16] target/riscv/tcg: add hash table insert helpers Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 14/16] target/riscv/tcg: honor user choice for G MISA bits Daniel Henrique Barboza
2023-10-31 20:39 ` [PATCH v7 15/16] target/riscv/tcg: validate profiles during finalize Daniel Henrique Barboza
2023-11-01  9:17   ` Andrew Jones
2023-10-31 20:39 ` [PATCH v7 16/16] riscv-qmp-cmds.c: add profile flags in cpu-model-expansion Daniel Henrique Barboza
2023-11-01  9:19   ` Andrew Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231101-f72b888f87063028f40c6e7a@orel \
    --to=ajones@ventanamicro.com \
    --cc=alistair.francis@wdc.com \
    --cc=bmeng@tinylab.org \
    --cc=dbarboza@ventanamicro.com \
    --cc=liweiwei@iscas.ac.cn \
    --cc=palmer@rivosinc.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=zhiwei_liu@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).