OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
a1be1d9a77
qemu-e2k/target/riscv/kvm.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

951 lines
24 KiB
C
Raw Normal View History

target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
/*
* RISC-V implementation of KVM hooks
*
* Copyright (c) 2020 Huawei Technologies Co., Ltd
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
* version 2 or later, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
* You should have received a copy of the GNU General Public License along with
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include "qemu/osdep.h"
#include <sys/ioctl.h>
#include <linux/kvm.h>
#include "qemu/timer.h"
target/riscv: add KVM specific MISA properties Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small impact since we just validating everything and error out if needed. But for KVM it would be good to know if a given value was set by the user or if it's a value already provided by KVM. Otherwise we don't know how to handle failed kvm_set_one_regs() when writing the configurations back. These characteristics make it overly complicated to use the same user facing flags for both KVM and TCG. A simpler approach is to create KVM specific properties that have specialized logic, forking KVM and TCG use cases for those cases only. Fully separating KVM/TCG properties is unneeded at this point - in fact we want the user experience to be as equal as possible, regardless of the acceleration chosen. We'll start this fork with the MISA properties, adding the MISA bits that the KVM driver currently supports. A new KVMCPUConfig type is introduced. It'll hold general information about an extension. For MISA extensions we're going to use the newly created getters of misa_ext_infos[] to populate their name and description. 'offset' holds the MISA bit (RVA, RVC, ...). We're calling it 'offset' instead of 'misa_bit' because this same KVMCPUConfig struct will be used to multi-letter extensions later on. This new type also holds a 'user_set' flag. This flag will be set when the user set an option that's different than what is already configured in the host, requiring KVM intervention to write the regs back during kvm_arch_init_vcpu(). Similar mechanics will be implemented for multi-letter extensions as well. There is no need to duplicate more code than necessary, so we're going to use the existing kvm_riscv_init_user_properties() to add the KVM specific properties. Any code that is adding a TCG user prop is then changed slightly to verify first if there's a KVM prop with the same name already added. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:30 +02:00
#include "qapi/error.h"
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
#include "qemu/error-report.h"
#include "qemu/main-loop.h"
target/riscv: add KVM specific MISA properties Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small impact since we just validating everything and error out if needed. But for KVM it would be good to know if a given value was set by the user or if it's a value already provided by KVM. Otherwise we don't know how to handle failed kvm_set_one_regs() when writing the configurations back. These characteristics make it overly complicated to use the same user facing flags for both KVM and TCG. A simpler approach is to create KVM specific properties that have specialized logic, forking KVM and TCG use cases for those cases only. Fully separating KVM/TCG properties is unneeded at this point - in fact we want the user experience to be as equal as possible, regardless of the acceleration chosen. We'll start this fork with the MISA properties, adding the MISA bits that the KVM driver currently supports. A new KVMCPUConfig type is introduced. It'll hold general information about an extension. For MISA extensions we're going to use the newly created getters of misa_ext_infos[] to populate their name and description. 'offset' holds the MISA bit (RVA, RVC, ...). We're calling it 'offset' instead of 'misa_bit' because this same KVMCPUConfig struct will be used to multi-letter extensions later on. This new type also holds a 'user_set' flag. This flag will be set when the user set an option that's different than what is already configured in the host, requiring KVM intervention to write the regs back during kvm_arch_init_vcpu(). Similar mechanics will be implemented for multi-letter extensions as well. There is no need to duplicate more code than necessary, so we're going to use the existing kvm_riscv_init_user_properties() to add the KVM specific properties. Any code that is adding a TCG user prop is then changed slightly to verify first if there's a KVM prop with the same name already added. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:30 +02:00
#include "qapi/visitor.h"
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
#include "sysemu/sysemu.h"
#include "sysemu/kvm.h"
#include "sysemu/kvm_int.h"
#include "cpu.h"
#include "trace.h"
#include "hw/pci/pci.h"
#include "exec/memattrs.h"
#include "exec/address-spaces.h"
#include "hw/boards.h"
#include "hw/irq.h"
#include "qemu/log.h"
#include "hw/loader.h"
target/riscv: Support start kernel directly by KVM Get kernel and fdt start address in virt.c, and pass them to KVM when cpu reset. Add kvm_riscv.h to place riscv specific interface. In addition, PLIC is created without M-mode PLIC contexts when KVM is enabled. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Message-id: 20220112081329.1835-7-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:22 +01:00
#include "kvm_riscv.h"
target/riscv: Handle KVM_EXIT_RISCV_SBI exit Use char-fe to handle console sbi call, which implement early console io while apply 'earlycon=sbi' into kernel parameters. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-9-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:24 +01:00
#include "sbi_ecall_interface.h"
#include "chardev/char-fe.h"
target/riscv: Add kvm_riscv_get/put_regs_timer Add kvm_riscv_get/put_regs_timer to synchronize virtual time context from KVM. To set register of RISCV_TIMER_REG(state) will occur a error from KVM on kvm_timer_state == 0. It's better to adapt in KVM, but it doesn't matter that adaping in QEMU. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-11-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:26 +01:00
#include "migration/migration.h"
target/riscv: Implement virtual time adjusting with vm state changing We hope that virtual time adjusts with vm state changing. When a vm is stopped, guest virtual time should stop counting and kvm_timer should be stopped. When the vm is resumed, guest virtual time should continue to count and kvm_timer should be restored. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-12-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:27 +01:00
#include "sysemu/runstate.h"
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
target/riscv: Implement function kvm_arch_init_vcpu Get isa info from kvm while kvm init. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-4-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:19 +01:00
static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type,
uint64_t idx)
{
uint64_t id = KVM_REG_RISCV | type | idx;
switch (riscv_cpu_mxl(env)) {
case MXL_RV32:
id |= KVM_REG_SIZE_U32;
break;
case MXL_RV64:
id |= KVM_REG_SIZE_U64;
break;
default:
g_assert_not_reached();
}
return id;
}
target/riscv: Implement kvm_arch_get_registers Get GPR CSR and FP registers from kvm by KVM_GET_ONE_REG ioctl. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-5-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:20 +01:00
#define RISCV_CORE_REG(env, name) kvm_riscv_reg_id(env, KVM_REG_RISCV_CORE, \
KVM_REG_RISCV_CORE_REG(name))
#define RISCV_CSR_REG(env, name) kvm_riscv_reg_id(env, KVM_REG_RISCV_CSR, \
KVM_REG_RISCV_CSR_REG(name))
target/riscv: Add kvm_riscv_get/put_regs_timer Add kvm_riscv_get/put_regs_timer to synchronize virtual time context from KVM. To set register of RISCV_TIMER_REG(state) will occur a error from KVM on kvm_timer_state == 0. It's better to adapt in KVM, but it doesn't matter that adaping in QEMU. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-11-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:26 +01:00
#define RISCV_TIMER_REG(env, name) kvm_riscv_reg_id(env, KVM_REG_RISCV_TIMER, \
KVM_REG_RISCV_TIMER_REG(name))
target/riscv: Implement kvm_arch_get_registers Get GPR CSR and FP registers from kvm by KVM_GET_ONE_REG ioctl. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-5-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:20 +01:00
#define RISCV_FP_F_REG(env, idx) kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_F, idx)
#define RISCV_FP_D_REG(env, idx) kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_D, idx)
#define KVM_RISCV_GET_CSR(cs, env, csr, reg) \
do { \
int ret = kvm_get_one_reg(cs, RISCV_CSR_REG(env, csr), &reg); \
if (ret) { \
return ret; \
} \
} while (0)
target/riscv: Implement kvm_arch_put_registers Put GPR CSR and FP registers to kvm by KVM_SET_ONE_REG ioctl Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-6-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:21 +01:00
#define KVM_RISCV_SET_CSR(cs, env, csr, reg) \
do { \
int ret = kvm_set_one_reg(cs, RISCV_CSR_REG(env, csr), &reg); \
if (ret) { \
return ret; \
} \
} while (0)
target/riscv: Add kvm_riscv_get/put_regs_timer Add kvm_riscv_get/put_regs_timer to synchronize virtual time context from KVM. To set register of RISCV_TIMER_REG(state) will occur a error from KVM on kvm_timer_state == 0. It's better to adapt in KVM, but it doesn't matter that adaping in QEMU. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-11-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:26 +01:00
#define KVM_RISCV_GET_TIMER(cs, env, name, reg) \
do { \
int ret = kvm_get_one_reg(cs, RISCV_TIMER_REG(env, name), &reg); \
if (ret) { \
abort(); \
} \
} while (0)
#define KVM_RISCV_SET_TIMER(cs, env, name, reg) \
do { \
target/riscv KVM_RISCV_SET_TIMER macro is not configured correctly Should set/get riscv all reg timer,i.e, time/compare/frequency/state. Signed-off-by: Yang Zhang <yang.zhang@hexintek.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1688 Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230707032306.4606-1-gaoshanliukou@163.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-07 05:23:06 +02:00
int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, name), &reg); \
target/riscv: Add kvm_riscv_get/put_regs_timer Add kvm_riscv_get/put_regs_timer to synchronize virtual time context from KVM. To set register of RISCV_TIMER_REG(state) will occur a error from KVM on kvm_timer_state == 0. It's better to adapt in KVM, but it doesn't matter that adaping in QEMU. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-11-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:26 +01:00
if (ret) { \
abort(); \
} \
} while (0)
target/riscv: add KVM specific MISA properties Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small impact since we just validating everything and error out if needed. But for KVM it would be good to know if a given value was set by the user or if it's a value already provided by KVM. Otherwise we don't know how to handle failed kvm_set_one_regs() when writing the configurations back. These characteristics make it overly complicated to use the same user facing flags for both KVM and TCG. A simpler approach is to create KVM specific properties that have specialized logic, forking KVM and TCG use cases for those cases only. Fully separating KVM/TCG properties is unneeded at this point - in fact we want the user experience to be as equal as possible, regardless of the acceleration chosen. We'll start this fork with the MISA properties, adding the MISA bits that the KVM driver currently supports. A new KVMCPUConfig type is introduced. It'll hold general information about an extension. For MISA extensions we're going to use the newly created getters of misa_ext_infos[] to populate their name and description. 'offset' holds the MISA bit (RVA, RVC, ...). We're calling it 'offset' instead of 'misa_bit' because this same KVMCPUConfig struct will be used to multi-letter extensions later on. This new type also holds a 'user_set' flag. This flag will be set when the user set an option that's different than what is already configured in the host, requiring KVM intervention to write the regs back during kvm_arch_init_vcpu(). Similar mechanics will be implemented for multi-letter extensions as well. There is no need to duplicate more code than necessary, so we're going to use the existing kvm_riscv_init_user_properties() to add the KVM specific properties. Any code that is adding a TCG user prop is then changed slightly to verify first if there's a KVM prop with the same name already added. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:30 +02:00
typedef struct KVMCPUConfig {
const char *name;
const char *description;
target_ulong offset;
int kvm_reg_id;
bool user_set;
target/riscv/kvm.c: add multi-letter extension KVM properties Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:32 +02:00
bool supported;
target/riscv: add KVM specific MISA properties Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small impact since we just validating everything and error out if needed. But for KVM it would be good to know if a given value was set by the user or if it's a value already provided by KVM. Otherwise we don't know how to handle failed kvm_set_one_regs() when writing the configurations back. These characteristics make it overly complicated to use the same user facing flags for both KVM and TCG. A simpler approach is to create KVM specific properties that have specialized logic, forking KVM and TCG use cases for those cases only. Fully separating KVM/TCG properties is unneeded at this point - in fact we want the user experience to be as equal as possible, regardless of the acceleration chosen. We'll start this fork with the MISA properties, adding the MISA bits that the KVM driver currently supports. A new KVMCPUConfig type is introduced. It'll hold general information about an extension. For MISA extensions we're going to use the newly created getters of misa_ext_infos[] to populate their name and description. 'offset' holds the MISA bit (RVA, RVC, ...). We're calling it 'offset' instead of 'misa_bit' because this same KVMCPUConfig struct will be used to multi-letter extensions later on. This new type also holds a 'user_set' flag. This flag will be set when the user set an option that's different than what is already configured in the host, requiring KVM intervention to write the regs back during kvm_arch_init_vcpu(). Similar mechanics will be implemented for multi-letter extensions as well. There is no need to duplicate more code than necessary, so we're going to use the existing kvm_riscv_init_user_properties() to add the KVM specific properties. Any code that is adding a TCG user prop is then changed slightly to verify first if there's a KVM prop with the same name already added. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:30 +02:00
} KVMCPUConfig;
#define KVM_MISA_CFG(_bit, _reg_id) \
{.offset = _bit, .kvm_reg_id = _reg_id}
/* KVM ISA extensions */
static KVMCPUConfig kvm_misa_ext_cfgs[] = {
KVM_MISA_CFG(RVA, KVM_RISCV_ISA_EXT_A),
KVM_MISA_CFG(RVC, KVM_RISCV_ISA_EXT_C),
KVM_MISA_CFG(RVD, KVM_RISCV_ISA_EXT_D),
KVM_MISA_CFG(RVF, KVM_RISCV_ISA_EXT_F),
KVM_MISA_CFG(RVH, KVM_RISCV_ISA_EXT_H),
KVM_MISA_CFG(RVI, KVM_RISCV_ISA_EXT_I),
KVM_MISA_CFG(RVM, KVM_RISCV_ISA_EXT_M),
};
static void kvm_cpu_set_misa_ext_cfg(Object *obj, Visitor *v,
const char *name,
void *opaque, Error **errp)
{
KVMCPUConfig *misa_ext_cfg = opaque;
target_ulong misa_bit = misa_ext_cfg->offset;
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
bool value, host_bit;
if (!visit_type_bool(v, name, &value, errp)) {
return;
}
host_bit = env->misa_ext_mask & misa_bit;
if (value == host_bit) {
return;
}
if (!value) {
misa_ext_cfg->user_set = true;
return;
}
/*
* Forbid users to enable extensions that aren't
* available in the hart.
*/
error_setg(errp, "Enabling MISA bit '%s' is not allowed: it's not "
"enabled in the host", misa_ext_cfg->name);
}
target/riscv/kvm.c: update KVM MISA bits 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. In the case of MISA bits we won't even try enabling bits that aren't already available in the host. The ioctl() is so likely to fail that it'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. Error out if anything goes wrong. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:31 +02:00
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++) {
KVMCPUConfig *misa_cfg = &kvm_misa_ext_cfgs[i];
target_ulong misa_bit = misa_cfg->offset;
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, &reg);
if (ret != 0) {
/*
* We're not checking for -EINVAL because if the bit is about
* to be disabled, it means that it was already enabled by
* KVM. We determined that by fetching the 'isa' register
* during init() time. Any error at this point is worth
* aborting.
*/
error_report("Unable to set KVM reg %s, error %d",
misa_cfg->name, ret);
exit(EXIT_FAILURE);
}
env->misa_ext &= ~misa_bit;
}
}
target/riscv/kvm.c: add multi-letter extension KVM properties Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:32 +02:00
#define CPUCFG(_prop) offsetof(struct RISCVCPUConfig, _prop)
#define KVM_EXT_CFG(_name, _prop, _reg_id) \
{.name = _name, .offset = CPUCFG(_prop), \
.kvm_reg_id = _reg_id}
static KVMCPUConfig kvm_multi_ext_cfgs[] = {
KVM_EXT_CFG("zicbom", ext_icbom, KVM_RISCV_ISA_EXT_ZICBOM),
KVM_EXT_CFG("zicboz", ext_icboz, KVM_RISCV_ISA_EXT_ZICBOZ),
KVM_EXT_CFG("zihintpause", ext_zihintpause, KVM_RISCV_ISA_EXT_ZIHINTPAUSE),
KVM_EXT_CFG("zbb", ext_zbb, KVM_RISCV_ISA_EXT_ZBB),
KVM_EXT_CFG("ssaia", ext_ssaia, KVM_RISCV_ISA_EXT_SSAIA),
KVM_EXT_CFG("sstc", ext_sstc, KVM_RISCV_ISA_EXT_SSTC),
KVM_EXT_CFG("svinval", ext_svinval, KVM_RISCV_ISA_EXT_SVINVAL),
KVM_EXT_CFG("svpbmt", ext_svpbmt, KVM_RISCV_ISA_EXT_SVPBMT),
};
target/riscv/kvm.c: add kvmconfig_get_cfg_addr() helper There are 2 places in which we need to get a pointer to a certain property of the cpu->cfg struct based on property offset. Next patch will add a couple more. Create a helper to avoid repeating this code over and over. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:37 +02:00
static void *kvmconfig_get_cfg_addr(RISCVCPU *cpu, KVMCPUConfig *kvmcfg)
{
return (void *)&cpu->cfg + kvmcfg->offset;
}
target/riscv/kvm.c: add multi-letter extension KVM properties Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:32 +02:00
static void kvm_cpu_cfg_set(RISCVCPU *cpu, KVMCPUConfig *multi_ext,
uint32_t val)
{
target/riscv/kvm.c: add kvmconfig_get_cfg_addr() helper There are 2 places in which we need to get a pointer to a certain property of the cpu->cfg struct based on property offset. Next patch will add a couple more. Create a helper to avoid repeating this code over and over. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:37 +02:00
bool *ext_enabled = kvmconfig_get_cfg_addr(cpu, multi_ext);
target/riscv/kvm.c: add multi-letter extension KVM properties Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:32 +02:00
*ext_enabled = val;
}
static uint32_t kvm_cpu_cfg_get(RISCVCPU *cpu,
KVMCPUConfig *multi_ext)
{
target/riscv/kvm.c: add kvmconfig_get_cfg_addr() helper There are 2 places in which we need to get a pointer to a certain property of the cpu->cfg struct based on property offset. Next patch will add a couple more. Create a helper to avoid repeating this code over and over. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:37 +02:00
bool *ext_enabled = kvmconfig_get_cfg_addr(cpu, multi_ext);
target/riscv/kvm.c: add multi-letter extension KVM properties Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:32 +02:00
return *ext_enabled;
}
static void kvm_cpu_set_multi_ext_cfg(Object *obj, Visitor *v,
const char *name,
void *opaque, Error **errp)
{
KVMCPUConfig *multi_ext_cfg = opaque;
RISCVCPU *cpu = RISCV_CPU(obj);
bool value, host_val;
if (!visit_type_bool(v, name, &value, errp)) {
return;
}
host_val = kvm_cpu_cfg_get(cpu, multi_ext_cfg);
/*
* Ignore if the user is setting the same value
* as the host.
*/
if (value == host_val) {
return;
}
if (!multi_ext_cfg->supported) {
/*
* Error out if the user is trying to enable an
* extension that KVM doesn't support. Ignore
* option otherwise.
*/
if (value) {
error_setg(errp, "KVM does not support disabling extension %s",
multi_ext_cfg->name);
}
return;
}
multi_ext_cfg->user_set = true;
kvm_cpu_cfg_set(cpu, multi_ext_cfg, value);
}
target/riscv: update multi-letter extension KVM properties We're now ready to update the multi-letter extensions status for KVM. kvm_riscv_update_cpu_cfg_isa_ext() is called called during vcpu creation time to verify which user options changes host defaults (via the 'user_set' flag) and tries to write them back to KVM. Failure to commit a change to KVM is only ignored in case KVM doesn't know about the extension (-EINVAL error code) and the user wanted to disable the given extension. Otherwise we're going to abort the boot process. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:36 +02:00
static void kvm_riscv_update_cpu_cfg_isa_ext(RISCVCPU *cpu, CPUState *cs)
{
CPURISCVState *env = &cpu->env;
uint64_t id, reg;
int i, ret;
for (i = 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) {
KVMCPUConfig *multi_ext_cfg = &kvm_multi_ext_cfgs[i];
if (!multi_ext_cfg->user_set) {
continue;
}
id = kvm_riscv_reg_id(env, KVM_REG_RISCV_ISA_EXT,
multi_ext_cfg->kvm_reg_id);
reg = kvm_cpu_cfg_get(cpu, multi_ext_cfg);
ret = kvm_set_one_reg(cs, id, &reg);
if (ret != 0) {
error_report("Unable to %s extension %s in KVM, error %d",
reg ? "enable" : "disable",
multi_ext_cfg->name, ret);
exit(EXIT_FAILURE);
}
}
}
target/riscv: add KVM specific MISA properties Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small impact since we just validating everything and error out if needed. But for KVM it would be good to know if a given value was set by the user or if it's a value already provided by KVM. Otherwise we don't know how to handle failed kvm_set_one_regs() when writing the configurations back. These characteristics make it overly complicated to use the same user facing flags for both KVM and TCG. A simpler approach is to create KVM specific properties that have specialized logic, forking KVM and TCG use cases for those cases only. Fully separating KVM/TCG properties is unneeded at this point - in fact we want the user experience to be as equal as possible, regardless of the acceleration chosen. We'll start this fork with the MISA properties, adding the MISA bits that the KVM driver currently supports. A new KVMCPUConfig type is introduced. It'll hold general information about an extension. For MISA extensions we're going to use the newly created getters of misa_ext_infos[] to populate their name and description. 'offset' holds the MISA bit (RVA, RVC, ...). We're calling it 'offset' instead of 'misa_bit' because this same KVMCPUConfig struct will be used to multi-letter extensions later on. This new type also holds a 'user_set' flag. This flag will be set when the user set an option that's different than what is already configured in the host, requiring KVM intervention to write the regs back during kvm_arch_init_vcpu(). Similar mechanics will be implemented for multi-letter extensions as well. There is no need to duplicate more code than necessary, so we're going to use the existing kvm_riscv_init_user_properties() to add the KVM specific properties. Any code that is adding a TCG user prop is then changed slightly to verify first if there's a KVM prop with the same name already added. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:30 +02:00
static void kvm_riscv_add_cpu_user_properties(Object *cpu_obj)
{
int i;
for (i = 0; i < ARRAY_SIZE(kvm_misa_ext_cfgs); i++) {
KVMCPUConfig *misa_cfg = &kvm_misa_ext_cfgs[i];
int bit = misa_cfg->offset;
misa_cfg->name = riscv_get_misa_ext_name(bit);
misa_cfg->description = riscv_get_misa_ext_description(bit);
object_property_add(cpu_obj, misa_cfg->name, "bool",
NULL,
kvm_cpu_set_misa_ext_cfg,
NULL, misa_cfg);
object_property_set_description(cpu_obj, misa_cfg->name,
misa_cfg->description);
}
target/riscv/kvm.c: add multi-letter extension KVM properties Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:32 +02:00
for (i = 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) {
KVMCPUConfig *multi_cfg = &kvm_multi_ext_cfgs[i];
object_property_add(cpu_obj, multi_cfg->name, "bool",
NULL,
kvm_cpu_set_multi_ext_cfg,
NULL, multi_cfg);
}
target/riscv: add KVM specific MISA properties Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small impact since we just validating everything and error out if needed. But for KVM it would be good to know if a given value was set by the user or if it's a value already provided by KVM. Otherwise we don't know how to handle failed kvm_set_one_regs() when writing the configurations back. These characteristics make it overly complicated to use the same user facing flags for both KVM and TCG. A simpler approach is to create KVM specific properties that have specialized logic, forking KVM and TCG use cases for those cases only. Fully separating KVM/TCG properties is unneeded at this point - in fact we want the user experience to be as equal as possible, regardless of the acceleration chosen. We'll start this fork with the MISA properties, adding the MISA bits that the KVM driver currently supports. A new KVMCPUConfig type is introduced. It'll hold general information about an extension. For MISA extensions we're going to use the newly created getters of misa_ext_infos[] to populate their name and description. 'offset' holds the MISA bit (RVA, RVC, ...). We're calling it 'offset' instead of 'misa_bit' because this same KVMCPUConfig struct will be used to multi-letter extensions later on. This new type also holds a 'user_set' flag. This flag will be set when the user set an option that's different than what is already configured in the host, requiring KVM intervention to write the regs back during kvm_arch_init_vcpu(). Similar mechanics will be implemented for multi-letter extensions as well. There is no need to duplicate more code than necessary, so we're going to use the existing kvm_riscv_init_user_properties() to add the KVM specific properties. Any code that is adding a TCG user prop is then changed slightly to verify first if there's a KVM prop with the same name already added. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:30 +02:00
}
target/riscv: Implement kvm_arch_get_registers Get GPR CSR and FP registers from kvm by KVM_GET_ONE_REG ioctl. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-5-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:20 +01:00
static int kvm_riscv_get_regs_core(CPUState *cs)
{
int ret = 0;
int i;
target_ulong reg;
CPURISCVState *env = &RISCV_CPU(cs)->env;
ret = kvm_get_one_reg(cs, RISCV_CORE_REG(env, regs.pc), &reg);
if (ret) {
return ret;
}
env->pc = reg;
for (i = 1; i < 32; i++) {
uint64_t id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CORE, i);
ret = kvm_get_one_reg(cs, id, &reg);
if (ret) {
return ret;
}
env->gpr[i] = reg;
}
return ret;
}
target/riscv: Implement kvm_arch_put_registers Put GPR CSR and FP registers to kvm by KVM_SET_ONE_REG ioctl Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-6-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:21 +01:00
static int kvm_riscv_put_regs_core(CPUState *cs)
{
int ret = 0;
int i;
target_ulong reg;
CPURISCVState *env = &RISCV_CPU(cs)->env;
reg = env->pc;
ret = kvm_set_one_reg(cs, RISCV_CORE_REG(env, regs.pc), &reg);
if (ret) {
return ret;
}
for (i = 1; i < 32; i++) {
uint64_t id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CORE, i);
reg = env->gpr[i];
ret = kvm_set_one_reg(cs, id, &reg);
if (ret) {
return ret;
}
}
return ret;
}
target/riscv: Implement kvm_arch_get_registers Get GPR CSR and FP registers from kvm by KVM_GET_ONE_REG ioctl. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-5-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:20 +01:00
static int kvm_riscv_get_regs_csr(CPUState *cs)
{
int ret = 0;
CPURISCVState *env = &RISCV_CPU(cs)->env;
KVM_RISCV_GET_CSR(cs, env, sstatus, env->mstatus);
KVM_RISCV_GET_CSR(cs, env, sie, env->mie);
KVM_RISCV_GET_CSR(cs, env, stvec, env->stvec);
KVM_RISCV_GET_CSR(cs, env, sscratch, env->sscratch);
KVM_RISCV_GET_CSR(cs, env, sepc, env->sepc);
KVM_RISCV_GET_CSR(cs, env, scause, env->scause);
KVM_RISCV_GET_CSR(cs, env, stval, env->stval);
KVM_RISCV_GET_CSR(cs, env, sip, env->mip);
KVM_RISCV_GET_CSR(cs, env, satp, env->satp);
return ret;
}
target/riscv: Implement kvm_arch_put_registers Put GPR CSR and FP registers to kvm by KVM_SET_ONE_REG ioctl Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-6-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:21 +01:00
static int kvm_riscv_put_regs_csr(CPUState *cs)
{
int ret = 0;
CPURISCVState *env = &RISCV_CPU(cs)->env;
KVM_RISCV_SET_CSR(cs, env, sstatus, env->mstatus);
KVM_RISCV_SET_CSR(cs, env, sie, env->mie);
KVM_RISCV_SET_CSR(cs, env, stvec, env->stvec);
KVM_RISCV_SET_CSR(cs, env, sscratch, env->sscratch);
KVM_RISCV_SET_CSR(cs, env, sepc, env->sepc);
KVM_RISCV_SET_CSR(cs, env, scause, env->scause);
KVM_RISCV_SET_CSR(cs, env, stval, env->stval);
KVM_RISCV_SET_CSR(cs, env, sip, env->mip);
KVM_RISCV_SET_CSR(cs, env, satp, env->satp);
return ret;
}
target/riscv: Implement kvm_arch_get_registers Get GPR CSR and FP registers from kvm by KVM_GET_ONE_REG ioctl. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-5-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:20 +01:00
static int kvm_riscv_get_regs_fp(CPUState *cs)
{
int ret = 0;
int i;
CPURISCVState *env = &RISCV_CPU(cs)->env;
if (riscv_has_ext(env, RVD)) {
uint64_t reg;
for (i = 0; i < 32; i++) {
ret = kvm_get_one_reg(cs, RISCV_FP_D_REG(env, i), &reg);
if (ret) {
return ret;
}
env->fpr[i] = reg;
}
return ret;
}
if (riscv_has_ext(env, RVF)) {
uint32_t reg;
for (i = 0; i < 32; i++) {
ret = kvm_get_one_reg(cs, RISCV_FP_F_REG(env, i), &reg);
if (ret) {
return ret;
}
env->fpr[i] = reg;
}
return ret;
}
return ret;
}
target/riscv: Implement kvm_arch_put_registers Put GPR CSR and FP registers to kvm by KVM_SET_ONE_REG ioctl Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-6-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:21 +01:00
static int kvm_riscv_put_regs_fp(CPUState *cs)
{
int ret = 0;
int i;
CPURISCVState *env = &RISCV_CPU(cs)->env;
if (riscv_has_ext(env, RVD)) {
uint64_t reg;
for (i = 0; i < 32; i++) {
reg = env->fpr[i];
ret = kvm_set_one_reg(cs, RISCV_FP_D_REG(env, i), &reg);
if (ret) {
return ret;
}
}
return ret;
}
if (riscv_has_ext(env, RVF)) {
uint32_t reg;
for (i = 0; i < 32; i++) {
reg = env->fpr[i];
ret = kvm_set_one_reg(cs, RISCV_FP_F_REG(env, i), &reg);
if (ret) {
return ret;
}
}
return ret;
}
return ret;
}
target/riscv: Add kvm_riscv_get/put_regs_timer Add kvm_riscv_get/put_regs_timer to synchronize virtual time context from KVM. To set register of RISCV_TIMER_REG(state) will occur a error from KVM on kvm_timer_state == 0. It's better to adapt in KVM, but it doesn't matter that adaping in QEMU. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-11-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:26 +01:00
static void kvm_riscv_get_regs_timer(CPUState *cs)
{
CPURISCVState *env = &RISCV_CPU(cs)->env;
if (env->kvm_timer_dirty) {
return;
}
KVM_RISCV_GET_TIMER(cs, env, time, env->kvm_timer_time);
KVM_RISCV_GET_TIMER(cs, env, compare, env->kvm_timer_compare);
KVM_RISCV_GET_TIMER(cs, env, state, env->kvm_timer_state);
KVM_RISCV_GET_TIMER(cs, env, frequency, env->kvm_timer_frequency);
env->kvm_timer_dirty = true;
}
static void kvm_riscv_put_regs_timer(CPUState *cs)
{
uint64_t reg;
CPURISCVState *env = &RISCV_CPU(cs)->env;
if (!env->kvm_timer_dirty) {
return;
}
KVM_RISCV_SET_TIMER(cs, env, time, env->kvm_timer_time);
KVM_RISCV_SET_TIMER(cs, env, compare, env->kvm_timer_compare);
/*
* To set register of RISCV_TIMER_REG(state) will occur a error from KVM
* on env->kvm_timer_state == 0, It's better to adapt in KVM, but it
* doesn't matter that adaping in QEMU now.
* TODO If KVM changes, adapt here.
*/
if (env->kvm_timer_state) {
KVM_RISCV_SET_TIMER(cs, env, state, env->kvm_timer_state);
}
/*
* For now, migration will not work between Hosts with different timer
* frequency. Therefore, we should check whether they are the same here
* during the migration.
*/
if (migration_is_running(migrate_get_current()->state)) {
KVM_RISCV_GET_TIMER(cs, env, frequency, reg);
if (reg != env->kvm_timer_frequency) {
error_report("Dst Hosts timer frequency != Src Hosts");
}
}
env->kvm_timer_dirty = false;
}
target/riscv: Implement kvm_arch_put_registers Put GPR CSR and FP registers to kvm by KVM_SET_ONE_REG ioctl Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-6-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:21 +01:00
target/riscv: use KVM scratch CPUs to init KVM properties Certain validations, such as the validations done for the machine IDs (mvendorid/marchid/mimpid), are done before starting the CPU. Non-dynamic (named) CPUs tries to match user input with a preset default. As it is today we can't prefetch a KVM default for these cases because we're only able to read/write KVM regs after the vcpu is spinning. Our target/arm friends use a concept called "scratch CPU", which consists of creating a vcpu for doing queries and validations and so on, which is discarded shortly after use [1]. This is a suitable solution for what we need so let's implement it in target/riscv as well. kvm_riscv_init_machine_ids() will be used to do any pre-launch setup for KVM CPUs, via riscv_cpu_add_user_properties(). The function will create a KVM scratch CPU, fetch KVM regs that work as default values for user properties, and then discard the scratch CPU afterwards. We're starting by initializing 'mvendorid'. This concept will be used to init other KVM specific properties in the next patches as well. [1] target/arm/kvm.c, kvm_arm_create_scratch_host_vcpu() Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:24 +02:00
typedef struct KVMScratchCPU {
int kvmfd;
int vmfd;
int cpufd;
} KVMScratchCPU;
/*
* Heavily inspired by kvm_arm_create_scratch_host_vcpu()
* from target/arm/kvm.c.
*/
static bool kvm_riscv_create_scratch_vcpu(KVMScratchCPU *scratch)
{
int kvmfd = -1, vmfd = -1, cpufd = -1;
kvmfd = qemu_open_old("/dev/kvm", O_RDWR);
if (kvmfd < 0) {
goto err;
}
do {
vmfd = ioctl(kvmfd, KVM_CREATE_VM, 0);
} while (vmfd == -1 && errno == EINTR);
if (vmfd < 0) {
goto err;
}
cpufd = ioctl(vmfd, KVM_CREATE_VCPU, 0);
if (cpufd < 0) {
goto err;
}
scratch->kvmfd = kvmfd;
scratch->vmfd = vmfd;
scratch->cpufd = cpufd;
return true;
err:
if (cpufd >= 0) {
close(cpufd);
}
if (vmfd >= 0) {
close(vmfd);
}
if (kvmfd >= 0) {
close(kvmfd);
}
return false;
}
static void kvm_riscv_destroy_scratch_vcpu(KVMScratchCPU *scratch)
{
close(scratch->cpufd);
close(scratch->vmfd);
close(scratch->kvmfd);
}
static void kvm_riscv_init_machine_ids(RISCVCPU *cpu, KVMScratchCPU *kvmcpu)
{
CPURISCVState *env = &cpu->env;
struct kvm_one_reg reg;
int ret;
reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
KVM_REG_RISCV_CONFIG_REG(mvendorid));
reg.addr = (uint64_t)&cpu->cfg.mvendorid;
ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, &reg);
if (ret != 0) {
error_report("Unable to retrieve mvendorid from host, error %d", ret);
}
target/riscv: read marchid/mimpid in kvm_riscv_init_machine_ids() Allow 'marchid' and 'mimpid' to also be initialized in kvm_riscv_init_machine_ids(). After this change, the handling of mvendorid/marchid/mimpid for the 'host' CPU type will be equal to what we already have for TCG named CPUs, i.e. the user is not able to set these values to a different val than the one that is already preset. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:25 +02:00
reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
KVM_REG_RISCV_CONFIG_REG(marchid));
reg.addr = (uint64_t)&cpu->cfg.marchid;
ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, &reg);
if (ret != 0) {
error_report("Unable to retrieve marchid from host, error %d", ret);
}
reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
KVM_REG_RISCV_CONFIG_REG(mimpid));
reg.addr = (uint64_t)&cpu->cfg.mimpid;
ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, &reg);
if (ret != 0) {
error_report("Unable to retrieve mimpid from host, error %d", ret);
}
target/riscv: use KVM scratch CPUs to init KVM properties Certain validations, such as the validations done for the machine IDs (mvendorid/marchid/mimpid), are done before starting the CPU. Non-dynamic (named) CPUs tries to match user input with a preset default. As it is today we can't prefetch a KVM default for these cases because we're only able to read/write KVM regs after the vcpu is spinning. Our target/arm friends use a concept called "scratch CPU", which consists of creating a vcpu for doing queries and validations and so on, which is discarded shortly after use [1]. This is a suitable solution for what we need so let's implement it in target/riscv as well. kvm_riscv_init_machine_ids() will be used to do any pre-launch setup for KVM CPUs, via riscv_cpu_add_user_properties(). The function will create a KVM scratch CPU, fetch KVM regs that work as default values for user properties, and then discard the scratch CPU afterwards. We're starting by initializing 'mvendorid'. This concept will be used to init other KVM specific properties in the next patches as well. [1] target/arm/kvm.c, kvm_arm_create_scratch_host_vcpu() Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:24 +02:00
}
target/riscv/kvm.c: init 'misa_ext_mask' with scratch CPU At this moment we're retrieving env->misa_ext during kvm_arch_init_cpu(), leaving env->misa_ext_mask behind. We want to set env->misa_ext_mask, and we want to set it as early as possible. The reason is that we're going to use it in the validation process of the KVM MISA properties we're going to add next. Setting it during arch_init_cpu() is too late for user validation. Move the code to a new helper that is going to be called during init() time, via kvm_riscv_init_user_properties(), like we're already doing for the machine ID properties. Set both misa_ext and misa_ext_mask to the same value retrieved by the 'isa' config reg. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:28 +02:00
static void kvm_riscv_init_misa_ext_mask(RISCVCPU *cpu,
KVMScratchCPU *kvmcpu)
{
CPURISCVState *env = &cpu->env;
struct kvm_one_reg reg;
int ret;
reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
KVM_REG_RISCV_CONFIG_REG(isa));
reg.addr = (uint64_t)&env->misa_ext_mask;
ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, &reg);
if (ret) {
error_report("Unable to fetch ISA register from KVM, "
"error %d", ret);
kvm_riscv_destroy_scratch_vcpu(kvmcpu);
exit(EXIT_FAILURE);
}
env->misa_ext = env->misa_ext_mask;
}
target/riscv/kvm.c: add multi-letter extension KVM properties Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:32 +02:00
static void kvm_riscv_init_multiext_cfg(RISCVCPU *cpu, KVMScratchCPU *kvmcpu)
{
CPURISCVState *env = &cpu->env;
uint64_t val;
int i, ret;
for (i = 0; i < ARRAY_SIZE(kvm_multi_ext_cfgs); i++) {
KVMCPUConfig *multi_ext_cfg = &kvm_multi_ext_cfgs[i];
struct kvm_one_reg reg;
reg.id = kvm_riscv_reg_id(env, KVM_REG_RISCV_ISA_EXT,
multi_ext_cfg->kvm_reg_id);
reg.addr = (uint64_t)&val;
ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, &reg);
if (ret != 0) {
if (errno == EINVAL) {
/* Silently default to 'false' if KVM does not support it. */
multi_ext_cfg->supported = false;
val = false;
} else {
error_report("Unable to read ISA_EXT KVM register %s, "
"error %d", multi_ext_cfg->name, ret);
kvm_riscv_destroy_scratch_vcpu(kvmcpu);
exit(EXIT_FAILURE);
}
} else {
multi_ext_cfg->supported = true;
}
kvm_cpu_cfg_set(cpu, multi_ext_cfg, val);
}
}
target/riscv: use KVM scratch CPUs to init KVM properties Certain validations, such as the validations done for the machine IDs (mvendorid/marchid/mimpid), are done before starting the CPU. Non-dynamic (named) CPUs tries to match user input with a preset default. As it is today we can't prefetch a KVM default for these cases because we're only able to read/write KVM regs after the vcpu is spinning. Our target/arm friends use a concept called "scratch CPU", which consists of creating a vcpu for doing queries and validations and so on, which is discarded shortly after use [1]. This is a suitable solution for what we need so let's implement it in target/riscv as well. kvm_riscv_init_machine_ids() will be used to do any pre-launch setup for KVM CPUs, via riscv_cpu_add_user_properties(). The function will create a KVM scratch CPU, fetch KVM regs that work as default values for user properties, and then discard the scratch CPU afterwards. We're starting by initializing 'mvendorid'. This concept will be used to init other KVM specific properties in the next patches as well. [1] target/arm/kvm.c, kvm_arm_create_scratch_host_vcpu() Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:24 +02:00
void kvm_riscv_init_user_properties(Object *cpu_obj)
{
RISCVCPU *cpu = RISCV_CPU(cpu_obj);
KVMScratchCPU kvmcpu;
if (!kvm_riscv_create_scratch_vcpu(&kvmcpu)) {
return;
}
target/riscv: add KVM specific MISA properties Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small impact since we just validating everything and error out if needed. But for KVM it would be good to know if a given value was set by the user or if it's a value already provided by KVM. Otherwise we don't know how to handle failed kvm_set_one_regs() when writing the configurations back. These characteristics make it overly complicated to use the same user facing flags for both KVM and TCG. A simpler approach is to create KVM specific properties that have specialized logic, forking KVM and TCG use cases for those cases only. Fully separating KVM/TCG properties is unneeded at this point - in fact we want the user experience to be as equal as possible, regardless of the acceleration chosen. We'll start this fork with the MISA properties, adding the MISA bits that the KVM driver currently supports. A new KVMCPUConfig type is introduced. It'll hold general information about an extension. For MISA extensions we're going to use the newly created getters of misa_ext_infos[] to populate their name and description. 'offset' holds the MISA bit (RVA, RVC, ...). We're calling it 'offset' instead of 'misa_bit' because this same KVMCPUConfig struct will be used to multi-letter extensions later on. This new type also holds a 'user_set' flag. This flag will be set when the user set an option that's different than what is already configured in the host, requiring KVM intervention to write the regs back during kvm_arch_init_vcpu(). Similar mechanics will be implemented for multi-letter extensions as well. There is no need to duplicate more code than necessary, so we're going to use the existing kvm_riscv_init_user_properties() to add the KVM specific properties. Any code that is adding a TCG user prop is then changed slightly to verify first if there's a KVM prop with the same name already added. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:30 +02:00
kvm_riscv_add_cpu_user_properties(cpu_obj);
target/riscv: use KVM scratch CPUs to init KVM properties Certain validations, such as the validations done for the machine IDs (mvendorid/marchid/mimpid), are done before starting the CPU. Non-dynamic (named) CPUs tries to match user input with a preset default. As it is today we can't prefetch a KVM default for these cases because we're only able to read/write KVM regs after the vcpu is spinning. Our target/arm friends use a concept called "scratch CPU", which consists of creating a vcpu for doing queries and validations and so on, which is discarded shortly after use [1]. This is a suitable solution for what we need so let's implement it in target/riscv as well. kvm_riscv_init_machine_ids() will be used to do any pre-launch setup for KVM CPUs, via riscv_cpu_add_user_properties(). The function will create a KVM scratch CPU, fetch KVM regs that work as default values for user properties, and then discard the scratch CPU afterwards. We're starting by initializing 'mvendorid'. This concept will be used to init other KVM specific properties in the next patches as well. [1] target/arm/kvm.c, kvm_arm_create_scratch_host_vcpu() Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:24 +02:00
kvm_riscv_init_machine_ids(cpu, &kvmcpu);
target/riscv/kvm.c: init 'misa_ext_mask' with scratch CPU At this moment we're retrieving env->misa_ext during kvm_arch_init_cpu(), leaving env->misa_ext_mask behind. We want to set env->misa_ext_mask, and we want to set it as early as possible. The reason is that we're going to use it in the validation process of the KVM MISA properties we're going to add next. Setting it during arch_init_cpu() is too late for user validation. Move the code to a new helper that is going to be called during init() time, via kvm_riscv_init_user_properties(), like we're already doing for the machine ID properties. Set both misa_ext and misa_ext_mask to the same value retrieved by the 'isa' config reg. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:28 +02:00
kvm_riscv_init_misa_ext_mask(cpu, &kvmcpu);
target/riscv/kvm.c: add multi-letter extension KVM properties Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:32 +02:00
kvm_riscv_init_multiext_cfg(cpu, &kvmcpu);
target/riscv: use KVM scratch CPUs to init KVM properties Certain validations, such as the validations done for the machine IDs (mvendorid/marchid/mimpid), are done before starting the CPU. Non-dynamic (named) CPUs tries to match user input with a preset default. As it is today we can't prefetch a KVM default for these cases because we're only able to read/write KVM regs after the vcpu is spinning. Our target/arm friends use a concept called "scratch CPU", which consists of creating a vcpu for doing queries and validations and so on, which is discarded shortly after use [1]. This is a suitable solution for what we need so let's implement it in target/riscv as well. kvm_riscv_init_machine_ids() will be used to do any pre-launch setup for KVM CPUs, via riscv_cpu_add_user_properties(). The function will create a KVM scratch CPU, fetch KVM regs that work as default values for user properties, and then discard the scratch CPU afterwards. We're starting by initializing 'mvendorid'. This concept will be used to init other KVM specific properties in the next patches as well. [1] target/arm/kvm.c, kvm_arm_create_scratch_host_vcpu() Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:24 +02:00
kvm_riscv_destroy_scratch_vcpu(&kvmcpu);
}
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
KVM_CAP_LAST_INFO
};
int kvm_arch_get_registers(CPUState *cs)
{
target/riscv: Implement kvm_arch_get_registers Get GPR CSR and FP registers from kvm by KVM_GET_ONE_REG ioctl. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-5-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:20 +01:00
int ret = 0;
ret = kvm_riscv_get_regs_core(cs);
if (ret) {
return ret;
}
ret = kvm_riscv_get_regs_csr(cs);
if (ret) {
return ret;
}
ret = kvm_riscv_get_regs_fp(cs);
if (ret) {
return ret;
}
return ret;
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
}
int kvm_arch_put_registers(CPUState *cs, int level)
{
target/riscv: Implement kvm_arch_put_registers Put GPR CSR and FP registers to kvm by KVM_SET_ONE_REG ioctl Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-6-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:21 +01:00
int ret = 0;
ret = kvm_riscv_put_regs_core(cs);
if (ret) {
return ret;
}
ret = kvm_riscv_put_regs_csr(cs);
if (ret) {
return ret;
}
ret = kvm_riscv_put_regs_fp(cs);
if (ret) {
return ret;
}
return ret;
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
}
int kvm_arch_release_virq_post(int virq)
{
return 0;
}
int kvm_arch_fixup_msi_route(struct kvm_irq_routing_entry *route,
uint64_t address, uint32_t data, PCIDevice *dev)
{
return 0;
}
int kvm_arch_destroy_vcpu(CPUState *cs)
{
return 0;
}
unsigned long kvm_arch_vcpu_id(CPUState *cpu)
{
return cpu->cpu_index;
}
target/riscv: Implement virtual time adjusting with vm state changing We hope that virtual time adjusts with vm state changing. When a vm is stopped, guest virtual time should stop counting and kvm_timer should be stopped. When the vm is resumed, guest virtual time should continue to count and kvm_timer should be restored. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-12-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:27 +01:00
static void kvm_riscv_vm_state_change(void *opaque, bool running,
RunState state)
{
CPUState *cs = opaque;
if (running) {
kvm_riscv_put_regs_timer(cs);
} else {
kvm_riscv_get_regs_timer(cs);
}
}
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
void kvm_arch_init_irq_routing(KVMState *s)
{
}
target/riscv: handle mvendorid/marchid/mimpid for KVM CPUs After changing user validation for mvendorid/marchid/mimpid to guarantee that the value is validated on user input time, coupled with the work in fetching KVM default values for them by using a scratch CPU, we're certain that the values in cpu->cfg.(mvendorid|marchid|mimpid) are already good to be written back to KVM. There's no need to write the values back for 'host' type CPUs since the values can't be changed, so let's do that just for generic CPUs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:26 +02:00
static int kvm_vcpu_set_machine_ids(RISCVCPU *cpu, CPUState *cs)
{
CPURISCVState *env = &cpu->env;
uint64_t id;
int ret;
id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
KVM_REG_RISCV_CONFIG_REG(mvendorid));
ret = kvm_set_one_reg(cs, id, &cpu->cfg.mvendorid);
if (ret != 0) {
return ret;
}
id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
KVM_REG_RISCV_CONFIG_REG(marchid));
ret = kvm_set_one_reg(cs, id, &cpu->cfg.marchid);
if (ret != 0) {
return ret;
}
id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG,
KVM_REG_RISCV_CONFIG_REG(mimpid));
ret = kvm_set_one_reg(cs, id, &cpu->cfg.mimpid);
return ret;
}
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
int kvm_arch_init_vcpu(CPUState *cs)
{
target/riscv: Implement function kvm_arch_init_vcpu Get isa info from kvm while kvm init. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-4-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:19 +01:00
int ret = 0;
RISCVCPU *cpu = RISCV_CPU(cs);
target/riscv: Implement virtual time adjusting with vm state changing We hope that virtual time adjusts with vm state changing. When a vm is stopped, guest virtual time should stop counting and kvm_timer should be stopped. When the vm is resumed, guest virtual time should continue to count and kvm_timer should be restored. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-12-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:27 +01:00
qemu_add_vm_change_state_handler(kvm_riscv_vm_state_change, cs);
target/riscv: handle mvendorid/marchid/mimpid for KVM CPUs After changing user validation for mvendorid/marchid/mimpid to guarantee that the value is validated on user input time, coupled with the work in fetching KVM default values for them by using a scratch CPU, we're certain that the values in cpu->cfg.(mvendorid|marchid|mimpid) are already good to be written back to KVM. There's no need to write the values back for 'host' type CPUs since the values can't be changed, so let's do that just for generic CPUs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:26 +02:00
if (!object_dynamic_cast(OBJECT(cpu), TYPE_RISCV_CPU_HOST)) {
ret = kvm_vcpu_set_machine_ids(cpu, cs);
target/riscv/kvm.c: update KVM MISA bits 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. In the case of MISA bits we won't even try enabling bits that aren't already available in the host. The ioctl() is so likely to fail that it'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. Error out if anything goes wrong. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:31 +02:00
if (ret != 0) {
return ret;
}
target/riscv: handle mvendorid/marchid/mimpid for KVM CPUs After changing user validation for mvendorid/marchid/mimpid to guarantee that the value is validated on user input time, coupled with the work in fetching KVM default values for them by using a scratch CPU, we're certain that the values in cpu->cfg.(mvendorid|marchid|mimpid) are already good to be written back to KVM. There's no need to write the values back for 'host' type CPUs since the values can't be changed, so let's do that just for generic CPUs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:26 +02:00
}
target/riscv/kvm.c: update KVM MISA bits 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. In the case of MISA bits we won't even try enabling bits that aren't already available in the host. The ioctl() is so likely to fail that it'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. Error out if anything goes wrong. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:31 +02:00
kvm_riscv_update_cpu_misa_ext(cpu, cs);
target/riscv: update multi-letter extension KVM properties We're now ready to update the multi-letter extensions status for KVM. kvm_riscv_update_cpu_cfg_isa_ext() is called called during vcpu creation time to verify which user options changes host defaults (via the 'user_set' flag) and tries to write them back to KVM. Failure to commit a change to KVM is only ignored in case KVM doesn't know about the extension (-EINVAL error code) and the user wanted to disable the given extension. Otherwise we're going to abort the boot process. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:36 +02:00
kvm_riscv_update_cpu_cfg_isa_ext(cpu, cs);
target/riscv/kvm.c: update KVM MISA bits 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. In the case of MISA bits we won't even try enabling bits that aren't already available in the host. The ioctl() is so likely to fail that it'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. Error out if anything goes wrong. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 12:17:31 +02:00
target/riscv: Implement function kvm_arch_init_vcpu Get isa info from kvm while kvm init. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-4-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:19 +01:00
return ret;
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
}
int kvm_arch_msi_data_to_gsi(uint32_t data)
{
abort();
}
int kvm_arch_add_msi_route_post(struct kvm_irq_routing_entry *route,
int vector, PCIDevice *dev)
{
return 0;
}
int kvm_arch_init(MachineState *ms, KVMState *s)
{
return 0;
}
int kvm_arch_irqchip_create(KVMState *s)
{
return 0;
}
int kvm_arch_process_async_events(CPUState *cs)
{
return 0;
}
void kvm_arch_pre_run(CPUState *cs, struct kvm_run *run)
{
}
MemTxAttrs kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
{
return MEMTXATTRS_UNSPECIFIED;
}
bool kvm_arch_stop_on_emulation_error(CPUState *cs)
{
return true;
}
target/riscv: Handle KVM_EXIT_RISCV_SBI exit Use char-fe to handle console sbi call, which implement early console io while apply 'earlycon=sbi' into kernel parameters. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-9-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:24 +01:00
static int kvm_riscv_handle_sbi(CPUState *cs, struct kvm_run *run)
{
int ret = 0;
unsigned char ch;
switch (run->riscv_sbi.extension_id) {
case SBI_EXT_0_1_CONSOLE_PUTCHAR:
ch = run->riscv_sbi.args[0];
qemu_chr_fe_write(serial_hd(0)->be, &ch, sizeof(ch));
break;
case SBI_EXT_0_1_CONSOLE_GETCHAR:
ret = qemu_chr_fe_read_all(serial_hd(0)->be, &ch, sizeof(ch));
if (ret == sizeof(ch)) {
target/riscv: fix SBI getchar handler for KVM Character must be returned via ret[0] field (copied to a0 by KVM). Return value should be set to 0 to indicate successful processing. Signed-off-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230203135155.12449-1-vladimir.isaev@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-03 14:51:55 +01:00
run->riscv_sbi.ret[0] = ch;
target/riscv: Handle KVM_EXIT_RISCV_SBI exit Use char-fe to handle console sbi call, which implement early console io while apply 'earlycon=sbi' into kernel parameters. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-9-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:24 +01:00
} else {
target/riscv: fix SBI getchar handler for KVM Character must be returned via ret[0] field (copied to a0 by KVM). Return value should be set to 0 to indicate successful processing. Signed-off-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230203135155.12449-1-vladimir.isaev@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-03 14:51:55 +01:00
run->riscv_sbi.ret[0] = -1;
target/riscv: Handle KVM_EXIT_RISCV_SBI exit Use char-fe to handle console sbi call, which implement early console io while apply 'earlycon=sbi' into kernel parameters. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-9-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:24 +01:00
}
target/riscv: fix SBI getchar handler for KVM Character must be returned via ret[0] field (copied to a0 by KVM). Return value should be set to 0 to indicate successful processing. Signed-off-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230203135155.12449-1-vladimir.isaev@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-02-03 14:51:55 +01:00
ret = 0;
target/riscv: Handle KVM_EXIT_RISCV_SBI exit Use char-fe to handle console sbi call, which implement early console io while apply 'earlycon=sbi' into kernel parameters. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-9-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:24 +01:00
break;
default:
qemu_log_mask(LOG_UNIMP,
"%s: un-handled SBI EXIT, specific reasons is %lu\n",
__func__, run->riscv_sbi.extension_id);
ret = -1;
break;
}
return ret;
}
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
{
target/riscv: Handle KVM_EXIT_RISCV_SBI exit Use char-fe to handle console sbi call, which implement early console io while apply 'earlycon=sbi' into kernel parameters. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220112081329.1835-9-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:24 +01:00
int ret = 0;
switch (run->exit_reason) {
case KVM_EXIT_RISCV_SBI:
ret = kvm_riscv_handle_sbi(cs, run);
break;
default:
qemu_log_mask(LOG_UNIMP, "%s: un-handled exit reason %d\n",
__func__, run->exit_reason);
ret = -1;
break;
}
return ret;
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
}
target/riscv: Support start kernel directly by KVM Get kernel and fdt start address in virt.c, and pass them to KVM when cpu reset. Add kvm_riscv.h to place riscv specific interface. In addition, PLIC is created without M-mode PLIC contexts when KVM is enabled. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup@brainfault.org> Message-id: 20220112081329.1835-7-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:22 +01:00
void kvm_riscv_reset_vcpu(RISCVCPU *cpu)
{
CPURISCVState *env = &cpu->env;
if (!kvm_enabled()) {
return;
}
env->pc = cpu->env.kernel_addr;
env->gpr[10] = kvm_arch_vcpu_id(CPU(cpu)); /* a0 */
env->gpr[11] = cpu->env.fdt_addr; /* a1 */
env->satp = 0;
}
target/riscv: Support setting external interrupt by KVM When KVM is enabled, set the S-mode external interrupt through kvm_riscv_set_irq function. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-8-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:23 +01:00
void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level)
{
int ret;
unsigned virq = level ? KVM_INTERRUPT_SET : KVM_INTERRUPT_UNSET;
if (irq != IRQ_S_EXT) {
perror("kvm riscv set irq != IRQ_S_EXT\n");
abort();
}
ret = kvm_vcpu_ioctl(CPU(cpu), KVM_INTERRUPT, &virq);
if (ret < 0) {
perror("Set irq failed");
abort();
}
}
target/riscv: Add target/riscv/kvm.c to place the public kvm interface Add target/riscv/kvm.c to place kvm_arch_* function needed by kvm/kvm-all.c. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Mingwang Li <limingwang@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Anup Patel <anup.patel@wdc.com> Message-id: 20220112081329.1835-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 09:13:18 +01:00
bool kvm_arch_cpu_check_are_resettable(void)
{
return true;
}
kvm: allow target-specific accelerator properties Several hypervisor capabilities in KVM are target-specific. When exposed to QEMU users as accelerator properties (i.e. -accel kvm,prop=value), they should not be available for all targets. Add a hook for targets to add their own properties to -accel kvm, for now no such property is defined. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20220929072014.20705-3-chenyi.qiang@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-09-29 09:20:12 +02:00
void kvm_arch_accel_class_init(ObjectClass *oc)
{
}
Reference in New Issue Copy Permalink