aboutsummaryrefslogtreecommitdiff
path: root/target/riscv/kvm.c
AgeCommit message (Collapse)Author
2023-11-19target/riscv/kvm: support KVM_GET_REG_LISTDaniel Henrique Barboza
KVM for RISC-V started supporting KVM_GET_REG_LIST in Linux 6.6. It consists of a KVM ioctl() that retrieves a list of all available regs for get_one_reg/set_one_reg. Regs that aren't present in the list aren't supported in the host. This simplifies our lives when initing the KVM regs since we don't have to always attempt a KVM_GET_ONE_REG for all regs QEMU knows. We'll only attempt a get_one_reg() if we're sure the reg is supported, i.e. it was retrieved by KVM_GET_REG_LIST. Any error in get_one_reg() will then always considered fatal, instead of having to handle special error codes that might indicate a non-fatal failure. Start by moving the current kvm_riscv_init_multiext_cfg() logic into a new kvm_riscv_read_multiext_legacy() helper. We'll prioritize using KVM_GET_REG_LIST, so check if we have it available and, in case we don't, use the legacy() logic. Otherwise, retrieve the available reg list and use it to check if the host supports our known KVM regs, doing the usual get_one_reg() for the supported regs and setting cpu->cfg accordingly. 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: <20231003132148.797921-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 608bdebb6075b757e5505f6bbc60c45a54a1390b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: trivial context tweak in target/riscv/kvm.c)
2023-11-19target/riscv/kvm: improve 'init_multiext_cfg' error msgDaniel Henrique Barboza
Our error message is returning the value of 'ret', which will be always -1 in case of error, and will not be that useful: qemu-system-riscv64: Unable to read ISA_EXT KVM register ssaia, error -1 Improve the error message by outputting 'errno' instead of 'ret'. Use strerrorname_np() to output the error name instead of the error code. This will give us what we need to know right away: qemu-system-riscv64: Unable to read ISA_EXT KVM register ssaia, error code: ENOENT Given that we're going to exit(1) in this condition instead of attempting to recover, remove the 'kvm_riscv_destroy_scratch_vcpu()' call. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20231003132148.797921-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 082e9e4a58ba80ec056220a2f762a1c6b9a3a96c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-24kvm: Introduce kvm_arch_get_default_type hookAkihiko Odaki
kvm_arch_get_default_type() returns the default KVM type. This hook is particularly useful to derive a KVM type that is valid for "none" machine model, which is used by libvirt to probe the availability of KVM. For MIPS, the existing mips_kvm_type() is reused. This function ensures the availability of VZ which is mandatory to use KVM on the current QEMU. Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20230727073134.134102-2-akihiko.odaki@daynix.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added doc comment for new function] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 5e0d65909c6f335d578b90491e165440c99adf81) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-08-11target/riscv/kvm.c: fix mvendorid size in vcpu_set_machine_ids()Daniel Henrique Barboza
cpu->cfg.mvendorid is a 32 bit field and kvm_set_one_reg() always write a target_ulong val, i.e. a 64 bit field in a 64 bit host. Given that we're passing a pointer to the mvendorid field, the reg is reading 64 bits starting from mvendorid and going 32 bits in the next field, marchid. Here's an example: $ ./qemu-system-riscv64 -machine virt,accel=kvm -m 2G -smp 1 \ -cpu rv64,marchid=0xab,mvendorid=0xcd,mimpid=0xef(...) (inside the guest) # cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc_zicbom_zicboz_zihintpause_zbb_sstc mmu : sv57 mvendorid : 0xab000000cd marchid : 0xab mimpid : 0xef 'mvendorid' was written as a combination of 0xab (the value from the adjacent field, marchid) and its intended value 0xcd. Fix it by assigning cpu->cfg.mvendorid to a target_ulong var 'reg' and use it as input for kvm_set_one_reg(). Here's the result with this patch applied and using the same QEMU command line: # cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc_zicbom_zicboz_zihintpause_zbb_sstc mmu : sv57 mvendorid : 0xcd marchid : 0xab mimpid : 0xef This bug affects only the generic (rv64) CPUs when running with KVM in a 64 bit env since the 'host' CPU does not allow the machine IDs to be changed via command line. Fixes: 1fb5a622f7 ("target/riscv: handle mvendorid/marchid/mimpid for KVM CPUs") 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: <20230802180058.281385-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/kvm.c: read/write (cbom|cboz)_blocksize in KVMDaniel Henrique Barboza
If we don't set a proper cbom_blocksize|cboz_blocksize in the FDT the Linux Kernel will fail to detect the availability of the CBOM/CBOZ extensions, regardless of the contents of the 'riscv,isa' DT prop. The FDT is being written using the cpu->cfg.cbom|z_blocksize attributes, so let's expose them as user properties like it is already done with TCG. This will also require us to determine proper blocksize values during init() time since the FDT is already created during realize(). We'll take a ride in kvm_riscv_init_multiext_cfg() to do it. Note that we don't need to fetch both cbom and cboz blocksizes every time: check for their parent extensions (icbom and icboz) and only read the blocksizes if needed. In contrast with cbom|z_blocksize properties from TCG, the user is not able to set any value that is different from the 'host' value when running KVM. KVM can be particularly harsh dealing with it: a ENOTSUPP can be thrown for the mere attempt of executing kvm_set_one_reg() for these 2 regs. Hopefully we don't need to call kvm_set_one_reg() for these regs. We'll check if the user input matches the host value in kvm_cpu_set_cbomz_blksize(), the set() accessor for both blocksize properties. We'll fail fast since it's already known to not be supported. 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-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/kvm.c: add kvmconfig_get_cfg_addr() helperDaniel Henrique Barboza
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-10target/riscv: update multi-letter extension KVM propertiesDaniel Henrique Barboza
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-10target/riscv/kvm.c: add multi-letter extension KVM propertiesDaniel Henrique Barboza
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-10target/riscv/kvm.c: update KVM MISA bitsDaniel Henrique Barboza
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-10target/riscv: add KVM specific MISA propertiesDaniel Henrique Barboza
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-10target/riscv/kvm.c: init 'misa_ext_mask' with scratch CPUDaniel Henrique Barboza
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-10target/riscv: handle mvendorid/marchid/mimpid for KVM CPUsDaniel Henrique Barboza
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-10target/riscv: read marchid/mimpid in kvm_riscv_init_machine_ids()Daniel Henrique Barboza
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-10target/riscv: use KVM scratch CPUs to init KVM propertiesDaniel Henrique Barboza
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-10target/riscv KVM_RISCV_SET_TIMER macro is not configured correctlyyang.zhang
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-02-07target/riscv: fix SBI getchar handler for KVMVladimir Isaev
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>
2022-10-10kvm: allow target-specific accelerator propertiesPaolo Bonzini
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-04-06Remove qemu-common.h include from most unitsMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20220323155743.1585078-33-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2022-01-21target/riscv: Implement virtual time adjusting with vm state changingYifei Jiang
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-21target/riscv: Add kvm_riscv_get/put_regs_timerYifei Jiang
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-21target/riscv: Handle KVM_EXIT_RISCV_SBI exitYifei Jiang
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-21target/riscv: Support setting external interrupt by KVMYifei Jiang
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-21target/riscv: Support start kernel directly by KVMYifei Jiang
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-21target/riscv: Implement kvm_arch_put_registersYifei Jiang
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-21target/riscv: Implement kvm_arch_get_registersYifei Jiang
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-21target/riscv: Implement function kvm_arch_init_vcpuYifei Jiang
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-21target/riscv: Add target/riscv/kvm.c to place the public kvm interfaceYifei Jiang
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>