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 v3 3/6] target/riscv/tcg: add user flag for profile support
Date: Mon, 23 Oct 2023 10:16:33 +0200	[thread overview]
Message-ID: <20231023-2018025adea3ffaebbbefe23@orel> (raw)
In-Reply-To: <20231020223951.357513-4-dbarboza@ventanamicro.com>

On Fri, Oct 20, 2023 at 07:39:48PM -0300, Daniel Henrique Barboza wrote:
> The TCG emulation implements all the extensions described in the
> RVA22U64 profile, both mandatory and optional. The mandatory extensions
> will be enabled via the profile flag. We'll leave the optional
> extensions to be enabled by hand.
> 
> Given that this is the first profile we're implementing in TCG we'll
> need some ground work first:
> 
> - all profiles declared in riscv_profiles[] will be exposed to users.
> TCG is the main accelerator we're considering when adding profile
> support in QEMU, so for now it's safe to assume that all profiles in
> riscv_profiles[] will be relevant to TCG;
> 
> - we'll not support user profile settings for vendor CPUs. The flags
> will still be exposed but users won't be able to change them. The idea
> is that vendor CPUs in the future can enable profiles internally in
> their cpu_init() functions, showing to the external world that the CPU
> supports a certain profile. But users won't be able to enable/disable
> it;
> 
> - Setting a profile to 'true' means 'enable all mandatory extensions of
> this profile, setting it to 'false' means disabling all its mandatory
> extensions. Disabling a profile is discouraged for regular use and will
> issue an user warning. User choices for individual extensions will take
> precedence, i.e. enabling a profile will not enable extensions that the
> user set to 'false', and vice-versa. This will make us independent of
> left-to-right ordering in the QEMU command line, i.e. the following QEMU
> command lines:
> 
> -cpu rv64,zicbom=false,rva22u64=true,Zifencei=false
> -cpu rv64,zicbom=false,Zifencei=false,rva22u64=true
> -cpu rv64,rva22u64=true,zicbom=false,Zifencei=false
> 
> They mean the same thing: "enable all mandatory extensions of the
> rva22u64 profile while keeping zicbom and Zifencei disabled".

Hmm, I'm not sure I agree with special-casing profiles like this. I think
the left-to-right processing should be consistent for all. I'm also not
sure we should always warn when disabling a profile. For example, if a
user does

 -cpu rv64,rva22u64=true,rva22u64=false

then they'll get a warning, even though all they're doing is restoring the
cpu model. While that looks like an odd thing to do, a script may be
adding the rva22u64=true and the rva22u64=false is the user input which
undoes what the script did.

As far as warnings go, it'd be nice to warn when mandatory profile
extensions are disabled from an enabled profile. Doing that might be
useful for debug, but users which do it without being aware they're
"breaking" the profile may learn from that warning. Note, the warning
should only come when the profile is actually enabled and when the
extension would actually be disabled, i.e.

 -cpu rv64,rva22u64=true,c=off

should warn

 -cpu rv64,c=off,rva22u64=true

should not warn (rva22u64 overrides c=off since it's to the right)

 -cpu rv64,rva22u64=true,rva22u64=false,c=off

should not warn (rva22u64 is not enabled)

And,

 -cpu rv64,rva22u64=true,rva24u64=false

should warn for each extension which is mandatory in both profiles.

Thanks,
drew


  reply	other threads:[~2023-10-23  8:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20 22:39 [PATCH v3 0/6] riscv: RVA22U64 profile support Daniel Henrique Barboza
2023-10-20 22:39 ` [PATCH v3 1/6] target/riscv: add rva22u64 profile definition Daniel Henrique Barboza
2023-10-25  6:22   ` LIU Zhiwei
2023-10-25 13:14     ` Daniel Henrique Barboza
2023-10-20 22:39 ` [PATCH v3 2/6] target/riscv/kvm: add 'rva22u64' flag as unavailable Daniel Henrique Barboza
2023-10-25  6:28   ` LIU Zhiwei
2023-10-20 22:39 ` [PATCH v3 3/6] target/riscv/tcg: add user flag for profile support Daniel Henrique Barboza
2023-10-23  8:16   ` Andrew Jones [this message]
2023-10-23 17:00     ` Daniel Henrique Barboza
2023-10-23 17:35       ` Andrew Jones
2023-10-23 17:54         ` Daniel Henrique Barboza
2023-10-26 14:36         ` Andrea Bolognani
2023-10-26 15:14           ` Andrew Jones
2023-10-26 17:36             ` Andrea Bolognani
2023-10-27 17:52               ` Daniel Henrique Barboza
2023-10-28  9:31                 ` Andrew Jones
2023-10-25  6:35   ` LIU Zhiwei
2023-10-20 22:39 ` [PATCH v3 4/6] target/riscv/tcg: add MISA user options hash Daniel Henrique Barboza
2023-10-25  6:45   ` LIU Zhiwei
2023-10-20 22:39 ` [PATCH v3 5/6] target/riscv/tcg: add riscv_cpu_write_misa_bit() Daniel Henrique Barboza
2023-10-25  6:45   ` LIU Zhiwei
2023-10-20 22:39 ` [PATCH v3 6/6] target/riscv/tcg: handle profile MISA bits Daniel Henrique Barboza
2023-10-25  6:46   ` LIU Zhiwei

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=20231023-2018025adea3ffaebbbefe23@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).