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 v4 16/19] target/riscv/cpu.c: create KVM mock properties
Date: Tue, 27 Jun 2023 10:11:16 +0200 [thread overview]
Message-ID: <20230627-204449ad8ad9fccf5411fec1@orel> (raw)
In-Reply-To: <20230626220209.22142-17-dbarboza@ventanamicro.com>
On Mon, Jun 26, 2023 at 07:02:06PM -0300, Daniel Henrique Barboza wrote:
> KVM-specific properties are being created inside target/riscv/kvm.c. But
> at this moment we're gathering all the remaining properties from TCG and
> adding them as is when running KVM. This creates a situation where
> non-KVM properties are setting flags to 'true' due to its default
> settings (e.g. Zawrs). Users can also freely enable them via command
> line.
>
> This doesn't impact runtime per se because KVM doesn't care about these
> flags, but code such as riscv_isa_string_ext() take those flags into
> account. The result is that, for a KVM guest, setting non-KVM properties
> will make them appear in the riscv,isa DT.
>
> We want to keep the same API for both TCG and KVM and at the same time,
> when running KVM, forbid non-KVM extensions to be enabled internally. We
> accomplish both by changing riscv_cpu_add_user_properties() to add a
> mock/no-op boolean property for every non-KVM extension in
> riscv_cpu_extensions[]. Then, when running KVM, users are still free to
> set extensions at will, we'll treat non-KVM extensions as a no-op, and
> riscv_isa_string_ext() will not report bogus extensions in the DT.
We're no longer treating these as no-ops. We're now intercepting attempts
to set unsupported extensions and erroring out.
>
> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> ---
> target/riscv/cpu.c | 40 +++++++++++++++++++++++++++++++++++++---
> 1 file changed, 37 insertions(+), 3 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index b65db165cc..ad4b0e3490 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1720,6 +1720,22 @@ static Property riscv_cpu_extensions[] = {
> DEFINE_PROP_END_OF_LIST(),
> };
>
> +
> +static void cpu_set_cfg_noop(Object *obj, Visitor *v,
As stated above, I don't think 'noop' conveys the right message.
> + const char *name,
> + void *opaque, Error **errp)
> +{
> + const char *propname = opaque;
> + bool value;
> +
> + if (!visit_type_bool(v, name, &value, errp)) {
> + return;
> + }
> +
We should only error out when value == true. Just like the other
KVM-unsupported extensions, we don't mind if the user explicitly
disables something we can't handle.
> + error_setg(errp, "extension %s is not available with KVM",
> + propname);
> +}
> +
> /*
> * Add CPU properties with user-facing flags.
> *
> @@ -1738,9 +1754,27 @@ static void riscv_cpu_add_user_properties(Object *obj)
> riscv_cpu_add_misa_properties(obj);
>
> for (prop = riscv_cpu_extensions; prop && prop->name; prop++) {
> - /* Check if KVM didn't create the property already */
> - if (object_property_find(obj, prop->name)) {
> - continue;
> + if (riscv_running_kvm()) {
> + /* Check if KVM didn't create the property already */
The check is for the positive, so I think the comment would read better as
"Check if KVM created the property already."
> + if (object_property_find(obj, prop->name)) {
> + continue;
> + }
> +
> + /*
> + * Set every multi-letter extension that KVM doesn't
> + * know as a no-op. This will allow users to set values
How about "Set the default to disabled for every extension unknown to
KVM and error out if the user attempts to enable any of them."
> + * to them while keeping their internal state to 'false'.
> + *
> + * We're giving a pass for non-bool properties since they're
> + * not related to the availability of extensions and can be
> + * safely ignored as is.
I guess that's OK for now. Ideally, we wouldn't have any non-booleans as
that will complicate QMP cpu model expansion. Instead, we'd have booleans
for valid values. For example, for vlen, we'd have vlen128, vlen256,
vlen512, etc.. Figuring out how to do that best is for another series
though.
> + */
> + if (prop->info == &qdev_prop_bool) {
> + object_property_add(obj, prop->name, "bool",
> + NULL, cpu_set_cfg_noop,
> + NULL, (void *)prop->name);
> + continue;
> + }
> }
>
> qdev_property_add_static(dev, prop);
> --
> 2.41.0
>
Thanks,
drew
next prev parent reply other threads:[~2023-06-27 8:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-26 22:01 [PATCH v4 00/19] target/riscv, KVM: fixes and enhancements Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 01/19] target/riscv: skip features setup for KVM CPUs Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 02/19] hw/riscv/virt.c: skip 'mmu-type' FDT if satp mode not set Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 03/19] target/riscv/cpu.c: restrict 'mvendorid' value Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 04/19] target/riscv/cpu.c: restrict 'mimpid' value Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 05/19] target/riscv/cpu.c: restrict 'marchid' value Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 06/19] target/riscv: use KVM scratch CPUs to init KVM properties Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 07/19] target/riscv: read marchid/mimpid in kvm_riscv_init_machine_ids() Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 08/19] target/riscv: handle mvendorid/marchid/mimpid for KVM CPUs Daniel Henrique Barboza
2023-06-26 22:01 ` [PATCH v4 09/19] linux-headers: Update to v6.4-rc1 Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 10/19] target/riscv/kvm.c: init 'misa_ext_mask' with scratch CPU Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 11/19] target/riscv/cpu: add misa_ext_info_arr[] Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 12/19] target/riscv: add KVM specific MISA properties Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 13/19] target/riscv/kvm.c: update KVM MISA bits Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 14/19] target/riscv/kvm.c: add multi-letter extension KVM properties Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 15/19] target/riscv/cpu.c: remove priv_ver check from riscv_isa_string_ext() Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 16/19] target/riscv/cpu.c: create KVM mock properties Daniel Henrique Barboza
2023-06-27 8:11 ` Andrew Jones [this message]
2023-06-26 22:02 ` [PATCH v4 17/19] target/riscv: update multi-letter extension KVM properties Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 18/19] target/riscv/kvm.c: add kvmconfig_get_cfg_addr() helper Daniel Henrique Barboza
2023-06-26 22:02 ` [PATCH v4 19/19] target/riscv/kvm.c: read/write (cbom|cboz)_blocksize in KVM Daniel Henrique Barboza
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=20230627-204449ad8ad9fccf5411fec1@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).