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 12/16] target/riscv/kvm.c: update KVM MISA bits
Date: Wed, 7 Jun 2023 14:05:59 +0200 [thread overview]
Message-ID: <20230607-c99f4cbc55fb2f02b4a26023@orel> (raw)
In-Reply-To: <20230530194623.272652-13-dbarboza@ventanamicro.com>
On Tue, May 30, 2023 at 04:46:19PM -0300, Daniel Henrique Barboza wrote:
> Our design philosophy with KVM properties can be resumed in two main
> decisions based on KVM interface availability and what the user wants to
> do:
>
> - if the user disables an extension that the host KVM module doesn't
> know about (i.e. it doesn't implement the kvm_get_one_reg() interface),
> keep booting the CPU. This will avoid users having to deal with issues
> with older KVM versions while disabling features they don't care;
>
> - for any other case we're going to error out immediately. If the user
> wants to enable a feature that KVM doesn't know about this a problem that
> is worth aborting - the user must know that the feature wasn't enabled
> in the hart. Likewise, if KVM knows about the extension, the user wants
> to enable/disable it, and we fail to do it so, that's also a problem we
> can't shrug it off.
>
> For MISA bits we're going to be a little more conservative: we won't
> even try enabling bits that aren't already available in the host. The
> ioctl() is so likely to fail that's not worth trying. This check is
> already done in the previous patch, in kvm_cpu_set_misa_ext_cfg(), thus
> we don't need to worry about it now.
>
> In kvm_riscv_update_cpu_misa_ext() we'll go through every potential user
> option and do as follows:
>
> - if the user didn't set the property or set to the same value of the
> host, do nothing;
>
> - Disable the given extension in KVM. If it fails we need to verify the
> error code. -EINVAL indicates that KVM doesn't know about the reg, so
> re-enable the extension in env->misa_ext and keep booting. If it fails
We shouldn't "re-enable the extension in env->misa_ext..." when the
extension isn't supported by KVM for any reason. But, assuming EINVAL
is only returned when KVM doesn't support the extension (I wish it
returned ENOENT instead), then we'll never get EINVAL here in update
anyway. env->misa_ext is initialized to what KVM supports, so it
wouldn't have had this unsupported extension bit set in the first
place, meaning 'user_set' wouldn't get set at property setting time
either.
> for any other reason we're going to exit out.
>
> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> ---
> target/riscv/kvm.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
> index 6afd56cda5..bb1dafe263 100644
> --- a/target/riscv/kvm.c
> +++ b/target/riscv/kvm.c
> @@ -166,6 +166,42 @@ static void kvm_cpu_set_misa_ext_cfg(Object *obj, Visitor *v,
> "enabled in the host", misa_ext_cfg->name);
> }
>
> +static void kvm_riscv_update_cpu_misa_ext(RISCVCPU *cpu, CPUState *cs)
> +{
> + CPURISCVState *env = &cpu->env;
> + uint64_t id, reg;
> + int i, ret;
> +
> + for (i = 0; i < ARRAY_SIZE(kvm_misa_ext_cfgs); i++) {
> + RISCVCPUMisaExtConfig *misa_cfg = &kvm_misa_ext_cfgs[i];
> +
> + if (!misa_cfg->user_set) {
> + continue;
> + }
> +
> + /* If we're here we're going to disable the MISA bit */
> + reg = 0;
> + id = kvm_riscv_reg_id(env, KVM_REG_RISCV_ISA_EXT,
> + misa_cfg->kvm_reg_id);
> + ret = kvm_set_one_reg(cs, id, ®);
> + if (ret != 0) {
> + if (ret == -EINVAL) {
> + /*
> + * KVM doesn't know how to handle this bit. Since
> + * it's an extension that the user wants to disable,
> + * do not error out.
> + */
> + continue;
This case can be replaced with a comment explaining we don't ever
expect EINVAL here at update time, since user_set will never be
true for user-disabled extensions which KVM doesn't support.
> + } else {
> + error_report("Unable to set KVM reg %s, error %d",
> + misa_cfg->name, ret);
> + exit(EXIT_FAILURE);
> + }
> + }
> + env->misa_ext &= ~misa_cfg->misa_bit;
> + }
> +}
> +
> static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj)
> {
> int i;
> @@ -632,8 +668,13 @@ int kvm_arch_init_vcpu(CPUState *cs)
>
> if (!object_dynamic_cast(OBJECT(cpu), TYPE_RISCV_CPU_HOST)) {
> ret = kvm_vcpu_set_machine_ids(cpu, cs);
> + if (ret != 0) {
> + return ret;
> + }
> }
>
> + kvm_riscv_update_cpu_misa_ext(cpu, cs);
> +
> return ret;
> }
>
> --
> 2.40.1
>
>
Thanks,
drew
next prev parent reply other threads:[~2023-06-07 12:07 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 19:46 [PATCH 00/16] target/riscv, KVM: fixes and enhancements Daniel Henrique Barboza
2023-05-30 19:46 ` [PATCH 01/16] target/riscv: skip features setup for KVM CPUs Daniel Henrique Barboza
2023-06-02 4:17 ` Alistair Francis
2023-06-02 14:52 ` Andrew Jones
2023-05-30 19:46 ` [PATCH 02/16] hw/riscv/virt.c: skip 'mmu-type' FDT if satp mode not set Daniel Henrique Barboza
2023-06-06 13:13 ` Andrew Jones
2023-06-06 20:07 ` Daniel Henrique Barboza
2023-06-12 3:53 ` Alistair Francis
2023-05-30 19:46 ` [PATCH 03/16] target/riscv/cpu.c: restrict 'mvendorid' value Daniel Henrique Barboza
2023-06-06 13:19 ` Andrew Jones
2023-06-06 20:06 ` Daniel Henrique Barboza
2023-06-12 3:56 ` Alistair Francis
2023-06-12 18:52 ` Daniel Henrique Barboza
2023-06-13 6:46 ` Alistair Francis
2023-05-30 19:46 ` [PATCH 04/16] target/riscv/cpu.c: restrict 'mimpid' value Daniel Henrique Barboza
2023-06-06 15:31 ` Andrew Jones
2023-05-30 19:46 ` [PATCH 05/16] target/riscv/cpu.c: restrict 'marchid' value Daniel Henrique Barboza
2023-06-06 15:33 ` Andrew Jones
2023-05-30 19:46 ` [PATCH 06/16] target/riscv: use KVM scratch CPUs to init KVM properties Daniel Henrique Barboza
2023-06-06 15:46 ` Andrew Jones
2023-06-12 3:59 ` Alistair Francis
2023-05-30 19:46 ` [PATCH 07/16] target/riscv: read marchid/mimpid in kvm_riscv_init_machine_ids() Daniel Henrique Barboza
2023-06-06 15:47 ` Andrew Jones
2023-06-12 4:05 ` Alistair Francis
2023-05-30 19:46 ` [PATCH 08/16] target/riscv: handle mvendorid/marchid/mimpid for KVM CPUs Daniel Henrique Barboza
2023-06-06 15:51 ` Andrew Jones
2023-05-30 19:46 ` [PATCH 09/16] linux-headers: Update to v6.4-rc1 Daniel Henrique Barboza
2023-05-30 19:46 ` [PATCH 10/16] target/riscv/kvm.c: init 'misa_ext_mask' with scratch CPU Daniel Henrique Barboza
2023-06-06 15:54 ` Andrew Jones
2023-05-30 19:46 ` [PATCH 11/16] target/riscv: add KVM specific MISA properties Daniel Henrique Barboza
2023-06-07 11:33 ` Andrew Jones
2023-05-30 19:46 ` [PATCH 12/16] target/riscv/kvm.c: update KVM MISA bits Daniel Henrique Barboza
2023-06-07 12:05 ` Andrew Jones [this message]
2023-05-30 19:46 ` [PATCH 13/16] target/riscv/kvm.c: add multi-letter extension KVM properties Daniel Henrique Barboza
2023-06-07 11:48 ` Andrew Jones
2023-06-07 19:59 ` Daniel Henrique Barboza
2023-06-08 6:02 ` Andrew Jones
2023-06-12 19:24 ` Daniel Henrique Barboza
2023-05-30 19:46 ` [PATCH 14/16] target/riscv: adapt 'riscv_isa_string' for KVM Daniel Henrique Barboza
2023-06-07 12:21 ` Andrew Jones
2023-06-13 10:29 ` Daniel Henrique Barboza
2023-06-13 18:19 ` Daniel Henrique Barboza
2023-05-30 19:46 ` [PATCH 15/16] target/riscv: update multi-letter extension KVM properties Daniel Henrique Barboza
2023-06-07 12:30 ` Andrew Jones
2023-05-30 19:46 ` [PATCH 16/16] target/riscv/kvm.c: read/write (cbom|cboz)_blocksize in KVM Daniel Henrique Barboza
2023-06-07 13:01 ` Andrew Jones
2023-06-07 20:37 ` Daniel Henrique Barboza
2023-06-08 6:39 ` 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=20230607-c99f4cbc55fb2f02b4a26023@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).