mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e7443334a8
qemu/target/riscv/cpu.c

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

2040 lines
64 KiB
C
Raw Normal View History

RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
/*
* QEMU RISC-V CPU
*
* Copyright (c) 2016-2017 Sagar Karandikar, sagark@eecs.berkeley.edu
* Copyright (c) 2017-2018 SiFive, Inc.
*
* 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"
target: Simplify how the TARGET_cpu_list() print The various TARGET_cpu_list() take an fprintf()-like callback and a FILE * to pass to it. Their callers (vl.c's main() via list_cpus(), bsd-user/main.c's main(), linux-user/main.c's main()) all pass fprintf() and stdout. Thus, the flexibility provided by the (rather tiresome) indirection isn't actually used. Drop the callback, and call qemu_printf() instead. Calling printf() would also work, but would make the code unsuitable for monitor context without making it simpler. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190417191805.28198-10-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-04-17 22:17:57 +03:00
#include "qemu/qemu-print.h"
qemu-common: Move qemu_isalnum() etc. to qemu/ctype.h Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-3-armbru@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-05-23 17:35:06 +03:00
#include "qemu/ctype.h"
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#include "qemu/log.h"
#include "cpu.h"
RISC-V: Add initial support for T-Head C906 This patch adds the T-Head C906 to the list of known CPUs. Selecting this CPUs will automatically enable the available ISA extensions of the CPUs (incl. vendor extensions). Co-developed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230131202013.2541053-13-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-01-31 23:20:11 +03:00
#include "cpu_vendorid.h"
target/riscv: Add basic vmstate description of CPU Add basic CPU state description to the newly created machine.c Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Yipeng Yin <yinyipeng1@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20201026115530.304-3-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-10-26 14:55:26 +03:00
#include "internals.h"
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#include "exec/exec-all.h"
#include "qapi/error.h"
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
#include "qapi/visitor.h"
target/riscv: Allow setting ISA extensions via CPU props This patch allows us to enable/disable the RISC-V ISA extensions from the QEMU command line. This works with the rv32 and rv64 machines. The idea is that in the future we can now add extensions and leave them disabled by default until enabled by the user. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-05-07 01:49:53 +03:00
#include "qemu/error-report.h"
target/riscv: Create settable CPU properties Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-04-20 05:24:01 +03:00
#include "hw/qdev-properties.h"
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#include "migration/vmstate.h"
target/riscv: rationalise softfloat includes We should avoid including the whole of softfloat headers in cpu.h and explicitly include it only where we will be calling softfloat functions. We can use the -types.h and -helpers.h in cpu.h for the few bits that are global. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Palmer Dabbelt <palmer@sifive.com>
2019-08-08 19:29:41 +03:00
#include "fpu/softfloat-helpers.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 11:13:22 +03:00
#include "sysemu/kvm.h"
target/riscv: skip features setup for KVM CPUs As it is today it's not possible to use '-cpu host' if the RISC-V host has RVH enabled. This is the resulting error: $ ./qemu/build/qemu-system-riscv64 \ -machine virt,accel=kvm -m 2G -smp 1 \ -nographic -snapshot -kernel ./guest_imgs/Image \ -initrd ./guest_imgs/rootfs_kvm_riscv64.img \ -append "earlycon=sbi root=/dev/ram rw" \ -cpu host qemu-system-riscv64: H extension requires priv spec 1.12.0 This happens because we're checking for priv spec for all CPUs, and since we're not setting env->priv_ver for the 'host' CPU, it's being default to zero (i.e. PRIV_SPEC_1_10_0). In reality env->priv_ver does not make sense when running with the KVM 'host' CPU. It's used to gate certain CSRs/extensions during translation to make them unavailable if the hart declares an older spec version. It doesn't have any other use. E.g. OpenSBI version 1.2 retrieves the spec checking if the CSR_MCOUNTEREN, CSR_MCOUNTINHIBIT and CSR_MENVCFG CSRs are available [1]. 'priv_ver' is just one example. We're doing a lot of feature validation and setup during riscv_cpu_realize() that it doesn't apply to KVM CPUs. Validating the feature set for those CPUs is a KVM problem that should be handled in KVM specific code. The new riscv_cpu_realize_tcg() helper contains all validation logic that are applicable to TCG CPUs only. riscv_cpu_realize() verifies if we're running TCG and, if it's the case, proceed with the usual TCG realize() logic. [1] lib/sbi/sbi_hart.c, hart_detect_features() 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-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:19 +03:00
#include "sysemu/tcg.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 11:13:22 +03:00
#include "kvm_riscv.h"
target/riscv: Replace `tb_pc()` with `tb->pc` Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230227135202.9710-18-anjo@rev.ng> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-02-27 16:51:52 +03:00
#include "tcg/tcg.h"
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
/* RISC-V CPU definitions */
target/riscv: misa to ISA string conversion fix Some bits in RISC-V `misa' CSR should not be reflected in the ISA string. For instance, `S' and `U' (represents existence of supervisor and user mode, respectively) in `misa' CSR must not be copied since neither `S' nor `U' are valid single-letter extensions. This commit also removes all reserved/dropped single-letter "extensions" from the list. - "B": Not going to be a single-letter extension (misa.B is reserved). - "J": Not going to be a single-letter extension (misa.J is reserved). - "K": Not going to be a single-letter extension (misa.K is reserved). - "L": Dropped. - "N": Dropped. - "T": Dropped. It also clarifies that the variable `riscv_single_letter_exts' is a single-letter extension order list. Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <4a4c11213a161a7eedabe46abe58b351bb0e2ef2.1648473008.git.research_trasio@irq.a4lg.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-03-28 16:11:23 +03:00
static const char riscv_single_letter_exts[] = "IEMAFDQCPVH";
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
target/riscv: Add isa extenstion strings to the device tree The Linux kernel parses the ISA extensions from "riscv,isa" DT property. It used to parse only the single letter base extensions until now. A generic ISA extension parsing framework was proposed[1] recently that can parse multi-letter ISA extensions as well. Generate the extended ISA string by appending the available ISA extensions to the "riscv,isa" string if it is enabled so that kernel can process it. [1] https://lkml.org/lkml/2022/2/15/263 Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Suggested-by: Heiko Stubner <heiko@sntech.de> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-Id: <20220329195657.1725425-1-atishp@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-03-29 22:56:57 +03:00
struct isa_ext_data {
const char *name;
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
int min_version;
int ext_enable_offset;
target/riscv: Add isa extenstion strings to the device tree The Linux kernel parses the ISA extensions from "riscv,isa" DT property. It used to parse only the single letter base extensions until now. A generic ISA extension parsing framework was proposed[1] recently that can parse multi-letter ISA extensions as well. Generate the extended ISA string by appending the available ISA extensions to the "riscv,isa" string if it is enabled so that kernel can process it. [1] https://lkml.org/lkml/2022/2/15/263 Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Suggested-by: Heiko Stubner <heiko@sntech.de> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-Id: <20220329195657.1725425-1-atishp@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-03-29 22:56:57 +03:00
};
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
#define ISA_EXT_DATA_ENTRY(_name, _min_ver, _prop) \
target/riscv: make CPUCFG() macro public The RISC-V KVM driver uses a CPUCFG() macro that calculates the offset of a certain field in the struct RISCVCPUConfig. We're going to use this macro in target/riscv/cpu.c as well in the next patches. Make it public. Rename it to CPU_CFG_OFFSET() for more clarity while we're at it. 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: <20230912132423.268494-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:17 +03:00
{#_name, _min_ver, CPU_CFG_OFFSET(_prop)}
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
target/riscv: Add RVV registers to log Print RvV extension register to log if VPU option is enabled. Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230629083730.386604-1-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-29 11:37:30 +03:00
/*
* From vector_helper.c
* Note that vector data is stored in host-endian 64-bit chunks,
* so addressing bytes needs a host-endian fixup.
*/
#if HOST_BIG_ENDIAN
#define BYTE(x) ((x) ^ 7)
#else
#define BYTE(x) (x)
#endif
target/riscv: Fix format for comments Fix formats for multi-lines comments. Add spaces around single line comments(after "/*" and before "*/"). Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Acked-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230405085813.40643-4-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-05 11:58:12 +03:00
/*
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
* Here are the ordering rules of extension naming defined by RISC-V
* specification :
* 1. All extensions should be separated from other multi-letter extensions
* by an underscore.
* 2. The first letter following the 'Z' conventionally indicates the most
* closely related alphabetical extension category, IMAFDQLCBKJTPVH.
* If multiple 'Z' extensions are named, they should be ordered first
* by category, then alphabetically within a category.
* 3. Standard supervisor-level extensions (starts with 'S') should be
* listed after standard unprivileged extensions. If multiple
* supervisor-level extensions are listed, they should be ordered
* alphabetically.
* 4. Non-standard extensions (starts with 'X') must be listed after all
* standard extensions. They must be separated from other multi-letter
* extensions by an underscore.
target/riscv: remove MISA properties from isa_edata_arr[] The code that disables extensions if there's a priv version mismatch uses cpu->cfg.ext_N properties to do its job. We're aiming to not rely on cpu->cfg.ext_N props for MISA bits. Split the MISA related verifications in a new function, removing it from isa_edata_arr[]. We're also erroring it out instead of disabling, making the cpu_init() function responsible for running an adequate priv spec for the MISA extensions it wants to use. Note that the RVV verification is being ignored since we're always have at least PRIV_VERSION_1_10_0. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:33 +03:00
*
* Single letter extensions are checked in riscv_cpu_validate_misa_priv()
* instead.
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
*/
static const struct isa_ext_data isa_edata_arr[] = {
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
ISA_EXT_DATA_ENTRY(zicbom, PRIV_VERSION_1_12_0, ext_icbom),
ISA_EXT_DATA_ENTRY(zicboz, PRIV_VERSION_1_12_0, ext_icboz),
ISA_EXT_DATA_ENTRY(zicond, PRIV_VERSION_1_12_0, ext_zicond),
ISA_EXT_DATA_ENTRY(zicsr, PRIV_VERSION_1_10_0, ext_icsr),
ISA_EXT_DATA_ENTRY(zifencei, PRIV_VERSION_1_10_0, ext_ifencei),
target/riscv: Add Zihintntl extension ISA string to DTS RVA23 Profiles states: The RVA23 profiles are intended to be used for 64-bit application processors that will run rich OS stacks from standard binary OS distributions and with a substantial number of third-party binary user applications that will be supported over a considerable length of time in the field. The chapter 4 of the unprivileged spec introduces the Zihintntl extension and Zihintntl is a mandatory extension presented in RVA23 Profiles, whose purpose is to enable application and operating system portability across different implementations. Thus the DTS should contain the Zihintntl ISA string in order to pass to software. The unprivileged spec states: Like any HINTs, these instructions may be freely ignored. Hence, although they are described in terms of cache-based memory hierarchies, they do not mandate the provision of caches. These instructions are encoded with non-used opcode, e.g. ADD x0, x0, x2, which QEMU already supports, and QEMU does not emulate cache. Therefore these instructions can be considered as a no-op, and we only need to add a new property for the Zihintntl extension. Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Jason Chien <jason.chien@sifive.com> Message-ID: <20230726074049.19505-2-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-26 10:40:46 +03:00
ISA_EXT_DATA_ENTRY(zihintntl, PRIV_VERSION_1_10_0, ext_zihintntl),
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
ISA_EXT_DATA_ENTRY(zihintpause, PRIV_VERSION_1_10_0, ext_zihintpause),
target/riscv/cpu.c: add zmmul isa string zmmul was promoted from experimental to ratified in commit 6d00ffad4e95. Add a riscv,isa string for it. Fixes: 6d00ffad4e95 ("target/riscv: move zmmul out of the experimental properties") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230720132424.371132-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-20 16:24:23 +03:00
ISA_EXT_DATA_ENTRY(zmmul, PRIV_VERSION_1_12_0, ext_zmmul),
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
ISA_EXT_DATA_ENTRY(zawrs, PRIV_VERSION_1_12_0, ext_zawrs),
riscv: Add support for the Zfa extension This patch introduces the RISC-V Zfa extension, which introduces additional floating-point instructions: * fli (load-immediate) with pre-defined immediates * fminm/fmaxm (like fmin/fmax but with different NaN behaviour) * fround/froundmx (round to integer) * fcvtmod.w.d (Modular Convert-to-Integer) * fmv* to access high bits of float register bigger than XLEN * Quiet comparison instructions (fleq/fltq) Zfa defines its instructions in combination with the following extensions: * single-precision floating-point (F) * double-precision floating-point (D) * quad-precision floating-point (Q) * half-precision floating-point (Zfh) Since QEMU does not support the RISC-V quad-precision floating-point ISA extension (Q), this patch does not include the instructions that depend on this extension. All other instructions are included in this patch. The Zfa specification can be found here: https://github.com/riscv/riscv-isa-manual/blob/master/src/zfa.tex The Zfa specifciation is frozen and is in public review since May 3, 2023: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/SED4ntBkabg The patch also includes a TCG test for the fcvtmod.w.d instruction. The test cases test for correct results and flag behaviour. Note, that the Zfa specification requires fcvtmod's flag behaviour to be identical to a fcvt with the same operands (which is also tested). Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230710071243.282464-1-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10 10:12:43 +03:00
ISA_EXT_DATA_ENTRY(zfa, PRIV_VERSION_1_12_0, ext_zfa),
target/riscv: Expose properties for BF16 extensions Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230615063302.102409-6-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-15 09:33:01 +03:00
ISA_EXT_DATA_ENTRY(zfbfmin, PRIV_VERSION_1_12_0, ext_zfbfmin),
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
ISA_EXT_DATA_ENTRY(zfh, PRIV_VERSION_1_11_0, ext_zfh),
ISA_EXT_DATA_ENTRY(zfhmin, PRIV_VERSION_1_11_0, ext_zfhmin),
ISA_EXT_DATA_ENTRY(zfinx, PRIV_VERSION_1_12_0, ext_zfinx),
ISA_EXT_DATA_ENTRY(zdinx, PRIV_VERSION_1_12_0, ext_zdinx),
ISA_EXT_DATA_ENTRY(zca, PRIV_VERSION_1_12_0, ext_zca),
ISA_EXT_DATA_ENTRY(zcb, PRIV_VERSION_1_12_0, ext_zcb),
ISA_EXT_DATA_ENTRY(zcf, PRIV_VERSION_1_12_0, ext_zcf),
ISA_EXT_DATA_ENTRY(zcd, PRIV_VERSION_1_12_0, ext_zcd),
ISA_EXT_DATA_ENTRY(zce, PRIV_VERSION_1_12_0, ext_zce),
ISA_EXT_DATA_ENTRY(zcmp, PRIV_VERSION_1_12_0, ext_zcmp),
ISA_EXT_DATA_ENTRY(zcmt, PRIV_VERSION_1_12_0, ext_zcmt),
ISA_EXT_DATA_ENTRY(zba, PRIV_VERSION_1_12_0, ext_zba),
ISA_EXT_DATA_ENTRY(zbb, PRIV_VERSION_1_12_0, ext_zbb),
ISA_EXT_DATA_ENTRY(zbc, PRIV_VERSION_1_12_0, ext_zbc),
ISA_EXT_DATA_ENTRY(zbkb, PRIV_VERSION_1_12_0, ext_zbkb),
ISA_EXT_DATA_ENTRY(zbkc, PRIV_VERSION_1_12_0, ext_zbkc),
ISA_EXT_DATA_ENTRY(zbkx, PRIV_VERSION_1_12_0, ext_zbkx),
ISA_EXT_DATA_ENTRY(zbs, PRIV_VERSION_1_12_0, ext_zbs),
ISA_EXT_DATA_ENTRY(zk, PRIV_VERSION_1_12_0, ext_zk),
ISA_EXT_DATA_ENTRY(zkn, PRIV_VERSION_1_12_0, ext_zkn),
ISA_EXT_DATA_ENTRY(zknd, PRIV_VERSION_1_12_0, ext_zknd),
ISA_EXT_DATA_ENTRY(zkne, PRIV_VERSION_1_12_0, ext_zkne),
ISA_EXT_DATA_ENTRY(zknh, PRIV_VERSION_1_12_0, ext_zknh),
ISA_EXT_DATA_ENTRY(zkr, PRIV_VERSION_1_12_0, ext_zkr),
ISA_EXT_DATA_ENTRY(zks, PRIV_VERSION_1_12_0, ext_zks),
ISA_EXT_DATA_ENTRY(zksed, PRIV_VERSION_1_12_0, ext_zksed),
ISA_EXT_DATA_ENTRY(zksh, PRIV_VERSION_1_12_0, ext_zksh),
ISA_EXT_DATA_ENTRY(zkt, PRIV_VERSION_1_12_0, ext_zkt),
target/riscv: Add Zvbb ISA extension support This commit adds support for the Zvbb vector-crypto extension, which consists of the following instructions: * vrol.[vv,vx] * vror.[vv,vx,vi] * vbrev8.v * vrev8.v * vandn.[vv,vx] * vbrev.v * vclz.v * vctz.v * vcpop.v * vwsll.[vv,vx,vi] Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Co-authored-by: William Salmon <will.salmon@codethink.co.uk> Co-authored-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> [max.chou@sifive.com: Fix imm mode of vror.vi] Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: William Salmon <will.salmon@codethink.co.uk> Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Signed-off-by: Dickon Hood <dickon.hood@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Exposed x-zvbb property] Message-ID: <20230711165917.2629866-9-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:07 +03:00
ISA_EXT_DATA_ENTRY(zvbb, PRIV_VERSION_1_12_0, ext_zvbb),
target/riscv: Add Zvbc ISA extension support This commit adds support for the Zvbc vector-crypto extension, which consists of the following instructions: * vclmulh.[vx,vv] * vclmul.[vx,vv] Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Co-authored-by: Max Chou <max.chou@sifive.com> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> [max.chou@sifive.com: Exposed x-zvbc property] Message-ID: <20230711165917.2629866-5-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:03 +03:00
ISA_EXT_DATA_ENTRY(zvbc, PRIV_VERSION_1_12_0, ext_zvbc),
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
ISA_EXT_DATA_ENTRY(zve32f, PRIV_VERSION_1_10_0, ext_zve32f),
ISA_EXT_DATA_ENTRY(zve64f, PRIV_VERSION_1_10_0, ext_zve64f),
ISA_EXT_DATA_ENTRY(zve64d, PRIV_VERSION_1_10_0, ext_zve64d),
target/riscv: Expose properties for BF16 extensions Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230615063302.102409-6-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-15 09:33:01 +03:00
ISA_EXT_DATA_ENTRY(zvfbfmin, PRIV_VERSION_1_12_0, ext_zvfbfmin),
ISA_EXT_DATA_ENTRY(zvfbfwma, PRIV_VERSION_1_12_0, ext_zvfbfwma),
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
ISA_EXT_DATA_ENTRY(zvfh, PRIV_VERSION_1_12_0, ext_zvfh),
ISA_EXT_DATA_ENTRY(zvfhmin, PRIV_VERSION_1_12_0, ext_zvfhmin),
target/riscv: Add Zvkg ISA extension support This commit adds support for the Zvkg vector-crypto extension, which consists of the following instructions: * vgmul.vv * vghsh.vv Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> [max.chou@sifive.com: Replaced vstart checking by TCG op] Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Exposed x-zvkg property] [max.chou@sifive.com: Replaced uint by int for cross win32 build] Message-ID: <20230711165917.2629866-13-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:11 +03:00
ISA_EXT_DATA_ENTRY(zvkg, PRIV_VERSION_1_12_0, ext_zvkg),
target/riscv: Add Zvkned ISA extension support This commit adds support for the Zvkned vector-crypto extension, which consists of the following instructions: * vaesef.[vv,vs] * vaesdf.[vv,vs] * vaesdm.[vv,vs] * vaesz.vs * vaesem.[vv,vs] * vaeskf1.vi * vaeskf2.vi Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Co-authored-by: William Salmon <will.salmon@codethink.co.uk> [max.chou@sifive.com: Replaced vstart checking by TCG op] Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: William Salmon <will.salmon@codethink.co.uk> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Imported aes-round.h and exposed x-zvkned property] [max.chou@sifive.com: Fixed endian issues and replaced the vstart & vl egs checking by helper function] [max.chou@sifive.com: Replaced bswap32 calls in aes key expanding] Message-ID: <20230711165917.2629866-10-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:08 +03:00
ISA_EXT_DATA_ENTRY(zvkned, PRIV_VERSION_1_12_0, ext_zvkned),
target/riscv: Add Zvknh ISA extension support This commit adds support for the Zvknh vector-crypto extension, which consists of the following instructions: * vsha2ms.vv * vsha2c[hl].vv Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Co-authored-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> [max.chou@sifive.com: Replaced vstart checking by TCG op] Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Exposed x-zvknha & x-zvknhb properties] [max.chou@sifive.com: Replaced SEW selection to happened during translation] Message-ID: <20230711165917.2629866-11-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:09 +03:00
ISA_EXT_DATA_ENTRY(zvknha, PRIV_VERSION_1_12_0, ext_zvknha),
ISA_EXT_DATA_ENTRY(zvknhb, PRIV_VERSION_1_12_0, ext_zvknhb),
target/riscv: Add Zvksed ISA extension support This commit adds support for the Zvksed vector-crypto extension, which consists of the following instructions: * vsm4k.vi * vsm4r.[vv,vs] Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> [lawrence.hunter@codethink.co.uk: Moved SM4 functions from crypto_helper.c to vcrypto_helper.c] [nazar.kazakov@codethink.co.uk: Added alignment checks, refactored code to use macros, and minor style changes] Signed-off-by: Max Chou <max.chou@sifive.com> Message-ID: <20230711165917.2629866-16-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:14 +03:00
ISA_EXT_DATA_ENTRY(zvksed, PRIV_VERSION_1_12_0, ext_zvksed),
target/riscv: Add Zvksh ISA extension support This commit adds support for the Zvksh vector-crypto extension, which consists of the following instructions: * vsm3me.vv * vsm3c.vi Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> [max.chou@sifive.com: Replaced vstart checking by TCG op] Signed-off-by: Kiran Ostrolenk <kiran.ostrolenk@codethink.co.uk> Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [max.chou@sifive.com: Exposed x-zvksh property] Message-ID: <20230711165917.2629866-12-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:10 +03:00
ISA_EXT_DATA_ENTRY(zvksh, PRIV_VERSION_1_12_0, ext_zvksh),
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
ISA_EXT_DATA_ENTRY(zhinx, PRIV_VERSION_1_12_0, ext_zhinx),
ISA_EXT_DATA_ENTRY(zhinxmin, PRIV_VERSION_1_12_0, ext_zhinxmin),
ISA_EXT_DATA_ENTRY(smaia, PRIV_VERSION_1_12_0, ext_smaia),
target/riscv/cpu.c: add smepmp isa string The cpu->cfg.epmp extension is still experimental, but it already has a 'smepmp' riscv,isa string. Add it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230720132424.371132-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-20 16:24:24 +03:00
ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, epmp),
target/riscv: smstateen knobs Add knobs to allow users to enable smstateen and also export it via the ISA extension string. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Weiwei Li<liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230518175058.2772506-4-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-18 20:50:58 +03:00
ISA_EXT_DATA_ENTRY(smstateen, PRIV_VERSION_1_12_0, ext_smstateen),
target/riscv/cpu.c: remove 'multi_letter' from isa_ext_data We don't have MISA extensions in isa_edata_arr[] anymore. Remove the redundant 'multi_letter' field from isa_ext_data. Suggested-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:34 +03:00
ISA_EXT_DATA_ENTRY(ssaia, PRIV_VERSION_1_12_0, ext_ssaia),
ISA_EXT_DATA_ENTRY(sscofpmf, PRIV_VERSION_1_12_0, ext_sscofpmf),
ISA_EXT_DATA_ENTRY(sstc, PRIV_VERSION_1_12_0, ext_sstc),
ISA_EXT_DATA_ENTRY(svadu, PRIV_VERSION_1_12_0, ext_svadu),
ISA_EXT_DATA_ENTRY(svinval, PRIV_VERSION_1_12_0, ext_svinval),
ISA_EXT_DATA_ENTRY(svnapot, PRIV_VERSION_1_12_0, ext_svnapot),
ISA_EXT_DATA_ENTRY(svpbmt, PRIV_VERSION_1_12_0, ext_svpbmt),
ISA_EXT_DATA_ENTRY(xtheadba, PRIV_VERSION_1_11_0, ext_xtheadba),
ISA_EXT_DATA_ENTRY(xtheadbb, PRIV_VERSION_1_11_0, ext_xtheadbb),
ISA_EXT_DATA_ENTRY(xtheadbs, PRIV_VERSION_1_11_0, ext_xtheadbs),
ISA_EXT_DATA_ENTRY(xtheadcmo, PRIV_VERSION_1_11_0, ext_xtheadcmo),
ISA_EXT_DATA_ENTRY(xtheadcondmov, PRIV_VERSION_1_11_0, ext_xtheadcondmov),
ISA_EXT_DATA_ENTRY(xtheadfmemidx, PRIV_VERSION_1_11_0, ext_xtheadfmemidx),
ISA_EXT_DATA_ENTRY(xtheadfmv, PRIV_VERSION_1_11_0, ext_xtheadfmv),
ISA_EXT_DATA_ENTRY(xtheadmac, PRIV_VERSION_1_11_0, ext_xtheadmac),
ISA_EXT_DATA_ENTRY(xtheadmemidx, PRIV_VERSION_1_11_0, ext_xtheadmemidx),
ISA_EXT_DATA_ENTRY(xtheadmempair, PRIV_VERSION_1_11_0, ext_xtheadmempair),
ISA_EXT_DATA_ENTRY(xtheadsync, PRIV_VERSION_1_11_0, ext_xtheadsync),
ISA_EXT_DATA_ENTRY(xventanacondops, PRIV_VERSION_1_12_0, ext_XVentanaCondOps),
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
};
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
/* Hash that stores user set extensions */
static GHashTable *multi_ext_user_opts;
target/riscv: move riscv_cpu_validate_set_extensions() to tcg-cpu.c This function is the core of the RISC-V validations for TCG CPUs, and it has a lot going on. Functions in cpu.c were made public to allow them to be used by the KVM accelerator class later on. 'cpu_cfg_ext_get_min_version()' is notably hard to move it to another file due to its dependency with isa_edata_arr[] array, thus make it public and use it as is for now. riscv_cpu_validate_set_extensions() is kept public because it's used by csr.c in write_misa(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:53 +03:00
bool isa_ext_is_enabled(RISCVCPU *cpu, uint32_t ext_offset)
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
{
target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabled We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:16 +03:00
bool *ext_enabled = (void *)&cpu->cfg + ext_offset;
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
return *ext_enabled;
}
target/riscv: move riscv_cpu_validate_set_extensions() to tcg-cpu.c This function is the core of the RISC-V validations for TCG CPUs, and it has a lot going on. Functions in cpu.c were made public to allow them to be used by the KVM accelerator class later on. 'cpu_cfg_ext_get_min_version()' is notably hard to move it to another file due to its dependency with isa_edata_arr[] array, thus make it public and use it as is for now. riscv_cpu_validate_set_extensions() is kept public because it's used by csr.c in write_misa(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:53 +03:00
void isa_ext_update_enabled(RISCVCPU *cpu, uint32_t ext_offset, bool en)
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
{
target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabled We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:16 +03:00
bool *ext_enabled = (void *)&cpu->cfg + ext_offset;
target/riscv: Force disable extensions if priv spec version does not match We should disable extensions in riscv_cpu_realize() if minimum required priv spec version is not satisfied. This also ensures that machines with priv spec v1.11 (or lower) cannot enable H, V, and various multi-letter extensions. Fixes: a775398be2e9 ("target/riscv: Add isa extenstion strings to the device tree") Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Message-Id: <20220630061150.905174-3-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-30 09:11:50 +03:00
*ext_enabled = en;
}
target/riscv: move riscv_cpu_validate_set_extensions() to tcg-cpu.c This function is the core of the RISC-V validations for TCG CPUs, and it has a lot going on. Functions in cpu.c were made public to allow them to be used by the KVM accelerator class later on. 'cpu_cfg_ext_get_min_version()' is notably hard to move it to another file due to its dependency with isa_edata_arr[] array, thus make it public and use it as is for now. riscv_cpu_validate_set_extensions() is kept public because it's used by csr.c in write_misa(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:53 +03:00
int cpu_cfg_ext_get_min_version(uint32_t ext_offset)
target/riscv/cpu.c: introduce cpu_cfg_ext_auto_update() During realize() time we're activating a lot of extensions based on some criteria, e.g.: if (cpu->cfg.ext_zk) { cpu->cfg.ext_zkn = true; cpu->cfg.ext_zkr = true; cpu->cfg.ext_zkt = true; } This practice resulted in at least one case where we ended up enabling something we shouldn't: RVC enabling zca/zcd/zcf when using a CPU that has priv_spec older than 1.12.0. We're also not considering user choice. There's no way of doing it now but this is about to change in the next few patches. cpu_cfg_ext_auto_update() will check for priv version mismatches before enabling extensions. If we have a mismatch between the current priv version and the extension we want to enable, do not enable it. In the near future, this same function will also consider user choice when deciding if we're going to enable/disable an extension or not. For now let's use it to handle zca/zcd/zcf enablement if RVC is enabled. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-16-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:18 +03:00
{
int i;
for (i = 0; i < ARRAY_SIZE(isa_edata_arr); i++) {
if (isa_edata_arr[i].ext_enable_offset != ext_offset) {
continue;
}
return isa_edata_arr[i].min_version;
}
g_assert_not_reached();
}
target/riscv: move riscv_cpu_validate_set_extensions() to tcg-cpu.c This function is the core of the RISC-V validations for TCG CPUs, and it has a lot going on. Functions in cpu.c were made public to allow them to be used by the KVM accelerator class later on. 'cpu_cfg_ext_get_min_version()' is notably hard to move it to another file due to its dependency with isa_edata_arr[] array, thus make it public and use it as is for now. riscv_cpu_validate_set_extensions() is kept public because it's used by csr.c in write_misa(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:53 +03:00
bool cpu_cfg_ext_is_user_set(uint32_t ext_offset)
target/riscv/cpu.c: honor user choice in cpu_cfg_ext_auto_update() Add a new cpu_cfg_ext_is_user_set() helper to check if an extension was set by the user in the command line. Use it inside cpu_cfg_ext_auto_update() to verify if the user set a certain extension and, if that's the case, do not change its value. This will make us honor user choice instead of overwriting the values. Users will then be informed whether they're using an incompatible set of extensions instead of QEMU setting a magic value that works. The reason why we're not implementing user choice for MISA extensions right now is because, today, we do not silently change any MISA bit during realize() time (we do warn when enabling bits if RVG is enabled). We do that - a lot - with multi-letter extensions though, so we're handling the most immediate concern first. After this patch, we'll now error out if the user explicitly set 'zce' to true and 'zca' to false: $ ./build/qemu-system-riscv64 -M virt -cpu rv64,zce=true,zca=false -nographic qemu-system-riscv64: Zcf/Zcd/Zcb/Zcmp/Zcmt extensions require Zca extension This didn't happen before because we were enabling 'zca' if 'zce' was enabled regardless if the user set 'zca' to false. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:22 +03:00
{
return g_hash_table_contains(multi_ext_user_opts,
GUINT_TO_POINTER(ext_offset));
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
const char * const riscv_int_regnames[] = {
target/riscv: Fix format for indentation Fix identation problems, and try to use the same indentation strategy in the same file. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230405085813.40643-3-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-05 11:58:11 +03:00
"x0/zero", "x1/ra", "x2/sp", "x3/gp", "x4/tp", "x5/t0", "x6/t1",
"x7/t2", "x8/s0", "x9/s1", "x10/a0", "x11/a1", "x12/a2", "x13/a3",
"x14/a4", "x15/a5", "x16/a6", "x17/a7", "x18/s2", "x19/s3", "x20/s4",
"x21/s5", "x22/s6", "x23/s7", "x24/s8", "x25/s9", "x26/s10", "x27/s11",
"x28/t3", "x29/t4", "x30/t5", "x31/t6"
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
};
target/riscv: array for the 64 upper bits of 128-bit registers The upper 64-bit of the 128-bit registers have now a place inside the cpu state structure, and are created as globals for future use. Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr> Co-authored-by: Fabien Portas <fabien.portas@grenoble-inp.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220106210108.138226-7-frederic.petrot@univ-grenoble-alpes.fr Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-07 00:00:56 +03:00
const char * const riscv_int_regnamesh[] = {
target/riscv: Fix format for indentation Fix identation problems, and try to use the same indentation strategy in the same file. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230405085813.40643-3-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-05 11:58:11 +03:00
"x0h/zeroh", "x1h/rah", "x2h/sph", "x3h/gph", "x4h/tph", "x5h/t0h",
"x6h/t1h", "x7h/t2h", "x8h/s0h", "x9h/s1h", "x10h/a0h", "x11h/a1h",
"x12h/a2h", "x13h/a3h", "x14h/a4h", "x15h/a5h", "x16h/a6h", "x17h/a7h",
"x18h/s2h", "x19h/s3h", "x20h/s4h", "x21h/s5h", "x22h/s6h", "x23h/s7h",
"x24h/s8h", "x25h/s9h", "x26h/s10h", "x27h/s11h", "x28h/t3h", "x29h/t4h",
"x30h/t5h", "x31h/t6h"
target/riscv: array for the 64 upper bits of 128-bit registers The upper 64-bit of the 128-bit registers have now a place inside the cpu state structure, and are created as globals for future use. Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr> Co-authored-by: Fabien Portas <fabien.portas@grenoble-inp.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220106210108.138226-7-frederic.petrot@univ-grenoble-alpes.fr Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-07 00:00:56 +03:00
};
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
const char * const riscv_fpr_regnames[] = {
target/riscv: Fix format for indentation Fix identation problems, and try to use the same indentation strategy in the same file. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230405085813.40643-3-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-05 11:58:11 +03:00
"f0/ft0", "f1/ft1", "f2/ft2", "f3/ft3", "f4/ft4", "f5/ft5",
"f6/ft6", "f7/ft7", "f8/fs0", "f9/fs1", "f10/fa0", "f11/fa1",
"f12/fa2", "f13/fa3", "f14/fa4", "f15/fa5", "f16/fa6", "f17/fa7",
"f18/fs2", "f19/fs3", "f20/fs4", "f21/fs5", "f22/fs6", "f23/fs7",
"f24/fs8", "f25/fs9", "f26/fs10", "f27/fs11", "f28/ft8", "f29/ft9",
"f30/ft10", "f31/ft11"
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
};
target/riscv: Add RVV registers to log Print RvV extension register to log if VPU option is enabled. Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230629083730.386604-1-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-29 11:37:30 +03:00
const char * const riscv_rvv_regnames[] = {
"v0", "v1", "v2", "v3", "v4", "v5", "v6",
"v7", "v8", "v9", "v10", "v11", "v12", "v13",
"v14", "v15", "v16", "v17", "v18", "v19", "v20",
"v21", "v22", "v23", "v24", "v25", "v26", "v27",
"v28", "v29", "v30", "v31"
};
target/riscv: Remove unnecessary riscv_*_names[] declaration riscv_excp_names[] and riscv_intr_names[] are only referenced by target/riscv/cpu.c locally. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210514052435.2203156-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-05-14 08:24:35 +03:00
static const char * const riscv_excp_names[] = {
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
"misaligned_fetch",
"fault_fetch",
"illegal_instruction",
"breakpoint",
"misaligned_load",
"fault_load",
"misaligned_store",
"fault_store",
"user_ecall",
"supervisor_ecall",
"hypervisor_ecall",
"machine_ecall",
"exec_page_fault",
"load_page_fault",
"reserved",
RISC-V: Add a missing "," in riscv_excp_names This would almost certainly cause the exception names to be reported incorrectly. Coverity found the issue (CID 1420223). As per Peter's suggestion, I've also added a comma at the end of the list to avoid the issue reappearing in the future. Fixes: ab67a1d07a ("target/riscv: Add support for the new execption numbers") Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-05 19:46:20 +03:00
"store_page_fault",
target/riscv: Add support for the new execption numbers The v0.5 Hypervisor spec add new execption numbers, let's add support for those. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-01 04:01:46 +03:00
"reserved",
"reserved",
"reserved",
"reserved",
"guest_exec_page_fault",
"guest_load_page_fault",
"reserved",
RISC-V: Add a missing "," in riscv_excp_names This would almost certainly cause the exception names to be reported incorrectly. Coverity found the issue (CID 1420223). As per Peter's suggestion, I've also added a comma at the end of the list to avoid the issue reappearing in the future. Fixes: ab67a1d07a ("target/riscv: Add support for the new execption numbers") Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-03-05 19:46:20 +03:00
"guest_store_page_fault",
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
};
target/riscv: Remove unnecessary riscv_*_names[] declaration riscv_excp_names[] and riscv_intr_names[] are only referenced by target/riscv/cpu.c locally. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210514052435.2203156-1-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-05-14 08:24:35 +03:00
static const char * const riscv_intr_names[] = {
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
"u_software",
"s_software",
target/riscv: Rename the H irqs to VS irqs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-01 04:01:49 +03:00
"vs_software",
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
"m_software",
"u_timer",
"s_timer",
target/riscv: Rename the H irqs to VS irqs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-01 04:01:49 +03:00
"vs_timer",
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
"m_timer",
"u_external",
target/riscv: fix a typo with interrupt names Interrupt names have been swapped in 205377f8 and do not follow IRQ_*_EXT definition order. Signed-off-by: Emmanuel Blot <emmanuel.blot@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210421133236.11323-1-emmanuel.blot@sifive.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-21 16:32:36 +03:00
"s_external",
target/riscv: Rename the H irqs to VS irqs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-01 04:01:49 +03:00
"vs_external",
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
"m_external",
RISC-V: Update CSR and interrupt definitions * Add user-mode CSR defininitions. * Reorder CSR definitions to match the specification. * Change H mode interrupt comment to 'reserved'. * Remove unused X_COP interrupt. * Add user-mode interrupts. * Remove erroneous until comments on machine mode interrupts. * Move together paging mode and page table bit definitions. * Move together interrupt and exception cause definitions. Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2018-03-06 00:51:53 +03:00
"reserved",
"reserved",
"reserved",
"reserved"
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
};
target/riscv/cpu.c: redesign register_cpu_props() The function is now a no-op for all cpu_init() callers that are setting a non-zero misa value in set_misa(), since it's no longer used to sync cpu->cfg props with env->misa_ext bits. Remove it in those cases. While we're at it, rename the function to match what it's actually doing: create user properties to set/remove CPU extensions. Make a note that it will overwrite env->misa_ext with the defaults set by each user property. Update the MISA bits comment in cpu.h as well. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:51 +03:00
static void riscv_cpu_add_user_properties(Object *obj);
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
static void riscv_init_max_cpu_extensions(Object *obj);
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
target/riscv: Fix bug in getting trap cause name for trace_riscv_trap When the cause number is equal to or greater than 23, print "(unknown)" in trace_riscv_trap. The max valid number of riscv_excp_names is 23, so the last excpetion "guest_store_page_fault" can not be printed. In addition, the current check of cause is invalid for riscv_intr_names. So introduce riscv_cpu_get_trap_name to get the trap cause name. Signed-off-by: Yifei Jiang <jiangyifei@huawei.com> Signed-off-by: Yipeng Yin <yinyipeng1@huawei.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20200814035819.1214-1-jiangyifei@huawei.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-08-14 06:58:19 +03:00
const char *riscv_cpu_get_trap_name(target_ulong cause, bool async)
{
if (async) {
return (cause < ARRAY_SIZE(riscv_intr_names)) ?
riscv_intr_names[cause] : "(unknown)";
} else {
return (cause < ARRAY_SIZE(riscv_excp_names)) ?
riscv_excp_names[cause] : "(unknown)";
}
}
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
static void set_misa(CPURISCVState *env, RISCVMXL mxl, uint32_t ext)
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
{
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
env->misa_mxl_max = env->misa_mxl = mxl;
env->misa_ext_mask = env->misa_ext = ext;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
#ifndef CONFIG_USER_ONLY
static uint8_t satp_mode_from_str(const char *satp_mode_str)
{
if (!strncmp(satp_mode_str, "mbare", 5)) {
return VM_1_10_MBARE;
}
if (!strncmp(satp_mode_str, "sv32", 4)) {
return VM_1_10_SV32;
}
if (!strncmp(satp_mode_str, "sv39", 4)) {
return VM_1_10_SV39;
}
if (!strncmp(satp_mode_str, "sv48", 4)) {
return VM_1_10_SV48;
}
if (!strncmp(satp_mode_str, "sv57", 4)) {
return VM_1_10_SV57;
}
if (!strncmp(satp_mode_str, "sv64", 4)) {
return VM_1_10_SV64;
}
g_assert_not_reached();
}
uint8_t satp_mode_max_from_map(uint32_t map)
{
target/riscv: fix satp_mode_finalize() when satp_mode.supported = 0 In the same emulated RISC-V host, the 'host' KVM CPU takes 4 times longer to boot than the 'rv64' KVM CPU. The reason is an unintended behavior of riscv_cpu_satp_mode_finalize() when satp_mode.supported = 0, i.e. when cpu_init() does not set satp_mode_max_supported(). satp_mode_max_from_map(map) does: 31 - __builtin_clz(map) This means that, if satp_mode.supported = 0, satp_mode_supported_max wil be '31 - 32'. But this is C, so satp_mode_supported_max will gladly set it to UINT_MAX (4294967295). After that, if the user didn't set a satp_mode, set_satp_mode_default_map(cpu) will make cfg.satp_mode.map = cfg.satp_mode.supported So satp_mode.map = 0. And then satp_mode_map_max will be set to satp_mode_max_from_map(cpu->cfg.satp_mode.map), i.e. also UINT_MAX. The guard "satp_mode_map_max > satp_mode_supported_max" doesn't protect us here since both are UINT_MAX. And finally we have 2 loops: for (int i = satp_mode_map_max - 1; i >= 0; --i) { Which are, in fact, 2 loops from UINT_MAX -1 to -1. This is where the extra delay when booting the 'host' CPU is coming from. Commit 43d1de32f8 already set a precedence for satp_mode.supported = 0 in a different manner. We're doing the same here. If supported == 0, interpret as 'the CPU wants the OS to handle satp mode alone' and skip satp_mode_finalize(). We'll also put a guard in satp_mode_max_from_map() to assert out if map is 0 since the function is not ready to deal with it. Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Fixes: 6f23aaeb9b ("riscv: Allow user to set the satp mode") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230817152903.694926-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-08-17 18:29:03 +03:00
/*
* 'map = 0' will make us return (31 - 32), which C will
* happily overflow to UINT_MAX. There's no good result to
* return if 'map = 0' (e.g. returning 0 will be ambiguous
* with the result for 'map = 1').
*
* Assert out if map = 0. Callers will have to deal with
* it outside of this function.
*/
g_assert(map > 0);
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
/* map here has at least one bit set, so no problem with clz */
return 31 - __builtin_clz(map);
}
const char *satp_mode_str(uint8_t satp_mode, bool is_32_bit)
{
if (is_32_bit) {
switch (satp_mode) {
case VM_1_10_SV32:
return "sv32";
case VM_1_10_MBARE:
return "none";
}
} else {
switch (satp_mode) {
case VM_1_10_SV64:
return "sv64";
case VM_1_10_SV57:
return "sv57";
case VM_1_10_SV48:
return "sv48";
case VM_1_10_SV39:
return "sv39";
case VM_1_10_MBARE:
return "none";
}
}
g_assert_not_reached();
}
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
static void set_satp_mode_max_supported(RISCVCPU *cpu,
uint8_t satp_mode)
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
{
bool rv32 = riscv_cpu_mxl(&cpu->env) == MXL_RV32;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
const bool *valid_vm = rv32 ? valid_vm_1_10_32 : valid_vm_1_10_64;
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
for (int i = 0; i <= satp_mode; ++i) {
if (valid_vm[i]) {
cpu->cfg.satp_mode.supported |= (1 << i);
}
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
}
}
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
/* Set the satp mode to the max supported */
static void set_satp_mode_default_map(RISCVCPU *cpu)
{
cpu->cfg.satp_mode.map = cpu->cfg.satp_mode.supported;
}
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
#endif
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
static void riscv_any_cpu_init(Object *obj)
{
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
target/riscv: Remove the hardcoded RVXLEN macro Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: a07bc0c6dc4958681b4f93cbc5d0acc31ed3344a.1619234854.git.alistair.francis@wdc.com
2021-04-24 06:28:33 +03:00
#if defined(TARGET_RISCV32)
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV32, RVI | RVM | RVA | RVF | RVD | RVC | RVU);
target/riscv: Remove the hardcoded RVXLEN macro Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: a07bc0c6dc4958681b4f93cbc5d0acc31ed3344a.1619234854.git.alistair.francis@wdc.com
2021-04-24 06:28:33 +03:00
#elif defined(TARGET_RISCV64)
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV64, RVI | RVM | RVA | RVF | RVD | RVC | RVU);
target/riscv: Remove the hardcoded RVXLEN macro Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: a07bc0c6dc4958681b4f93cbc5d0acc31ed3344a.1619234854.git.alistair.francis@wdc.com
2021-04-24 06:28:33 +03:00
#endif
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(RISCV_CPU(obj),
target/riscv: Fix format for indentation Fix identation problems, and try to use the same indentation strategy in the same file. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230405085813.40643-3-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-05 11:58:11 +03:00
riscv_cpu_mxl(&RISCV_CPU(obj)->env) == MXL_RV32 ?
VM_1_10_SV32 : VM_1_10_SV57);
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#endif
target/riscv: add PRIV_VERSION_LATEST All these generic CPUs are using the latest priv available, at this moment PRIV_VERSION_1_12_0: - riscv_any_cpu_init() - rv32_base_cpu_init() - rv64_base_cpu_init() - rv128_base_cpu_init() Create a new PRIV_VERSION_LATEST enum and use it in those cases. I'll make it easier to update everything at once when a new priv version is available. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:07 +03:00
env->priv_ver = PRIV_VERSION_LATEST;
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
/* inherited from parent obj via riscv_cpu_init() */
cpu->cfg.ext_ifencei = true;
cpu->cfg.ext_icsr = true;
cpu->cfg.mmu = true;
cpu->cfg.pmp = true;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
static void riscv_max_cpu_init(Object *obj)
{
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
RISCVMXL mlx = MXL_RV64;
#ifdef TARGET_RISCV32
mlx = MXL_RV32;
#endif
set_misa(env, mlx, 0);
riscv_cpu_add_user_properties(obj);
riscv_init_max_cpu_extensions(obj);
env->priv_ver = PRIV_VERSION_LATEST;
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(RISCV_CPU(obj), mlx == MXL_RV32 ?
VM_1_10_SV32 : VM_1_10_SV57);
#endif
}
target/riscv: cpu: Set XLEN independently from target Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: 7eddba45b5d223321c031431849fdd42eceb514b.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:23:05 +03:00
#if defined(TARGET_RISCV64)
static void rv64_base_cpu_init(Object *obj)
target/riscv: Add a base 32 and 64 bit CPU At the same time deprecate the ISA string CPUs. It is dobtful anyone specifies the CPUs, but we are keeping them for the Spike machine (which is about to be depreated) so we may as well just mark them as deprecated. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-04-20 05:24:09 +03:00
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
target/riscv: Allow setting ISA extensions via CPU props This patch allows us to enable/disable the RISC-V ISA extensions from the QEMU command line. This works with the rv32 and rv64 machines. The idea is that in the future we can now add extensions and leave them disabled by default until enabled by the user. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-05-07 01:49:53 +03:00
/* We set this in the realise function */
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV64, 0);
target/riscv/cpu.c: redesign register_cpu_props() The function is now a no-op for all cpu_init() callers that are setting a non-zero misa value in set_misa(), since it's no longer used to sync cpu->cfg props with env->misa_ext bits. Remove it in those cases. While we're at it, rename the function to match what it's actually doing: create user properties to set/remove CPU extensions. Make a note that it will overwrite env->misa_ext with the defaults set by each user property. Update the MISA bits comment in cpu.h as well. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:51 +03:00
riscv_cpu_add_user_properties(obj);
target/riscv: Don't force update priv spec version to latest The riscv_cpu_realize() sets priv spec version to v1.12 when it is when "env->priv_ver == 0" (i.e. default v1.10) because the enum value of priv spec v1.10 is zero. Due to above issue, the sifive_u machine will see priv spec v1.12 instead of priv spec v1.10. To fix this issue, we set latest priv spec version (i.e. v1.12) for base rv64/rv32 cpu and riscv_cpu_realize() will override priv spec version only when "cpu->cfg.priv_spec != NULL". Fixes: 7100fe6c2441 ("target/riscv: Enable privileged spec version 1.12") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220611080107.391981-2-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-11 11:01:04 +03:00
/* Set latest version of privileged specification */
target/riscv: add PRIV_VERSION_LATEST All these generic CPUs are using the latest priv available, at this moment PRIV_VERSION_1_12_0: - riscv_any_cpu_init() - rv32_base_cpu_init() - rv64_base_cpu_init() - rv128_base_cpu_init() Create a new PRIV_VERSION_LATEST enum and use it in those cases. I'll make it easier to update everything at once when a new priv version is available. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:07 +03:00
env->priv_ver = PRIV_VERSION_LATEST;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV57);
#endif
target/riscv: Add a base 32 and 64 bit CPU At the same time deprecate the ISA string CPUs. It is dobtful anyone specifies the CPUs, but we are keeping them for the Spike machine (which is about to be depreated) so we may as well just mark them as deprecated. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-04-20 05:24:09 +03:00
}
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
static void rv64_sifive_u_cpu_init(Object *obj)
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
{
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV64, RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
target/riscv/cpu.c: remove set_priv_version() The setter is doing nothing special. Just set env->priv_ver directly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:06 +03:00
env->priv_ver = PRIV_VERSION_1_10_0;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV39);
#endif
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
/* inherited from parent obj via riscv_cpu_init() */
cpu->cfg.ext_ifencei = true;
cpu->cfg.ext_icsr = true;
cpu->cfg.mmu = true;
cpu->cfg.pmp = true;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
static void rv64_sifive_e_cpu_init(Object *obj)
target/riscv: Add the lowRISC Ibex CPU Ibex is a small and efficient, 32-bit, in-order RISC-V core with a 2-stage pipeline that implements the RV32IMC instruction set architecture. For more details on lowRISC see here: https://github.com/lowRISC/ibex Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com>
2020-04-23 20:50:09 +03:00
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV64, RVI | RVM | RVA | RVC | RVU);
target/riscv/cpu.c: remove set_priv_version() The setter is doing nothing special. Just set env->priv_ver directly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:06 +03:00
env->priv_ver = PRIV_VERSION_1_10_0;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(cpu, VM_1_10_MBARE);
#endif
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
/* inherited from parent obj via riscv_cpu_init() */
cpu->cfg.ext_ifencei = true;
cpu->cfg.ext_icsr = true;
cpu->cfg.pmp = true;
target/riscv: Add the lowRISC Ibex CPU Ibex is a small and efficient, 32-bit, in-order RISC-V core with a 2-stage pipeline that implements the RV32IMC instruction set architecture. For more details on lowRISC see here: https://github.com/lowRISC/ibex Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com>
2020-04-23 20:50:09 +03:00
}
target/riscv: setup everything for rv64 to support rv128 execution This patch adds the support of the '-cpu rv128' option to qemu-system-riscv64 so that we can indicate that we want to run rv128 executables. Still, there is no support for 128-bit insns at that stage so qemu fails miserably (as expected) if launched with this option. Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr> Co-authored-by: Fabien Portas <fabien.portas@grenoble-inp.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220106210108.138226-8-frederic.petrot@univ-grenoble-alpes.fr [ Changed by AF - Rename CPU to "x-rv128" ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-07 00:00:57 +03:00
RISC-V: Add initial support for T-Head C906 This patch adds the T-Head C906 to the list of known CPUs. Selecting this CPUs will automatically enable the available ISA extensions of the CPUs (incl. vendor extensions). Co-developed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230131202013.2541053-13-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-01-31 23:20:11 +03:00
static void rv64_thead_c906_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
RISCVCPU *cpu = RISCV_CPU(obj);
target/riscv: add RVG and remove cpu->cfg.ext_g We're still have one RISCVCPUConfig MISA flag, 'ext_g'. We'll remove it the same way we did with the others: create a "g" RISCVCPUMisaExtConfig property, remove the old "g" property, remove all instances of 'cfg.ext_g' and use riscv_has_ext(env, RVG). The caveat is that we don't have RVG, so add it. RVG will be used right off the bat in set_misa() of rv64_thead_c906_cpu_init() because the CPU is enabling G via the now removed 'ext_g' flag. After this patch, there are no more MISA extensions represented by flags in RISCVCPUConfig. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:50 +03:00
set_misa(env, MXL_RV64, RVG | RVC | RVS | RVU);
target/riscv/cpu.c: remove set_priv_version() The setter is doing nothing special. Just set env->priv_ver directly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:06 +03:00
env->priv_ver = PRIV_VERSION_1_11_0;
RISC-V: Add initial support for T-Head C906 This patch adds the T-Head C906 to the list of known CPUs. Selecting this CPUs will automatically enable the available ISA extensions of the CPUs (incl. vendor extensions). Co-developed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230131202013.2541053-13-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-01-31 23:20:11 +03:00
riscv: Add support for the Zfa extension This patch introduces the RISC-V Zfa extension, which introduces additional floating-point instructions: * fli (load-immediate) with pre-defined immediates * fminm/fmaxm (like fmin/fmax but with different NaN behaviour) * fround/froundmx (round to integer) * fcvtmod.w.d (Modular Convert-to-Integer) * fmv* to access high bits of float register bigger than XLEN * Quiet comparison instructions (fleq/fltq) Zfa defines its instructions in combination with the following extensions: * single-precision floating-point (F) * double-precision floating-point (D) * quad-precision floating-point (Q) * half-precision floating-point (Zfh) Since QEMU does not support the RISC-V quad-precision floating-point ISA extension (Q), this patch does not include the instructions that depend on this extension. All other instructions are included in this patch. The Zfa specification can be found here: https://github.com/riscv/riscv-isa-manual/blob/master/src/zfa.tex The Zfa specifciation is frozen and is in public review since May 3, 2023: https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/SED4ntBkabg The patch also includes a TCG test for the fcvtmod.w.d instruction. The test cases test for correct results and flag behaviour. Note, that the Zfa specification requires fcvtmod's flag behaviour to be identical to a fcvt with the same operands (which is also tested). Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230710071243.282464-1-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10 10:12:43 +03:00
cpu->cfg.ext_zfa = true;
RISC-V: Add initial support for T-Head C906 This patch adds the T-Head C906 to the list of known CPUs. Selecting this CPUs will automatically enable the available ISA extensions of the CPUs (incl. vendor extensions). Co-developed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230131202013.2541053-13-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-01-31 23:20:11 +03:00
cpu->cfg.ext_zfh = true;
cpu->cfg.mmu = true;
cpu->cfg.ext_xtheadba = true;
cpu->cfg.ext_xtheadbb = true;
cpu->cfg.ext_xtheadbs = true;
cpu->cfg.ext_xtheadcmo = true;
cpu->cfg.ext_xtheadcondmov = true;
cpu->cfg.ext_xtheadfmemidx = true;
cpu->cfg.ext_xtheadmac = true;
cpu->cfg.ext_xtheadmemidx = true;
cpu->cfg.ext_xtheadmempair = true;
cpu->cfg.ext_xtheadsync = true;
cpu->cfg.mvendorid = THEAD_VENDOR_ID;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(cpu, VM_1_10_SV39);
#endif
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
/* inherited from parent obj via riscv_cpu_init() */
cpu->cfg.pmp = true;
RISC-V: Add initial support for T-Head C906 This patch adds the T-Head C906 to the list of known CPUs. Selecting this CPUs will automatically enable the available ISA extensions of the CPUs (incl. vendor extensions). Co-developed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230131202013.2541053-13-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-01-31 23:20:11 +03:00
}
target/riscv: add Ventana's Veyron V1 CPU Add a virtual CPU for Ventana's first CPU named veyron-v1. It runs exclusively for the rv64 target. It's tested with the 'virt' board. CPU specs and general information can be found here: https://www.nextplatform.com/2023/02/02/the-first-risc-v-shot-across-the-datacenter-bow/ Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230418123624.16414-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-18 15:36:24 +03:00
static void rv64_veyron_v1_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
RISCVCPU *cpu = RISCV_CPU(obj);
set_misa(env, MXL_RV64, RVG | RVC | RVS | RVU | RVH);
env->priv_ver = PRIV_VERSION_1_12_0;
/* Enable ISA extensions */
cpu->cfg.mmu = true;
target/riscv/cpu.c: fix veyron-v1 CPU properties Commit 7f0bdfb5bfc2 ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") removed code that was enabling mmu, pmp, ext_ifencei and ext_icsr from riscv_cpu_init(), the init() function of TYPE_RISCV_CPU, parent type of all RISC-V CPUss. This was done to force CPUs to explictly enable all extensions and features it requires, without any 'magic values' that were inherited by the parent type. This commit failed to make appropriate changes in the 'veyron-v1' CPU, added earlier by commit e1d084a8524a. The result is that the veyron-v1 CPU has ext_ifencei, ext_icsr and pmp set to 'false', which is not the case. The reason why it took this long to notice (thanks LIU Zhiwei for reporting it) is because Linux doesn't mind 'ifencei' and 'icsr' being absent in the 'riscv,isa' DT, implying that they're both present if the 'i' extension is enabled. OpenSBI also doesn't error out or warns about the lack of 'pmp', it'll just not protect memory pages. Fix it by setting them to 'true' in rv64_veyron_v1_cpu_init() like 7f0bdfb5bfc2 already did with other CPUs. Reported-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Fixes: 7f0bdfb5bfc2 ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-Id: <20230620152443.137079-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-20 18:24:43 +03:00
cpu->cfg.ext_ifencei = true;
cpu->cfg.ext_icsr = true;
cpu->cfg.pmp = true;
target/riscv: add Ventana's Veyron V1 CPU Add a virtual CPU for Ventana's first CPU named veyron-v1. It runs exclusively for the rv64 target. It's tested with the 'virt' board. CPU specs and general information can be found here: https://www.nextplatform.com/2023/02/02/the-first-risc-v-shot-across-the-datacenter-bow/ Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230418123624.16414-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-18 15:36:24 +03:00
cpu->cfg.ext_icbom = true;
cpu->cfg.cbom_blocksize = 64;
cpu->cfg.cboz_blocksize = 64;
cpu->cfg.ext_icboz = true;
cpu->cfg.ext_smaia = true;
cpu->cfg.ext_ssaia = true;
cpu->cfg.ext_sscofpmf = true;
cpu->cfg.ext_sstc = true;
cpu->cfg.ext_svinval = true;
cpu->cfg.ext_svnapot = true;
cpu->cfg.ext_svpbmt = true;
cpu->cfg.ext_smstateen = true;
cpu->cfg.ext_zba = true;
cpu->cfg.ext_zbb = true;
cpu->cfg.ext_zbc = true;
cpu->cfg.ext_zbs = true;
cpu->cfg.ext_XVentanaCondOps = true;
cpu->cfg.mvendorid = VEYRON_V1_MVENDORID;
cpu->cfg.marchid = VEYRON_V1_MARCHID;
cpu->cfg.mimpid = VEYRON_V1_MIMPID;
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(cpu, VM_1_10_SV48);
#endif
}
target/riscv: setup everything for rv64 to support rv128 execution This patch adds the support of the '-cpu rv128' option to qemu-system-riscv64 so that we can indicate that we want to run rv128 executables. Still, there is no support for 128-bit insns at that stage so qemu fails miserably (as expected) if launched with this option. Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr> Co-authored-by: Fabien Portas <fabien.portas@grenoble-inp.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220106210108.138226-8-frederic.petrot@univ-grenoble-alpes.fr [ Changed by AF - Rename CPU to "x-rv128" ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-07 00:00:57 +03:00
static void rv128_base_cpu_init(Object *obj)
{
if (qemu_tcg_mttcg_enabled()) {
/* Missing 128-bit aligned atomics */
error_report("128-bit RISC-V currently does not work with Multi "
"Threaded TCG. Please use: -accel tcg,thread=single");
exit(EXIT_FAILURE);
}
CPURISCVState *env = &RISCV_CPU(obj)->env;
/* We set this in the realise function */
set_misa(env, MXL_RV128, 0);
target/riscv/cpu.c: redesign register_cpu_props() The function is now a no-op for all cpu_init() callers that are setting a non-zero misa value in set_misa(), since it's no longer used to sync cpu->cfg props with env->misa_ext bits. Remove it in those cases. While we're at it, rename the function to match what it's actually doing: create user properties to set/remove CPU extensions. Make a note that it will overwrite env->misa_ext with the defaults set by each user property. Update the MISA bits comment in cpu.h as well. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:51 +03:00
riscv_cpu_add_user_properties(obj);
target/riscv: Don't force update priv spec version to latest The riscv_cpu_realize() sets priv spec version to v1.12 when it is when "env->priv_ver == 0" (i.e. default v1.10) because the enum value of priv spec v1.10 is zero. Due to above issue, the sifive_u machine will see priv spec v1.12 instead of priv spec v1.10. To fix this issue, we set latest priv spec version (i.e. v1.12) for base rv64/rv32 cpu and riscv_cpu_realize() will override priv spec version only when "cpu->cfg.priv_spec != NULL". Fixes: 7100fe6c2441 ("target/riscv: Enable privileged spec version 1.12") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220611080107.391981-2-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-11 11:01:04 +03:00
/* Set latest version of privileged specification */
target/riscv: add PRIV_VERSION_LATEST All these generic CPUs are using the latest priv available, at this moment PRIV_VERSION_1_12_0: - riscv_any_cpu_init() - rv32_base_cpu_init() - rv64_base_cpu_init() - rv128_base_cpu_init() Create a new PRIV_VERSION_LATEST enum and use it in those cases. I'll make it easier to update everything at once when a new priv version is available. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:07 +03:00
env->priv_ver = PRIV_VERSION_LATEST;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV57);
#endif
target/riscv: setup everything for rv64 to support rv128 execution This patch adds the support of the '-cpu rv128' option to qemu-system-riscv64 so that we can indicate that we want to run rv128 executables. Still, there is no support for 128-bit insns at that stage so qemu fails miserably (as expected) if launched with this option. Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr> Co-authored-by: Fabien Portas <fabien.portas@grenoble-inp.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220106210108.138226-8-frederic.petrot@univ-grenoble-alpes.fr [ Changed by AF - Rename CPU to "x-rv128" ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-07 00:00:57 +03:00
}
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
#else
target/riscv: cpu: Set XLEN independently from target Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: 7eddba45b5d223321c031431849fdd42eceb514b.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:23:05 +03:00
static void rv32_base_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
/* We set this in the realise function */
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV32, 0);
target/riscv/cpu.c: redesign register_cpu_props() The function is now a no-op for all cpu_init() callers that are setting a non-zero misa value in set_misa(), since it's no longer used to sync cpu->cfg props with env->misa_ext bits. Remove it in those cases. While we're at it, rename the function to match what it's actually doing: create user properties to set/remove CPU extensions. Make a note that it will overwrite env->misa_ext with the defaults set by each user property. Update the MISA bits comment in cpu.h as well. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:51 +03:00
riscv_cpu_add_user_properties(obj);
target/riscv: Don't force update priv spec version to latest The riscv_cpu_realize() sets priv spec version to v1.12 when it is when "env->priv_ver == 0" (i.e. default v1.10) because the enum value of priv spec v1.10 is zero. Due to above issue, the sifive_u machine will see priv spec v1.12 instead of priv spec v1.10. To fix this issue, we set latest priv spec version (i.e. v1.12) for base rv64/rv32 cpu and riscv_cpu_realize() will override priv spec version only when "cpu->cfg.priv_spec != NULL". Fixes: 7100fe6c2441 ("target/riscv: Enable privileged spec version 1.12") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220611080107.391981-2-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-11 11:01:04 +03:00
/* Set latest version of privileged specification */
target/riscv: add PRIV_VERSION_LATEST All these generic CPUs are using the latest priv available, at this moment PRIV_VERSION_1_12_0: - riscv_any_cpu_init() - rv32_base_cpu_init() - rv64_base_cpu_init() - rv128_base_cpu_init() Create a new PRIV_VERSION_LATEST enum and use it in those cases. I'll make it easier to update everything at once when a new priv version is available. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:07 +03:00
env->priv_ver = PRIV_VERSION_LATEST;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV32);
#endif
target/riscv: cpu: Set XLEN independently from target Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: 7eddba45b5d223321c031431849fdd42eceb514b.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:23:05 +03:00
}
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
static void rv32_sifive_u_cpu_init(Object *obj)
{
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV32, RVI | RVM | RVA | RVF | RVD | RVC | RVS | RVU);
target/riscv/cpu.c: remove set_priv_version() The setter is doing nothing special. Just set env->priv_ver directly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:06 +03:00
env->priv_ver = PRIV_VERSION_1_10_0;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(RISCV_CPU(obj), VM_1_10_SV32);
#endif
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
/* inherited from parent obj via riscv_cpu_init() */
cpu->cfg.ext_ifencei = true;
cpu->cfg.ext_icsr = true;
cpu->cfg.mmu = true;
cpu->cfg.pmp = true;
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
}
target/riscv: Add the lowRISC Ibex CPU Ibex is a small and efficient, 32-bit, in-order RISC-V core with a 2-stage pipeline that implements the RV32IMC instruction set architecture. For more details on lowRISC see here: https://github.com/lowRISC/ibex Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com>
2020-04-23 20:50:09 +03:00
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
static void rv32_sifive_e_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV32, RVI | RVM | RVA | RVC | RVU);
target/riscv/cpu.c: remove set_priv_version() The setter is doing nothing special. Just set env->priv_ver directly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:06 +03:00
env->priv_ver = PRIV_VERSION_1_10_0;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(cpu, VM_1_10_MBARE);
#endif
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
/* inherited from parent obj via riscv_cpu_init() */
cpu->cfg.ext_ifencei = true;
cpu->cfg.ext_icsr = true;
cpu->cfg.pmp = true;
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
}
riscv: Generalize CPU init routine for the imacu CPU There is no need to have two functions that have almost the same codes for 32-bit and 64-bit imacu CPUs. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1591837729-27486-3-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-11 04:08:48 +03:00
target/riscv: Rename IBEX CPU init routine Current IBEX CPU init routine name seems to be too generic. Since it uses a different reset vector from the generic one, it merits a dedicated name. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-2-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-2-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-16 03:50:37 +03:00
static void rv32_ibex_cpu_init(Object *obj)
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV32, RVI | RVM | RVC | RVU);
target/riscv/cpu.c: remove set_priv_version() The setter is doing nothing special. Just set env->priv_ver directly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:06 +03:00
env->priv_ver = PRIV_VERSION_1_11_0;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(cpu, VM_1_10_MBARE);
#endif
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
cpu->cfg.epmp = true;
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
/* inherited from parent obj via riscv_cpu_init() */
cpu->cfg.ext_ifencei = true;
cpu->cfg.ext_icsr = true;
cpu->cfg.pmp = true;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
riscv: Keep the CPU init routine names consistent Adding a _ to keep some consistency among the CPU init routines. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1591837729-27486-4-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-11 04:08:49 +03:00
static void rv32_imafcu_nommu_cpu_init(Object *obj)
target/riscv: Add a sifive-e34 cpu type The sifive-e34 cpu type is the same as the sifive-e31 with the single precision floating-point extension enabled. Signed-off-by: Corey Wharton <coreyw7@fb.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20200313193429.8035-3-coreyw7@fb.com Message-Id: <20200313193429.8035-3-coreyw7@fb.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-03-13 22:34:29 +03:00
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
set_misa(env, MXL_RV32, RVI | RVM | RVA | RVF | RVC | RVU);
target/riscv/cpu.c: remove set_priv_version() The setter is doing nothing special. Just set env->priv_ver directly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:06 +03:00
env->priv_ver = PRIV_VERSION_1_10_0;
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(cpu, VM_1_10_MBARE);
#endif
target/riscv/cpu.c: remove cfg setup from riscv_cpu_init() We have 4 config settings being done in riscv_cpu_init(): ext_ifencei, ext_icsr, mmu and pmp. This is also the constructor of the "riscv-cpu" device, which happens to be the parent device of every RISC-V cpu. The result is that these 4 configs are being set every time, and every other CPU should always account for them. CPUs such as sifive_e need to disable settings that aren't enabled simply because the parent class happens to be enabling it. Moving all configurations from the parent class to each CPU will centralize the config of each CPU into its own init(), which is clearer than having to account to whatever happens to be set in the parent device. These settings are also being set in register_cpu_props() when no 'misa_ext' is set, so for these CPUs we don't need changes. Named CPUs will receive all cfgs that the parent were setting into their init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:13 +03:00
/* inherited from parent obj via riscv_cpu_init() */
cpu->cfg.ext_ifencei = true;
cpu->cfg.ext_icsr = true;
cpu->cfg.pmp = true;
target/riscv: Add a sifive-e34 cpu type The sifive-e34 cpu type is the same as the sifive-e31 with the single precision floating-point extension enabled. Signed-off-by: Corey Wharton <coreyw7@fb.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 20200313193429.8035-3-coreyw7@fb.com Message-Id: <20200313193429.8035-3-coreyw7@fb.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-03-13 22:34:29 +03:00
}
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
#endif
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
target/riscv: Add host cpu type 'host' type cpu is set isa to RV32 or RV64 simply, more isa info will obtain from KVM in kvm_arch_init_vcpu() 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-10-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 11:13:25 +03:00
#if defined(CONFIG_KVM)
static void riscv_host_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
#if defined(TARGET_RISCV32)
set_misa(env, MXL_RV32, 0);
#elif defined(TARGET_RISCV64)
set_misa(env, MXL_RV64, 0);
#endif
target/riscv/cpu.c: redesign register_cpu_props() The function is now a no-op for all cpu_init() callers that are setting a non-zero misa value in set_misa(), since it's no longer used to sync cpu->cfg props with env->misa_ext bits. Remove it in those cases. While we're at it, rename the function to match what it's actually doing: create user properties to set/remove CPU extensions. Make a note that it will overwrite env->misa_ext with the defaults set by each user property. Update the MISA bits comment in cpu.h as well. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:51 +03:00
riscv_cpu_add_user_properties(obj);
target/riscv: Add host cpu type 'host' type cpu is set isa to RV32 or RV64 simply, more isa info will obtain from KVM in kvm_arch_init_vcpu() 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-10-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 11:13:25 +03:00
}
target/riscv: Restrict KVM-specific fields from ArchCPU These fields shouldn't be accessed when KVM is not available. Restrict the KVM timer migration state. Rename the KVM timer post_load() handler accordingly, because cpu_post_load() is too generic. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230626232007.8933-3-philmd@linaro.org>
2023-04-04 12:15:05 +03:00
#endif /* CONFIG_KVM */
target/riscv: Add host cpu type 'host' type cpu is set isa to RV32 or RV64 simply, more isa info will obtain from KVM in kvm_arch_init_vcpu() 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-10-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 11:13:25 +03:00
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
static ObjectClass *riscv_cpu_class_by_name(const char *cpu_model)
{
ObjectClass *oc;
char *typename;
char **cpuname;
cpuname = g_strsplit(cpu_model, ",", 1);
typename = g_strdup_printf(RISCV_CPU_TYPE_NAME("%s"), cpuname[0]);
oc = object_class_by_name(typename);
g_strfreev(cpuname);
g_free(typename);
if (!oc || !object_class_dynamic_cast(oc, TYPE_RISCV_CPU) ||
object_class_is_abstract(oc)) {
return NULL;
}
return oc;
}
qom/cpu: Simplify how CPUClass:cpu_dump_state() prints CPUClass method dump_statistics() takes an fprintf()-like callback and a FILE * to pass to it. Most callers pass fprintf() and stderr. log_cpu_state() passes fprintf() and qemu_log_file. hmp_info_registers() passes monitor_fprintf() and the current monitor cast to FILE *. monitor_fprintf() casts it right back, and is otherwise identical to monitor_printf(). The callback gets passed around a lot, which is tiresome. The type-punning around monitor_fprintf() is ugly. Drop the callback, and call qemu_fprintf() instead. Also gets rid of the type-punning, since qemu_fprintf() takes NULL instead of the current monitor cast to FILE *. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190417191805.28198-15-armbru@redhat.com>
2019-04-17 22:18:02 +03:00
static void riscv_cpu_dump_state(CPUState *cs, FILE *f, int flags)
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
{
RISCVCPU *cpu = RISCV_CPU(cs);
CPURISCVState *env = &cpu->env;
target/riscv: Add RVV registers to log Print RvV extension register to log if VPU option is enabled. Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230629083730.386604-1-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-29 11:37:30 +03:00
int i, j;
uint8_t *p;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
target/riscv: Dump Hypervisor registers if enabled Dump the Hypervisor registers and the current Hypervisor state. While we are editing this code let's also dump stvec and scause. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-01 04:02:02 +03:00
#if !defined(CONFIG_USER_ONLY)
if (riscv_has_ext(env, RVH)) {
target/riscv: Remove riscv_cpu_virt_enabled() Directly use env->virt_enabled instead. Suggested-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230405085813.40643-2-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-05 11:58:10 +03:00
qemu_fprintf(f, " %s %d\n", "V = ", env->virt_enabled);
target/riscv: Dump Hypervisor registers if enabled Dump the Hypervisor registers and the current Hypervisor state. While we are editing this code let's also dump stvec and scause. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-01 04:02:02 +03:00
}
#endif
qom/cpu: Simplify how CPUClass:cpu_dump_state() prints CPUClass method dump_statistics() takes an fprintf()-like callback and a FILE * to pass to it. Most callers pass fprintf() and stderr. log_cpu_state() passes fprintf() and qemu_log_file. hmp_info_registers() passes monitor_fprintf() and the current monitor cast to FILE *. monitor_fprintf() casts it right back, and is otherwise identical to monitor_printf(). The callback gets passed around a lot, which is tiresome. The type-punning around monitor_fprintf() is ugly. Drop the callback, and call qemu_fprintf() instead. Also gets rid of the type-punning, since qemu_fprintf() takes NULL instead of the current monitor cast to FILE *. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190417191805.28198-15-armbru@redhat.com>
2019-04-17 22:18:02 +03:00
qemu_fprintf(f, " %s " TARGET_FMT_lx "\n", "pc ", env->pc);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#ifndef CONFIG_USER_ONLY
target/riscv: Use riscv_csrrw_debug for cpu_dump Use the official debug read interface to the csrs, rather than referencing the env slots directly. Put the list of csrs to dump into a table. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-15-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:17:08 +03:00
{
static const int dump_csrs[] = {
CSR_MHARTID,
CSR_MSTATUS,
CSR_MSTATUSH,
target/riscv: Add some comments for sstatus CSR in riscv_cpu_dump_state() sstatus register dump is currently missing in riscv_cpu_dump_state(). As sstatus is a copy of mstatus, which is described in the priv spec, it seems redundant to print the same information twice. Add some comments for this to let people know this is intentional. Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20221125050354.3166023-1-bmeng@tinylab.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-11-25 08:03:54 +03:00
/*
* CSR_SSTATUS is intentionally omitted here as its value
* can be figured out by looking at CSR_MSTATUS
*/
target/riscv: Use riscv_csrrw_debug for cpu_dump Use the official debug read interface to the csrs, rather than referencing the env slots directly. Put the list of csrs to dump into a table. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-15-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:17:08 +03:00
CSR_HSTATUS,
CSR_VSSTATUS,
CSR_MIP,
CSR_MIE,
CSR_MIDELEG,
CSR_HIDELEG,
CSR_MEDELEG,
CSR_HEDELEG,
CSR_MTVEC,
CSR_STVEC,
CSR_VSTVEC,
CSR_MEPC,
CSR_SEPC,
CSR_VSEPC,
CSR_MCAUSE,
CSR_SCAUSE,
CSR_VSCAUSE,
CSR_MTVAL,
CSR_STVAL,
CSR_HTVAL,
CSR_MTVAL2,
CSR_MSCRATCH,
CSR_SSCRATCH,
CSR_SATP,
target/riscv: Print new PM CSRs in QEMU logs Signed-off-by: Alexey Baturo <space.monkey.delivers@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20211025173609.2724490-6-space.monkey.delivers@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-25 20:36:06 +03:00
CSR_MMTE,
CSR_UPMBASE,
CSR_UPMMASK,
CSR_SPMBASE,
CSR_SPMMASK,
CSR_MPMBASE,
CSR_MPMMASK,
target/riscv: Use riscv_csrrw_debug for cpu_dump Use the official debug read interface to the csrs, rather than referencing the env slots directly. Put the list of csrs to dump into a table. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-15-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:17:08 +03:00
};
target/riscv: cpu: Fixup local variables shadowing Local variables shadowing other local variables or parameters make the code needlessly hard to understand. Bugs love to hide in such code. Evidence: "[PATCH v3 1/7] migration/rdma: Fix save_page method to fail on polling error". This patch removes the local variable shadowing. Tested by adding: --extra-cflags='-Wshadow=local -Wno-error=shadow=local -Wno-error=shadow=compatible-local' To configure Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925043023.71448-3-alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2023-09-25 07:30:21 +03:00
for (i = 0; i < ARRAY_SIZE(dump_csrs); ++i) {
target/riscv: Use riscv_csrrw_debug for cpu_dump Use the official debug read interface to the csrs, rather than referencing the env slots directly. Put the list of csrs to dump into a table. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-15-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:17:08 +03:00
int csrno = dump_csrs[i];
target_ulong val = 0;
RISCVException res = riscv_csrrw_debug(env, csrno, &val, 0, 0);
/*
* Rely on the smode, hmode, etc, predicates within csr.c
* to do the filtering of the registers that are present.
*/
if (res == RISCV_EXCP_NONE) {
qemu_fprintf(f, " %-8s " TARGET_FMT_lx "\n",
csr_ops[csrno].name, val);
}
}
target/riscv: Dump Hypervisor registers if enabled Dump the Hypervisor registers and the current Hypervisor state. While we are editing this code let's also dump stvec and scause. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-02-01 04:02:02 +03:00
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#endif
for (i = 0; i < 32; i++) {
target/riscv: line up all of the registers in the info register dump Ensure the columns for all of the register names and values line up. No functional change, just a minor tweak to the output. Signed-off-by: Travis Geiselbrecht <travisg@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20211009055019.545153-1-travisg@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-09 08:50:19 +03:00
qemu_fprintf(f, " %-8s " TARGET_FMT_lx,
qom/cpu: Simplify how CPUClass:cpu_dump_state() prints CPUClass method dump_statistics() takes an fprintf()-like callback and a FILE * to pass to it. Most callers pass fprintf() and stderr. log_cpu_state() passes fprintf() and qemu_log_file. hmp_info_registers() passes monitor_fprintf() and the current monitor cast to FILE *. monitor_fprintf() casts it right back, and is otherwise identical to monitor_printf(). The callback gets passed around a lot, which is tiresome. The type-punning around monitor_fprintf() is ugly. Drop the callback, and call qemu_fprintf() instead. Also gets rid of the type-punning, since qemu_fprintf() takes NULL instead of the current monitor cast to FILE *. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190417191805.28198-15-armbru@redhat.com>
2019-04-17 22:18:02 +03:00
riscv_int_regnames[i], env->gpr[i]);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
if ((i & 3) == 3) {
qom/cpu: Simplify how CPUClass:cpu_dump_state() prints CPUClass method dump_statistics() takes an fprintf()-like callback and a FILE * to pass to it. Most callers pass fprintf() and stderr. log_cpu_state() passes fprintf() and qemu_log_file. hmp_info_registers() passes monitor_fprintf() and the current monitor cast to FILE *. monitor_fprintf() casts it right back, and is otherwise identical to monitor_printf(). The callback gets passed around a lot, which is tiresome. The type-punning around monitor_fprintf() is ugly. Drop the callback, and call qemu_fprintf() instead. Also gets rid of the type-punning, since qemu_fprintf() takes NULL instead of the current monitor cast to FILE *. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190417191805.28198-15-armbru@redhat.com>
2019-04-17 22:18:02 +03:00
qemu_fprintf(f, "\n");
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
}
target/riscv: Honor CPU_DUMP_FPU Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Reviewed-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-05-11 06:31:33 +03:00
if (flags & CPU_DUMP_FPU) {
for (i = 0; i < 32; i++) {
target/riscv: line up all of the registers in the info register dump Ensure the columns for all of the register names and values line up. No functional change, just a minor tweak to the output. Signed-off-by: Travis Geiselbrecht <travisg@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20211009055019.545153-1-travisg@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-09 08:50:19 +03:00
qemu_fprintf(f, " %-8s %016" PRIx64,
qom/cpu: Simplify how CPUClass:cpu_dump_state() prints CPUClass method dump_statistics() takes an fprintf()-like callback and a FILE * to pass to it. Most callers pass fprintf() and stderr. log_cpu_state() passes fprintf() and qemu_log_file. hmp_info_registers() passes monitor_fprintf() and the current monitor cast to FILE *. monitor_fprintf() casts it right back, and is otherwise identical to monitor_printf(). The callback gets passed around a lot, which is tiresome. The type-punning around monitor_fprintf() is ugly. Drop the callback, and call qemu_fprintf() instead. Also gets rid of the type-punning, since qemu_fprintf() takes NULL instead of the current monitor cast to FILE *. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190417191805.28198-15-armbru@redhat.com>
2019-04-17 22:18:02 +03:00
riscv_fpr_regnames[i], env->fpr[i]);
target/riscv: Honor CPU_DUMP_FPU Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Reviewed-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-05-11 06:31:33 +03:00
if ((i & 3) == 3) {
qom/cpu: Simplify how CPUClass:cpu_dump_state() prints CPUClass method dump_statistics() takes an fprintf()-like callback and a FILE * to pass to it. Most callers pass fprintf() and stderr. log_cpu_state() passes fprintf() and qemu_log_file. hmp_info_registers() passes monitor_fprintf() and the current monitor cast to FILE *. monitor_fprintf() casts it right back, and is otherwise identical to monitor_printf(). The callback gets passed around a lot, which is tiresome. The type-punning around monitor_fprintf() is ugly. Drop the callback, and call qemu_fprintf() instead. Also gets rid of the type-punning, since qemu_fprintf() takes NULL instead of the current monitor cast to FILE *. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190417191805.28198-15-armbru@redhat.com>
2019-04-17 22:18:02 +03:00
qemu_fprintf(f, "\n");
target/riscv: Honor CPU_DUMP_FPU Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Reviewed-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2018-05-11 06:31:33 +03:00
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
}
target/riscv: Add RVV registers to log Print RvV extension register to log if VPU option is enabled. Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230629083730.386604-1-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-29 11:37:30 +03:00
if (riscv_has_ext(env, RVV) && (flags & CPU_DUMP_VPU)) {
static const int dump_rvv_csrs[] = {
CSR_VSTART,
CSR_VXSAT,
CSR_VXRM,
CSR_VCSR,
CSR_VL,
CSR_VTYPE,
CSR_VLENB,
};
target/riscv: cpu: Fixup local variables shadowing Local variables shadowing other local variables or parameters make the code needlessly hard to understand. Bugs love to hide in such code. Evidence: "[PATCH v3 1/7] migration/rdma: Fix save_page method to fail on polling error". This patch removes the local variable shadowing. Tested by adding: --extra-cflags='-Wshadow=local -Wno-error=shadow=local -Wno-error=shadow=compatible-local' To configure Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925043023.71448-3-alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2023-09-25 07:30:21 +03:00
for (i = 0; i < ARRAY_SIZE(dump_rvv_csrs); ++i) {
target/riscv: Add RVV registers to log Print RvV extension register to log if VPU option is enabled. Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230629083730.386604-1-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-29 11:37:30 +03:00
int csrno = dump_rvv_csrs[i];
target_ulong val = 0;
RISCVException res = riscv_csrrw_debug(env, csrno, &val, 0, 0);
/*
* Rely on the smode, hmode, etc, predicates within csr.c
* to do the filtering of the registers that are present.
*/
if (res == RISCV_EXCP_NONE) {
qemu_fprintf(f, " %-8s " TARGET_FMT_lx "\n",
csr_ops[csrno].name, val);
}
}
uint16_t vlenb = cpu->cfg.vlen >> 3;
for (i = 0; i < 32; i++) {
qemu_fprintf(f, " %-8s ", riscv_rvv_regnames[i]);
p = (uint8_t *)env->vreg;
for (j = vlenb - 1 ; j >= 0; j--) {
qemu_fprintf(f, "%02x", *(p + i * vlenb + BYTE(j)));
}
qemu_fprintf(f, "\n");
}
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
static void riscv_cpu_set_pc(CPUState *cs, vaddr value)
{
RISCVCPU *cpu = RISCV_CPU(cs);
CPURISCVState *env = &cpu->env;
target/riscv: Extend pc for runtime pc write In some cases, we must restore the guest PC to the address of the start of the TB, such as when the instruction counter hits zero. So extend pc register according to current xlen for these cases. Signed-off-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220120122050.41546-8-zhiwei_liu@c-sky.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-20 15:20:34 +03:00
if (env->xl == MXL_RV32) {
env->pc = (int32_t)value;
} else {
env->pc = value;
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
hw/core: Add CPUClass.get_pc Populate this new method for all targets. Always match the result that would be given by cpu_get_tb_cpu_state, as we will want these values to correspond in the logs. Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (target/sparc) Signed-off-by: Richard Henderson <richard.henderson@linaro.org> --- Cc: Eduardo Habkost <eduardo@habkost.net> (supporter:Machine core) Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> (supporter:Machine core) Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org> (reviewer:Machine core) Cc: Yanan Wang <wangyanan55@huawei.com> (reviewer:Machine core) Cc: Michael Rolnik <mrolnik@gmail.com> (maintainer:AVR TCG CPUs) Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> (maintainer:CRIS TCG CPUs) Cc: Taylor Simpson <tsimpson@quicinc.com> (supporter:Hexagon TCG CPUs) Cc: Song Gao <gaosong@loongson.cn> (maintainer:LoongArch TCG CPUs) Cc: Xiaojuan Yang <yangxiaojuan@loongson.cn> (maintainer:LoongArch TCG CPUs) Cc: Laurent Vivier <laurent@vivier.eu> (maintainer:M68K TCG CPUs) Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> (reviewer:MIPS TCG CPUs) Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com> (reviewer:MIPS TCG CPUs) Cc: Chris Wulff <crwulff@gmail.com> (maintainer:NiosII TCG CPUs) Cc: Marek Vasut <marex@denx.de> (maintainer:NiosII TCG CPUs) Cc: Stafford Horne <shorne@gmail.com> (odd fixer:OpenRISC TCG CPUs) Cc: Yoshinori Sato <ysato@users.sourceforge.jp> (reviewer:RENESAS RX CPUs) Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (maintainer:SPARC TCG CPUs) Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> (maintainer:TriCore TCG CPUs) Cc: Max Filippov <jcmvbkbc@gmail.com> (maintainer:Xtensa TCG CPUs) Cc: qemu-arm@nongnu.org (open list:ARM TCG CPUs) Cc: qemu-ppc@nongnu.org (open list:PowerPC TCG CPUs) Cc: qemu-riscv@nongnu.org (open list:RISC-V TCG CPUs) Cc: qemu-s390x@nongnu.org (open list:S390 TCG CPUs)
2022-09-30 20:31:21 +03:00
static vaddr riscv_cpu_get_pc(CPUState *cs)
{
RISCVCPU *cpu = RISCV_CPU(cs);
CPURISCVState *env = &cpu->env;
/* Match cpu_get_tb_cpu_state. */
if (env->xl == MXL_RV32) {
return env->pc & UINT32_MAX;
}
return env->pc;
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
static bool riscv_cpu_has_work(CPUState *cs)
{
#ifndef CONFIG_USER_ONLY
RISCVCPU *cpu = RISCV_CPU(cs);
CPURISCVState *env = &cpu->env;
/*
* Definition of the WFI instruction requires it to ignore the privilege
* mode and delegation registers, but respect individual enables
*/
target/riscv: Wake on VS-level external interrupts Whether or not VSEIP is pending isn't reflected in env->mip and must instead be determined from hstatus.vgein and hgeip. As a result a CPU in WFI won't wake on a VSEIP, which violates the WFI behavior as specified in the privileged ISA. Just use riscv_cpu_all_pending() instead, which already accounts for VSEIP. Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220531210544.181322-1-abrestic@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-01 00:05:44 +03:00
return riscv_cpu_all_pending(env) != 0;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#else
return true;
#endif
}
target/riscv: Convert to 3-phase reset Convert the riscv CPU class to use 3-phase reset, so it doesn't need to use device_class_set_parent_reset() any more. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Edgar E. Iglesias <edgar@zeroasic.com> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-id: 20221124115023.2437291-15-peter.maydell@linaro.org
2022-11-24 14:50:17 +03:00
static void riscv_cpu_reset_hold(Object *obj)
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
{
target/riscv: Implement AIA local interrupt priorities The AIA spec defines programmable 8-bit priority for each local interrupt at M-level, S-level and VS-level so we extend local interrupt processing to consider AIA interrupt priorities. The AIA CSRs which help software configure local interrupt priorities will be added by subsequent patches. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220204174700.534953-10-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:45 +03:00
#ifndef CONFIG_USER_ONLY
uint8_t iprio;
int i, irq, rdzero;
#endif
target/riscv: Convert to 3-phase reset Convert the riscv CPU class to use 3-phase reset, so it doesn't need to use device_class_set_parent_reset() any more. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Edgar E. Iglesias <edgar@zeroasic.com> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-id: 20221124115023.2437291-15-peter.maydell@linaro.org
2022-11-24 14:50:17 +03:00
CPUState *cs = CPU(obj);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
RISCVCPU *cpu = RISCV_CPU(cs);
RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
CPURISCVState *env = &cpu->env;
target/riscv: Convert to 3-phase reset Convert the riscv CPU class to use 3-phase reset, so it doesn't need to use device_class_set_parent_reset() any more. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Edgar E. Iglesias <edgar@zeroasic.com> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-id: 20221124115023.2437291-15-peter.maydell@linaro.org
2022-11-24 14:50:17 +03:00
if (mcc->parent_phases.hold) {
mcc->parent_phases.hold(obj);
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#ifndef CONFIG_USER_ONLY
target/riscv: Split misa.mxl and misa.ext The hw representation of misa.mxl is at the high bits of the misa csr. Representing this in the same way inside QEMU results in overly complex code trying to check that field. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-4-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:57 +03:00
env->misa_mxl = env->misa_mxl_max;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
env->priv = PRV_M;
env->mstatus &= ~(MSTATUS_MIE | MSTATUS_MPRV);
target/riscv: Add MXL/SXL/UXL to TB_FLAGS Begin adding support for switching XLEN at runtime. Extract the effective XLEN from MISA and MSTATUS and store for use during translation. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-6-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:59 +03:00
if (env->misa_mxl > MXL_RV32) {
/*
* The reset status of SXL/UXL is undefined, but mstatus is WARL
* and we must ensure that the value after init is valid for read.
*/
env->mstatus = set_field(env->mstatus, MSTATUS64_SXL, env->misa_mxl);
env->mstatus = set_field(env->mstatus, MSTATUS64_UXL, env->misa_mxl);
target/riscv: Set default XLEN for hypervisor When swap regs for hypervisor, the value of vsstatus or mstatus_hs should have the right XLEN. Otherwise, it will propagate to mstatus. Signed-off-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220120122050.41546-22-zhiwei_liu@c-sky.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-20 15:20:48 +03:00
if (riscv_has_ext(env, RVH)) {
env->vsstatus = set_field(env->vsstatus,
MSTATUS64_SXL, env->misa_mxl);
env->vsstatus = set_field(env->vsstatus,
MSTATUS64_UXL, env->misa_mxl);
env->mstatus_hs = set_field(env->mstatus_hs,
MSTATUS64_SXL, env->misa_mxl);
env->mstatus_hs = set_field(env->mstatus_hs,
MSTATUS64_UXL, env->misa_mxl);
}
target/riscv: Add MXL/SXL/UXL to TB_FLAGS Begin adding support for switching XLEN at runtime. Extract the effective XLEN from MISA and MSTATUS and store for use during translation. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-6-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:59 +03:00
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
env->mcause = 0;
target/riscv: Implement SGEIP bit in hip and hie CSRs A hypervisor can optionally take guest external interrupts using SGEIP bit of hip and hie CSRs. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-3-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:38 +03:00
env->miclaim = MIP_SGEIP;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
env->pc = env->resetvec;
target/riscv: Set [m|s]tval for both illegal and virtual instruction traps Currently, the [m|s]tval CSRs are set with trapping instruction encoding only for illegal instruction traps taken at the time of instruction decoding. In RISC-V world, a valid instructions might also trap as illegal or virtual instruction based to trapping bits in various CSRs (such as mstatus.TVM or hstatus.VTVM). We improve setting of [m|s]tval CSRs for all types of illegal and virtual instruction traps. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220511144528.393530-4-apatel@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-05-11 17:45:23 +03:00
env->bins = 0;
target/riscv: Add proper two-stage lookup exception detection The current two-stage lookup detection in riscv_cpu_do_interrupt falls short of its purpose, as all it checks is whether two-stage address translation either via the hypervisor-load store instructions or the MPRV feature would be allowed. What we really need instead is whether two-stage address translation was active when the exception was raised. However, in riscv_cpu_do_interrupt we do not have the information to reliably detect this. Therefore, when we raise a memory fault exception we have to record whether two-stage address translation is active. Signed-off-by: Georg Kotheimer <georg.kotheimer@kernkonzept.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210319141459.1196741-1-georg.kotheimer@kernkonzept.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-03-19 17:14:59 +03:00
env->two_stage_lookup = false;
target/riscv: Implement AIA local interrupt priorities The AIA spec defines programmable 8-bit priority for each local interrupt at M-level, S-level and VS-level so we extend local interrupt processing to consider AIA interrupt priorities. The AIA CSRs which help software configure local interrupt priorities will be added by subsequent patches. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220204174700.534953-10-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:45 +03:00
target/riscv: Add *envcfg.HADE related check in address translation When menvcfg.HADE is 1, hardware updating of PTE A/D bits is enabled during single-stage address translation. When the hypervisor extension is implemented, if menvcfg.HADE is 1, hardware updating of PTE A/D bits is enabled during G-stage address translation. Set *envcfg.HADE default true for backward compatibility. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230224040852.37109-6-liweiwei@iscas.ac.cn> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-02-24 07:08:51 +03:00
env->menvcfg = (cpu->cfg.ext_svpbmt ? MENVCFG_PBMTE : 0) |
target/riscv: Update CSR bits name for svadu extension The Svadu specification updated the name of the *envcfg bit from HADE to ADUE. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230816141916.66898-1-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-08-16 17:19:16 +03:00
(cpu->cfg.ext_svadu ? MENVCFG_ADUE : 0);
target/riscv: Add *envcfg.HADE related check in address translation When menvcfg.HADE is 1, hardware updating of PTE A/D bits is enabled during single-stage address translation. When the hypervisor extension is implemented, if menvcfg.HADE is 1, hardware updating of PTE A/D bits is enabled during G-stage address translation. Set *envcfg.HADE default true for backward compatibility. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230224040852.37109-6-liweiwei@iscas.ac.cn> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-02-24 07:08:51 +03:00
env->henvcfg = (cpu->cfg.ext_svpbmt ? HENVCFG_PBMTE : 0) |
target/riscv: Update CSR bits name for svadu extension The Svadu specification updated the name of the *envcfg bit from HADE to ADUE. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230816141916.66898-1-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-08-16 17:19:16 +03:00
(cpu->cfg.ext_svadu ? HENVCFG_ADUE : 0);
target/riscv: Add *envcfg.PBMTE related check in address translation menvcfg.PBMTE bit controls whether the Svpbmt extension is available for use in S-mode and G-stage address translation. henvcfg.PBMTE bit controls whether the Svpbmt extension is available for use in VS-stage address translation. Set *envcfg.PBMTE default true for backward compatibility. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230224040852.37109-5-liweiwei@iscas.ac.cn> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-02-24 07:08:50 +03:00
target/riscv: Implement AIA local interrupt priorities The AIA spec defines programmable 8-bit priority for each local interrupt at M-level, S-level and VS-level so we extend local interrupt processing to consider AIA interrupt priorities. The AIA CSRs which help software configure local interrupt priorities will be added by subsequent patches. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220204174700.534953-10-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:45 +03:00
/* Initialized default priorities of local interrupts. */
for (i = 0; i < ARRAY_SIZE(env->miprio); i++) {
iprio = riscv_cpu_default_priority(i);
env->miprio[i] = (i == IRQ_M_EXT) ? 0 : iprio;
env->siprio[i] = (i == IRQ_S_EXT) ? 0 : iprio;
env->hviprio[i] = 0;
}
i = 0;
while (!riscv_cpu_hviprio_index2irq(i, &irq, &rdzero)) {
if (!rdzero) {
env->hviprio[irq] = env->miprio[irq];
}
i++;
}
target/riscv: Support CSRs required for RISC-V PM extension except for the h-mode Signed-off-by: Alexey Baturo <space.monkey.delivers@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20211025173609.2724490-4-space.monkey.delivers@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-25 20:36:04 +03:00
/* mmte is supposed to have pm.current hardwired to 1 */
target/riscv: Add a general status enum for extensions The pointer masking is the only extension that directly use status. The vector or float extension uses the status in an indirect way. Replace the pointer masking extension special status fields with the general status. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-Id: <20230324143031.1093-3-zhiwei_liu@linux.alibaba.com> [rth: Add a typedef for the enum] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Tested-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230325105429.1142530-3-richard.henderson@linaro.org> Message-Id: <20230412114333.118895-3-richard.henderson@linaro.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-12 14:43:10 +03:00
env->mmte |= (EXT_STATUS_INITIAL | MMTE_M_PM_CURRENT);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#endif
target/riscv: Create xl field in env Current xlen has been used in helper functions and many other places. The computation of current xlen is not so trivial, so that we should recompute it as little as possible. Fortunately, xlen only changes in very seldom cases, such as exception, misa write, mstatus write, cpu reset, migration load. So that we can only recompute xlen in this places and cache it into CPURISCVState. Signed-off-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220120122050.41546-6-zhiwei_liu@c-sky.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-20 15:20:32 +03:00
env->xl = riscv_cpu_mxl(env);
target/riscv: Create current pm fields in env Signed-off-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20220120122050.41546-12-zhiwei_liu@c-sky.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-20 15:20:38 +03:00
riscv_cpu_update_mask(env);
target/riscv: Convert the RISC-V exceptions to an enum Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: f191dcf08bf413a822e743a7c7f824d68879a527.1617290165.git.alistair.francis@wdc.com
2021-04-01 18:17:29 +03:00
cs->exception_index = RISCV_EXCP_NONE;
RISC-V: Clear load reservations on context switch and SC This prevents a load reservation from being placed in one context/process, then being used in another, resulting in an SC succeeding incorrectly and breaking atomics. Signed-off-by: Joel Sing <joel@sing.id.au> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-06-24 21:08:38 +03:00
env->load_res = -1;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
set_default_nan_mode(1, &env->fp_status);
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 11:13:22 +03:00
#ifndef CONFIG_USER_ONLY
target/riscv: remove RISCV_FEATURE_DEBUG RISCV_FEATURE_DEBUG will always follow the value defined by cpu->cfg.debug flag. Read the flag instead. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20230222185205.355361-5-dbarboza@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-02-22 21:51:59 +03:00
if (cpu->cfg.debug) {
target/riscv: Allocate itrigger timers only once riscv_trigger_init() had been called on reset events that can happen several times for a CPU and it allocated timers for itrigger. If old timers were present, they were simply overwritten by the new timers, resulting in a memory leak. Divide riscv_trigger_init() into two functions, namely riscv_trigger_realize() and riscv_trigger_reset() and call them in appropriate timing. The timer allocation will happen only once for a CPU in riscv_trigger_realize(). Fixes: 5a4ae64cac ("target/riscv: Add itrigger support when icount is enabled") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230818034059.9146-1-akihiko.odaki@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-08-18 06:40:58 +03:00
riscv_trigger_reset_hold(env);
target/riscv: csr: Hook debug CSR read/write This adds debug CSR read/write support to the RISC-V CSR RW table. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220421003324.1134983-4-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-04-21 03:33:21 +03: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 11:13:22 +03:00
if (kvm_enabled()) {
kvm_riscv_reset_vcpu(cpu);
}
#endif
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
static void riscv_cpu_disas_set_info(CPUState *s, disassemble_info *info)
{
target/riscv: cpu: Remove compile time XLEN checks Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Tested-by: Bin Meng <bin.meng@windriver.com> Message-id: a426ead44db5065a0790066d43e91245683509d7.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:56 +03:00
RISCVCPU *cpu = RISCV_CPU(s);
target/riscv: Use xl instead of mxl for disassemble Disassemble function(plugin_disas, target_disas, monitor_disas) will always call set_disas_info before disassembling instructions. plugin_disas and target_disas will always be called under a TB, which has the same XLEN. We can't ensure that monitor_disas will always be called under a TB, but current XLEN will still be a better choice, thus we can ensure at least the disassemble of the nearest one TB is right. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230612111034.3955227-2-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-12 14:10:27 +03:00
CPURISCVState *env = &cpu->env;
target/riscv: Pass RISCVCPUConfig as target_info to disassemble_info Pass RISCVCPUConfig as disassemble_info.target_info to support disas of conflict instructions related to specific extensions. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230523093539.203909-4-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-23 12:35:34 +03:00
info->target_info = &cpu->cfg;
target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl Shortly, the set of supported XL will not be just 32 and 64, and representing that properly using the enumeration will be imperative. Two places, booting and gdb, intentionally use misa_mxl_max to emphasize the use of the reset value of misa.mxl, and not the current cpu state. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-5-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:58 +03:00
target/riscv: Use xl instead of mxl for disassemble Disassemble function(plugin_disas, target_disas, monitor_disas) will always call set_disas_info before disassembling instructions. plugin_disas and target_disas will always be called under a TB, which has the same XLEN. We can't ensure that monitor_disas will always be called under a TB, but current XLEN will still be a better choice, thus we can ensure at least the disassemble of the nearest one TB is right. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230612111034.3955227-2-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-12 14:10:27 +03:00
switch (env->xl) {
target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl Shortly, the set of supported XL will not be just 32 and 64, and representing that properly using the enumeration will be imperative. Two places, booting and gdb, intentionally use misa_mxl_max to emphasize the use of the reset value of misa.mxl, and not the current cpu state. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-5-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:58 +03:00
case MXL_RV32:
target/riscv: cpu: Remove compile time XLEN checks Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Tested-by: Bin Meng <bin.meng@windriver.com> Message-id: a426ead44db5065a0790066d43e91245683509d7.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:56 +03:00
info->print_insn = print_insn_riscv32;
target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl Shortly, the set of supported XL will not be just 32 and 64, and representing that properly using the enumeration will be imperative. Two places, booting and gdb, intentionally use misa_mxl_max to emphasize the use of the reset value of misa.mxl, and not the current cpu state. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-5-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:58 +03:00
break;
case MXL_RV64:
target/riscv: cpu: Remove compile time XLEN checks Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Tested-by: Bin Meng <bin.meng@windriver.com> Message-id: a426ead44db5065a0790066d43e91245683509d7.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:56 +03:00
info->print_insn = print_insn_riscv64;
target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl Shortly, the set of supported XL will not be just 32 and 64, and representing that properly using the enumeration will be imperative. Two places, booting and gdb, intentionally use misa_mxl_max to emphasize the use of the reset value of misa.mxl, and not the current cpu state. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-5-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:58 +03:00
break;
target/riscv: setup everything for rv64 to support rv128 execution This patch adds the support of the '-cpu rv128' option to qemu-system-riscv64 so that we can indicate that we want to run rv128 executables. Still, there is no support for 128-bit insns at that stage so qemu fails miserably (as expected) if launched with this option. Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr> Co-authored-by: Fabien Portas <fabien.portas@grenoble-inp.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220106210108.138226-8-frederic.petrot@univ-grenoble-alpes.fr [ Changed by AF - Rename CPU to "x-rv128" ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-07 00:00:57 +03:00
case MXL_RV128:
info->print_insn = print_insn_riscv128;
break;
target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl Shortly, the set of supported XL will not be just 32 and 64, and representing that properly using the enumeration will be imperative. Two places, booting and gdb, intentionally use misa_mxl_max to emphasize the use of the reset value of misa.mxl, and not the current cpu state. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-5-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:58 +03:00
default:
g_assert_not_reached();
target/riscv: cpu: Remove compile time XLEN checks Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Tested-by: Bin Meng <bin.meng@windriver.com> Message-id: a426ead44db5065a0790066d43e91245683509d7.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:56 +03:00
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
target/riscv: move riscv_cpu_validate_set_extensions() to tcg-cpu.c This function is the core of the RISC-V validations for TCG CPUs, and it has a lot going on. Functions in cpu.c were made public to allow them to be used by the KVM accelerator class later on. 'cpu_cfg_ext_get_min_version()' is notably hard to move it to another file due to its dependency with isa_edata_arr[] array, thus make it public and use it as is for now. riscv_cpu_validate_set_extensions() is kept public because it's used by csr.c in write_misa(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:53 +03:00
void riscv_cpu_disable_priv_spec_isa_exts(RISCVCPU *cpu)
target/riscv/cpu.c: add priv_spec validate/disable_exts helpers We're doing env->priv_spec validation and assignment at the start of riscv_cpu_realize(), which is fine, but then we're doing a force disable on extensions that aren't compatible with the priv version. This second step is being done too early. The disabled extensions might be re-enabled again in riscv_cpu_validate_set_extensions() by accident. A better place to put this code is at the end of riscv_cpu_validate_set_extensions() after all the validations are completed. Add a new helper, riscv_cpu_disable_priv_spec_isa_exts(), to disable the extesions after the validation is done. While we're at it, create a riscv_cpu_validate_priv_spec() helper to host all env->priv_spec related validation to unclog riscv_cpu_realize a bit. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:10 +03:00
{
CPURISCVState *env = &cpu->env;
int i;
/* Force disable extensions if priv spec version does not match */
for (i = 0; i < ARRAY_SIZE(isa_edata_arr); i++) {
target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabled We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:16 +03:00
if (isa_ext_is_enabled(cpu, isa_edata_arr[i].ext_enable_offset) &&
target/riscv/cpu.c: add priv_spec validate/disable_exts helpers We're doing env->priv_spec validation and assignment at the start of riscv_cpu_realize(), which is fine, but then we're doing a force disable on extensions that aren't compatible with the priv version. This second step is being done too early. The disabled extensions might be re-enabled again in riscv_cpu_validate_set_extensions() by accident. A better place to put this code is at the end of riscv_cpu_validate_set_extensions() after all the validations are completed. Add a new helper, riscv_cpu_disable_priv_spec_isa_exts(), to disable the extesions after the validation is done. While we're at it, create a riscv_cpu_validate_priv_spec() helper to host all env->priv_spec related validation to unclog riscv_cpu_realize a bit. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:10 +03:00
(env->priv_ver < isa_edata_arr[i].min_version)) {
target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabled We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:16 +03:00
isa_ext_update_enabled(cpu, isa_edata_arr[i].ext_enable_offset,
false);
target/riscv/cpu.c: add priv_spec validate/disable_exts helpers We're doing env->priv_spec validation and assignment at the start of riscv_cpu_realize(), which is fine, but then we're doing a force disable on extensions that aren't compatible with the priv version. This second step is being done too early. The disabled extensions might be re-enabled again in riscv_cpu_validate_set_extensions() by accident. A better place to put this code is at the end of riscv_cpu_validate_set_extensions() after all the validations are completed. Add a new helper, riscv_cpu_disable_priv_spec_isa_exts(), to disable the extesions after the validation is done. While we're at it, create a riscv_cpu_validate_priv_spec() helper to host all env->priv_spec related validation to unclog riscv_cpu_realize a bit. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230517135714.211809-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-17 16:57:10 +03:00
#ifndef CONFIG_USER_ONLY
warn_report("disabling %s extension for hart 0x" TARGET_FMT_lx
" because privilege spec version does not match",
isa_edata_arr[i].name, env->mhartid);
#else
warn_report("disabling %s extension because "
"privilege spec version does not match",
isa_edata_arr[i].name);
#endif
}
}
}
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
#ifndef CONFIG_USER_ONLY
static void riscv_cpu_satp_mode_finalize(RISCVCPU *cpu, Error **errp)
{
bool rv32 = riscv_cpu_mxl(&cpu->env) == MXL_RV32;
target/riscv: fix satp_mode_finalize() when satp_mode.supported = 0 In the same emulated RISC-V host, the 'host' KVM CPU takes 4 times longer to boot than the 'rv64' KVM CPU. The reason is an unintended behavior of riscv_cpu_satp_mode_finalize() when satp_mode.supported = 0, i.e. when cpu_init() does not set satp_mode_max_supported(). satp_mode_max_from_map(map) does: 31 - __builtin_clz(map) This means that, if satp_mode.supported = 0, satp_mode_supported_max wil be '31 - 32'. But this is C, so satp_mode_supported_max will gladly set it to UINT_MAX (4294967295). After that, if the user didn't set a satp_mode, set_satp_mode_default_map(cpu) will make cfg.satp_mode.map = cfg.satp_mode.supported So satp_mode.map = 0. And then satp_mode_map_max will be set to satp_mode_max_from_map(cpu->cfg.satp_mode.map), i.e. also UINT_MAX. The guard "satp_mode_map_max > satp_mode_supported_max" doesn't protect us here since both are UINT_MAX. And finally we have 2 loops: for (int i = satp_mode_map_max - 1; i >= 0; --i) { Which are, in fact, 2 loops from UINT_MAX -1 to -1. This is where the extra delay when booting the 'host' CPU is coming from. Commit 43d1de32f8 already set a precedence for satp_mode.supported = 0 in a different manner. We're doing the same here. If supported == 0, interpret as 'the CPU wants the OS to handle satp mode alone' and skip satp_mode_finalize(). We'll also put a guard in satp_mode_max_from_map() to assert out if map is 0 since the function is not ready to deal with it. Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Fixes: 6f23aaeb9b ("riscv: Allow user to set the satp mode") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230817152903.694926-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-08-17 18:29:03 +03:00
uint8_t satp_mode_map_max, satp_mode_supported_max;
/* The CPU wants the OS to decide which satp mode to use */
if (cpu->cfg.satp_mode.supported == 0) {
return;
}
satp_mode_supported_max =
satp_mode_max_from_map(cpu->cfg.satp_mode.supported);
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
if (cpu->cfg.satp_mode.map == 0) {
if (cpu->cfg.satp_mode.init == 0) {
/* If unset by the user, we fallback to the default satp mode. */
set_satp_mode_default_map(cpu);
} else {
/*
* Find the lowest level that was disabled and then enable the
* first valid level below which can be found in
* valid_vm_1_10_32/64.
*/
for (int i = 1; i < 16; ++i) {
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
if ((cpu->cfg.satp_mode.init & (1 << i)) &&
(cpu->cfg.satp_mode.supported & (1 << i))) {
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
for (int j = i - 1; j >= 0; --j) {
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
if (cpu->cfg.satp_mode.supported & (1 << j)) {
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
cpu->cfg.satp_mode.map |= (1 << j);
break;
}
}
break;
}
}
}
}
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
satp_mode_map_max = satp_mode_max_from_map(cpu->cfg.satp_mode.map);
/* Make sure the user asked for a supported configuration (HW and qemu) */
if (satp_mode_map_max > satp_mode_supported_max) {
error_setg(errp, "satp_mode %s is higher than hw max capability %s",
satp_mode_str(satp_mode_map_max, rv32),
satp_mode_str(satp_mode_supported_max, rv32));
return;
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
}
/*
* Make sure the user did not ask for an invalid configuration as per
* the specification.
*/
if (!rv32) {
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
for (int i = satp_mode_map_max - 1; i >= 0; --i) {
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
if (!(cpu->cfg.satp_mode.map & (1 << i)) &&
(cpu->cfg.satp_mode.init & (1 << i)) &&
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
(cpu->cfg.satp_mode.supported & (1 << i))) {
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
error_setg(errp, "cannot disable %s satp mode if %s "
"is enabled", satp_mode_str(i, false),
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
satp_mode_str(satp_mode_map_max, false));
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
return;
}
}
}
/* Finally expand the map so that all valid modes are set */
riscv: Introduce satp mode hw capabilities Currently, the max satp mode is set with the only constraint that it must be implemented in QEMU, i.e. set in valid_vm_1_10_[32|64]. But we actually need to add another level of constraint: what the hw is actually capable of, because currently, a linux booting on a sifive-u54 boots in sv57 mode which is incompatible with the cpu's sv39 max capability. So add a new bitmap to RISCVSATPMap which contains this capability and initialize it in every XXX_cpu_init. Finally: - valid_vm_1_10_[32|64] constrains which satp mode the CPU can use - the CPU hw capabilities constrains what the user may select - the user's selection then constrains what's available to the guest OS. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230303131252.892893-5-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:51 +03:00
for (int i = satp_mode_map_max - 1; i >= 0; --i) {
if (cpu->cfg.satp_mode.supported & (1 << i)) {
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
cpu->cfg.satp_mode.map |= (1 << i);
}
}
}
#endif
static void riscv_cpu_finalize_features(RISCVCPU *cpu, Error **errp)
{
#ifndef CONFIG_USER_ONLY
Error *local_err = NULL;
riscv_cpu_satp_mode_finalize(cpu, &local_err);
if (local_err != NULL) {
error_propagate(errp, local_err);
return;
}
#endif
}
target/riscv: skip features setup for KVM CPUs As it is today it's not possible to use '-cpu host' if the RISC-V host has RVH enabled. This is the resulting error: $ ./qemu/build/qemu-system-riscv64 \ -machine virt,accel=kvm -m 2G -smp 1 \ -nographic -snapshot -kernel ./guest_imgs/Image \ -initrd ./guest_imgs/rootfs_kvm_riscv64.img \ -append "earlycon=sbi root=/dev/ram rw" \ -cpu host qemu-system-riscv64: H extension requires priv spec 1.12.0 This happens because we're checking for priv spec for all CPUs, and since we're not setting env->priv_ver for the 'host' CPU, it's being default to zero (i.e. PRIV_SPEC_1_10_0). In reality env->priv_ver does not make sense when running with the KVM 'host' CPU. It's used to gate certain CSRs/extensions during translation to make them unavailable if the hart declares an older spec version. It doesn't have any other use. E.g. OpenSBI version 1.2 retrieves the spec checking if the CSR_MCOUNTEREN, CSR_MCOUNTINHIBIT and CSR_MENVCFG CSRs are available [1]. 'priv_ver' is just one example. We're doing a lot of feature validation and setup during riscv_cpu_realize() that it doesn't apply to KVM CPUs. Validating the feature set for those CPUs is a KVM problem that should be handled in KVM specific code. The new riscv_cpu_realize_tcg() helper contains all validation logic that are applicable to TCG CPUs only. riscv_cpu_realize() verifies if we're running TCG and, if it's the case, proceed with the usual TCG realize() logic. [1] lib/sbi/sbi_hart.c, hart_detect_features() 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-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:19 +03:00
static void riscv_cpu_realize(DeviceState *dev, Error **errp)
{
CPUState *cs = CPU(dev);
RISCVCPU *cpu = RISCV_CPU(dev);
RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(dev);
Error *local_err = NULL;
target/riscv: deprecate the 'any' CPU type The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU Core Definition"), being around since the beginning. It's not an easy CPU to use: it's undocumented and its name doesn't tell users much about what the CPU is supposed to bring. 'git log' doesn't help us either in knowing what was the original design of this CPU type. The closest we have is a comment from Alistair [1] where he recalls from memory that the 'any' CPU is supposed to behave like the newly added 'max' CPU. He also suggested that the 'any' CPU should be removed. The default CPUs are rv32 and rv64, so removing the 'any' CPU will have impact only on users that might have a script that uses '-cpu any'. And those users are better off using the default CPUs or the new 'max' CPU. We would love to just remove the code and be done with it, but one does not simply remove a feature in QEMU. We'll put the CPU in quarantine first, letting users know that we have the intent of removing it in the future. [1] https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02891.html 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> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:15 +03:00
if (object_dynamic_cast(OBJECT(dev), TYPE_RISCV_CPU_ANY) != NULL) {
warn_report("The 'any' CPU is deprecated and will be "
"removed in the future.");
}
target/riscv: skip features setup for KVM CPUs As it is today it's not possible to use '-cpu host' if the RISC-V host has RVH enabled. This is the resulting error: $ ./qemu/build/qemu-system-riscv64 \ -machine virt,accel=kvm -m 2G -smp 1 \ -nographic -snapshot -kernel ./guest_imgs/Image \ -initrd ./guest_imgs/rootfs_kvm_riscv64.img \ -append "earlycon=sbi root=/dev/ram rw" \ -cpu host qemu-system-riscv64: H extension requires priv spec 1.12.0 This happens because we're checking for priv spec for all CPUs, and since we're not setting env->priv_ver for the 'host' CPU, it's being default to zero (i.e. PRIV_SPEC_1_10_0). In reality env->priv_ver does not make sense when running with the KVM 'host' CPU. It's used to gate certain CSRs/extensions during translation to make them unavailable if the hart declares an older spec version. It doesn't have any other use. E.g. OpenSBI version 1.2 retrieves the spec checking if the CSR_MCOUNTEREN, CSR_MCOUNTINHIBIT and CSR_MENVCFG CSRs are available [1]. 'priv_ver' is just one example. We're doing a lot of feature validation and setup during riscv_cpu_realize() that it doesn't apply to KVM CPUs. Validating the feature set for those CPUs is a KVM problem that should be handled in KVM specific code. The new riscv_cpu_realize_tcg() helper contains all validation logic that are applicable to TCG CPUs only. riscv_cpu_realize() verifies if we're running TCG and, if it's the case, proceed with the usual TCG realize() logic. [1] lib/sbi/sbi_hart.c, hart_detect_features() 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-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:19 +03:00
cpu_exec_realizefn(cs, &local_err);
if (local_err != NULL) {
error_propagate(errp, local_err);
return;
}
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
riscv_cpu_finalize_features(cpu, &local_err);
if (local_err != NULL) {
error_propagate(errp, local_err);
return;
}
RISC-V: Add hooks to use the gdb xml files. The gdb CSR xml file has registers in documentation order, not numerical order, so we need a table to map the register numbers. This also adds fairly standard gdb hooks to access xml specified registers. notice: The fpu xml from gdb 8.3 has unused register #, 65 and make first csr register # become 69. We register extra register on gdb to correct csr offset calculation Signed-off-by: Jim Wilson <jimw@sifive.com> Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-03-15 13:26:59 +03:00
riscv_cpu_register_gdb_regs_for_features(cs);
target/riscv: Allocate itrigger timers only once riscv_trigger_init() had been called on reset events that can happen several times for a CPU and it allocated timers for itrigger. If old timers were present, they were simply overwritten by the new timers, resulting in a memory leak. Divide riscv_trigger_init() into two functions, namely riscv_trigger_realize() and riscv_trigger_reset() and call them in appropriate timing. The timer allocation will happen only once for a CPU in riscv_trigger_realize(). Fixes: 5a4ae64cac ("target/riscv: Add itrigger support when icount is enabled") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230818034059.9146-1-akihiko.odaki@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-08-18 06:40:58 +03:00
#ifndef CONFIG_USER_ONLY
if (cpu->cfg.debug) {
riscv_trigger_realize(&cpu->env);
}
#endif
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
qemu_init_vcpu(cs);
cpu_reset(cs);
mcc->parent_realize(dev, errp);
}
target/riscv: Expose interrupt pending bits as GPIO lines Expose the 12 interrupt pending bits in MIP as GPIO lines. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 069d6162f0bc2f4a4f5a44e73f6442b11c703c53.1630301632.git.alistair.francis@wdc.com
2021-08-30 08:34:20 +03:00
#ifndef CONFIG_USER_ONLY
riscv: Allow user to set the satp mode RISC-V specifies multiple sizes for addressable memory and Linux probes for the machine's support at startup via the satp CSR register (done in csr.c:validate_vm). As per the specification, sv64 must support sv57, which in turn must support sv48...etc. So we can restrict machine support by simply setting the "highest" supported mode and the bare mode is always supported. You can set the satp mode using the new properties "sv32", "sv39", "sv48", "sv57" and "sv64" as follows: -cpu rv64,sv57=on # Linux will boot using sv57 scheme -cpu rv64,sv39=on # Linux will boot using sv39 scheme -cpu rv64,sv57=off # Linux will boot using sv48 scheme -cpu rv64 # Linux will boot using sv57 scheme by default We take the highest level set by the user: -cpu rv64,sv48=on,sv57=on # Linux will boot using sv57 scheme We make sure that invalid configurations are rejected: -cpu rv64,sv39=off,sv48=on # sv39 must be supported if higher modes are # enabled We accept "redundant" configurations: -cpu rv64,sv48=on,sv57=off # Linux will boot using sv48 scheme And contradictory configurations: -cpu rv64,sv48=on,sv48=off # Linux will boot using sv39 scheme Co-Developed-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Ludovic Henry <ludovic@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-ID: <20230303131252.892893-4-alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 16:12:50 +03:00
static void cpu_riscv_get_satp(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVSATPMap *satp_map = opaque;
uint8_t satp = satp_mode_from_str(name);
bool value;
value = satp_map->map & (1 << satp);
visit_type_bool(v, name, &value, errp);
}
static void cpu_riscv_set_satp(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVSATPMap *satp_map = opaque;
uint8_t satp = satp_mode_from_str(name);
bool value;
if (!visit_type_bool(v, name, &value, errp)) {
return;
}
satp_map->map = deposit32(satp_map->map, satp, 1, value);
satp_map->init |= 1 << satp;
}
static void riscv_add_satp_mode_properties(Object *obj)
{
RISCVCPU *cpu = RISCV_CPU(obj);
if (cpu->env.misa_mxl == MXL_RV32) {
object_property_add(obj, "sv32", "bool", cpu_riscv_get_satp,
cpu_riscv_set_satp, NULL, &cpu->cfg.satp_mode);
} else {
object_property_add(obj, "sv39", "bool", cpu_riscv_get_satp,
cpu_riscv_set_satp, NULL, &cpu->cfg.satp_mode);
object_property_add(obj, "sv48", "bool", cpu_riscv_get_satp,
cpu_riscv_set_satp, NULL, &cpu->cfg.satp_mode);
object_property_add(obj, "sv57", "bool", cpu_riscv_get_satp,
cpu_riscv_set_satp, NULL, &cpu->cfg.satp_mode);
object_property_add(obj, "sv64", "bool", cpu_riscv_get_satp,
cpu_riscv_set_satp, NULL, &cpu->cfg.satp_mode);
}
}
target/riscv: Expose interrupt pending bits as GPIO lines Expose the 12 interrupt pending bits in MIP as GPIO lines. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 069d6162f0bc2f4a4f5a44e73f6442b11c703c53.1630301632.git.alistair.francis@wdc.com
2021-08-30 08:34:20 +03:00
static void riscv_cpu_set_irq(void *opaque, int irq, int level)
{
RISCVCPU *cpu = RISCV_CPU(opaque);
target/riscv: Implement hgeie and hgeip CSRs The hgeie and hgeip CSRs are required for emulating an external interrupt controller capable of injecting virtual external interrupt to Guest/VM running at VS-level. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-4-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:39 +03:00
CPURISCVState *env = &cpu->env;
target/riscv: Expose interrupt pending bits as GPIO lines Expose the 12 interrupt pending bits in MIP as GPIO lines. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 069d6162f0bc2f4a4f5a44e73f6442b11c703c53.1630301632.git.alistair.francis@wdc.com
2021-08-30 08:34:20 +03:00
target/riscv: Implement hgeie and hgeip CSRs The hgeie and hgeip CSRs are required for emulating an external interrupt controller capable of injecting virtual external interrupt to Guest/VM running at VS-level. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-4-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:39 +03:00
if (irq < IRQ_LOCAL_MAX) {
switch (irq) {
case IRQ_U_SOFT:
case IRQ_S_SOFT:
case IRQ_VS_SOFT:
case IRQ_M_SOFT:
case IRQ_U_TIMER:
case IRQ_S_TIMER:
case IRQ_VS_TIMER:
case IRQ_M_TIMER:
case IRQ_U_EXT:
case IRQ_VS_EXT:
case IRQ_M_EXT:
target/riscv: cpu: Fixup indentation Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220317061817.3856850-2-alistair.francis@opensource.wdc.com>
2022-03-17 09:18:16 +03:00
if (kvm_enabled()) {
target/riscv: Implement hgeie and hgeip CSRs The hgeie and hgeip CSRs are required for emulating an external interrupt controller capable of injecting virtual external interrupt to Guest/VM running at VS-level. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-4-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:39 +03:00
kvm_riscv_set_irq(cpu, irq, level);
target/riscv: cpu: Fixup indentation Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220317061817.3856850-2-alistair.francis@opensource.wdc.com>
2022-03-17 09:18:16 +03:00
} else {
target/riscv: Simplify type conversion for CPURISCVState Use CPURISCVState as argument directly in riscv_cpu_update_mip and riscv_timer_write_timecmp, since type converts from CPURISCVState to RISCVCPU in many caller of them and then back to CPURISCVState in them. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230309071329.45932-4-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-03-09 10:13:28 +03:00
riscv_cpu_update_mip(env, 1 << irq, BOOL_TO_MASK(level));
target/riscv: cpu: Fixup indentation Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220317061817.3856850-2-alistair.francis@opensource.wdc.com>
2022-03-17 09:18:16 +03:00
}
target/riscv: Implement hgeie and hgeip CSRs The hgeie and hgeip CSRs are required for emulating an external interrupt controller capable of injecting virtual external interrupt to Guest/VM running at VS-level. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-4-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:39 +03:00
break;
target/riscv: Allow software access to MIP SEIP The RISC-V specification states that: "Supervisor-level external interrupts are made pending based on the logical-OR of the software-writable SEIP bit and the signal from the external interrupt controller." We currently only allow either the interrupt controller or software to set the bit, which is incorrect. This patch removes the miclaim mask when writing MIP to allow M-mode software to inject interrupts, even with an interrupt controller. We then also need to keep track of which source is setting MIP_SEIP. The final value is a OR of both, so we add two bools and use that to keep track of the current state. This way either source can change without losing the correct value. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/904 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220317061817.3856850-3-alistair.francis@opensource.wdc.com>
2022-03-17 09:18:17 +03:00
case IRQ_S_EXT:
if (kvm_enabled()) {
kvm_riscv_set_irq(cpu, irq, level);
} else {
env->external_seip = level;
target/riscv: Simplify type conversion for CPURISCVState Use CPURISCVState as argument directly in riscv_cpu_update_mip and riscv_timer_write_timecmp, since type converts from CPURISCVState to RISCVCPU in many caller of them and then back to CPURISCVState in them. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230309071329.45932-4-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-03-09 10:13:28 +03:00
riscv_cpu_update_mip(env, 1 << irq,
target/riscv: Allow software access to MIP SEIP The RISC-V specification states that: "Supervisor-level external interrupts are made pending based on the logical-OR of the software-writable SEIP bit and the signal from the external interrupt controller." We currently only allow either the interrupt controller or software to set the bit, which is incorrect. This patch removes the miclaim mask when writing MIP to allow M-mode software to inject interrupts, even with an interrupt controller. We then also need to keep track of which source is setting MIP_SEIP. The final value is a OR of both, so we add two bools and use that to keep track of the current state. This way either source can change without losing the correct value. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/904 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20220317061817.3856850-3-alistair.francis@opensource.wdc.com>
2022-03-17 09:18:17 +03:00
BOOL_TO_MASK(level | env->software_seip));
}
break;
target/riscv: Implement hgeie and hgeip CSRs The hgeie and hgeip CSRs are required for emulating an external interrupt controller capable of injecting virtual external interrupt to Guest/VM running at VS-level. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-4-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:39 +03:00
default:
g_assert_not_reached();
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 11:13:23 +03:00
}
target/riscv: Implement hgeie and hgeip CSRs The hgeie and hgeip CSRs are required for emulating an external interrupt controller capable of injecting virtual external interrupt to Guest/VM running at VS-level. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-4-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:39 +03:00
} else if (irq < (IRQ_LOCAL_MAX + IRQ_LOCAL_GUEST_MAX)) {
/* Require H-extension for handling guest local interrupts */
if (!riscv_has_ext(env, RVH)) {
g_assert_not_reached();
}
/* Compute bit position in HGEIP CSR */
irq = irq - IRQ_LOCAL_MAX + 1;
if (env->geilen < irq) {
g_assert_not_reached();
}
/* Update HGEIP CSR */
env->hgeip &= ~((target_ulong)1 << irq);
if (level) {
env->hgeip |= (target_ulong)1 << irq;
}
/* Update mip.SGEIP bit */
target/riscv: Simplify type conversion for CPURISCVState Use CPURISCVState as argument directly in riscv_cpu_update_mip and riscv_timer_write_timecmp, since type converts from CPURISCVState to RISCVCPU in many caller of them and then back to CPURISCVState in them. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230309071329.45932-4-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-03-09 10:13:28 +03:00
riscv_cpu_update_mip(env, MIP_SGEIP,
target/riscv: Implement hgeie and hgeip CSRs The hgeie and hgeip CSRs are required for emulating an external interrupt controller capable of injecting virtual external interrupt to Guest/VM running at VS-level. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-4-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:39 +03:00
BOOL_TO_MASK(!!(env->hgeie & env->hgeip)));
} else {
target/riscv: Expose interrupt pending bits as GPIO lines Expose the 12 interrupt pending bits in MIP as GPIO lines. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 069d6162f0bc2f4a4f5a44e73f6442b11c703c53.1630301632.git.alistair.francis@wdc.com
2021-08-30 08:34:20 +03:00
g_assert_not_reached();
}
}
#endif /* CONFIG_USER_ONLY */
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
static void riscv_cpu_init(Object *obj)
{
target/riscv: Expose interrupt pending bits as GPIO lines Expose the 12 interrupt pending bits in MIP as GPIO lines. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 069d6162f0bc2f4a4f5a44e73f6442b11c703c53.1630301632.git.alistair.francis@wdc.com
2021-08-30 08:34:20 +03:00
#ifndef CONFIG_USER_ONLY
accel/tcg: Remove cpu_set_cpustate_pointers This function is now empty, so remove it. In the case of m68k and tricore, this empties the class instance initfn, so remove those as well. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-09-14 03:36:27 +03:00
qdev_init_gpio_in(DEVICE(obj), riscv_cpu_set_irq,
target/riscv: Implement hgeie and hgeip CSRs The hgeie and hgeip CSRs are required for emulating an external interrupt controller capable of injecting virtual external interrupt to Guest/VM running at VS-level. Signed-off-by: Anup Patel <anup.patel@wdc.com> Signed-off-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Message-id: 20220204174700.534953-4-anup@brainfault.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-04 20:46:39 +03:00
IRQ_LOCAL_MAX + IRQ_LOCAL_GUEST_MAX);
target/riscv: Expose interrupt pending bits as GPIO lines Expose the 12 interrupt pending bits in MIP as GPIO lines. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 069d6162f0bc2f4a4f5a44e73f6442b11c703c53.1630301632.git.alistair.francis@wdc.com
2021-08-30 08:34:20 +03:00
#endif /* CONFIG_USER_ONLY */
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
multi_ext_user_opts = g_hash_table_new(NULL, g_direct_equal);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
target/riscv: introduce riscv_cpu_add_misa_properties() Ever since RISCVCPUConfig got introduced users are able to set CPU extensions in the command line. User settings are reflected in the cpu->cfg object for later use. These properties are used in the target/riscv/cpu.c code, most notably in riscv_cpu_validate_set_extensions(), where most of our realize time validations are made. And then there's env->misa_ext, the field where the MISA extensions are set, that is read everywhere else. We need to keep env->misa_ext updated with cpu->cfg settings, since our validations rely on it, forcing us to make register_cpu_props() write cpu->cfg.ext_N flags to cover for named CPUs that aren't used named properties but also needs to go through the same validation steps. Failing to so will make those name CPUs fail validation (see c66ffcd5358b for more info). Not only that, but we also need to sync env->misa_ext with cpu->cfg again during realize() time to catch any change the user might have done, since the rest of the code relies on that. Making cpu->cfg.ext_N and env->misa_ext reflect each other is not needed. What we want is a way for users to enable/disable MISA extensions, and there's nothing stopping us from letting the user write env->misa_ext directly. Here are the artifacts that will enable us to do that: - RISCVCPUMisaExtConfig will declare each MISA property; - cpu_set_misa_ext_cfg() is the setter for each property. We'll write env->misa_ext and env->misa_ext_mask with the appropriate misa_bit; cutting off cpu->cfg.ext_N from the logic; - cpu_get_misa_ext_cfg() is a getter that will retrieve the current val of the property based on env->misa_ext; - riscv_cpu_add_misa_properties() will be called in register_cpu_props() to init all MISA properties from the misa_ext_cfgs[] array. With this infrastructure we'll start to get rid of each cpu->cfg.ext_N attribute in the next patches. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:35 +03:00
typedef struct RISCVCPUMisaExtConfig {
const char *name;
const char *description;
target_ulong misa_bit;
bool enabled;
} RISCVCPUMisaExtConfig;
static void cpu_set_misa_ext_cfg(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
const RISCVCPUMisaExtConfig *misa_ext_cfg = opaque;
target_ulong misa_bit = misa_ext_cfg->misa_bit;
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
bool value;
if (!visit_type_bool(v, name, &value, errp)) {
return;
}
if (value) {
env->misa_ext |= misa_bit;
env->misa_ext_mask |= misa_bit;
} else {
env->misa_ext &= ~misa_bit;
env->misa_ext_mask &= ~misa_bit;
}
}
static void cpu_get_misa_ext_cfg(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
const RISCVCPUMisaExtConfig *misa_ext_cfg = opaque;
target_ulong misa_bit = misa_ext_cfg->misa_bit;
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
bool value;
value = env->misa_ext & misa_bit;
visit_type_bool(v, name, &value, errp);
}
target/riscv/cpu: add misa_ext_info_arr[] Next patch will add KVM specific user properties for both MISA and multi-letter extensions. For MISA extensions we want to make use of what is already available in misa_ext_cfgs[] to avoid code repetition. misa_ext_info_arr[] array will hold name and description for each MISA extension that misa_ext_cfgs[] is declaring. We'll then use this new array in KVM code to avoid duplicating strings. Two getters were added to allow KVM to retrieve the 'name' and 'description' for each MISA property. There's nothing holding us back from doing the same with multi-letter extensions. For now doing just with MISA extensions is enough. It is worth documenting that even using the __bultin_ctz() directive to populate the misa_ext_info_arr[] we are forced to assign 'name' and 'description' during runtime in riscv_cpu_add_misa_properties(). The reason is that some Gitlab runners ('clang-user' and 'tsan-build') will throw errors like this if we fetch 'name' and 'description' from the array in the MISA_CFG() macro: ../target/riscv/cpu.c:1624:5: error: initializer element is not a compile-time constant MISA_CFG(RVA, true), ^~~~~~~~~~~~~~~~~~~ ../target/riscv/cpu.c:1619:53: note: expanded from macro 'MISA_CFG' {.name = misa_ext_info_arr[MISA_INFO_IDX(_bit)].name, \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ gcc and others compilers/builders were fine with that change. We can't ignore failures in the Gitlab pipeline though, so code was changed to make every runner happy. As a side effect, misa_ext_cfg[] is no longer a 'const' array because it must be set during runtime. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:29 +03:00
typedef struct misa_ext_info {
const char *name;
const char *description;
} MISAExtInfo;
#define MISA_INFO_IDX(_bit) \
__builtin_ctz(_bit)
#define MISA_EXT_INFO(_bit, _propname, _descr) \
[MISA_INFO_IDX(_bit)] = {.name = _propname, .description = _descr}
static const MISAExtInfo misa_ext_info_arr[] = {
MISA_EXT_INFO(RVA, "a", "Atomic instructions"),
MISA_EXT_INFO(RVC, "c", "Compressed instructions"),
MISA_EXT_INFO(RVD, "d", "Double-precision float point"),
MISA_EXT_INFO(RVF, "f", "Single-precision float point"),
MISA_EXT_INFO(RVI, "i", "Base integer instruction set"),
MISA_EXT_INFO(RVE, "e", "Base integer instruction set (embedded)"),
MISA_EXT_INFO(RVM, "m", "Integer multiplication and division"),
MISA_EXT_INFO(RVS, "s", "Supervisor-level instructions"),
MISA_EXT_INFO(RVU, "u", "User-level instructions"),
MISA_EXT_INFO(RVH, "h", "Hypervisor"),
MISA_EXT_INFO(RVJ, "x-j", "Dynamic translated languages"),
MISA_EXT_INFO(RVV, "v", "Vector operations"),
MISA_EXT_INFO(RVG, "g", "General purpose (IMAFD_Zicsr_Zifencei)"),
};
static int riscv_validate_misa_info_idx(uint32_t bit)
{
int idx;
/*
* Our lowest valid input (RVA) is 1 and
* __builtin_ctz() is UB with zero.
*/
g_assert(bit != 0);
idx = MISA_INFO_IDX(bit);
g_assert(idx < ARRAY_SIZE(misa_ext_info_arr));
return idx;
}
const char *riscv_get_misa_ext_name(uint32_t bit)
{
int idx = riscv_validate_misa_info_idx(bit);
const char *val = misa_ext_info_arr[idx].name;
g_assert(val != NULL);
return val;
}
const char *riscv_get_misa_ext_description(uint32_t bit)
{
int idx = riscv_validate_misa_info_idx(bit);
const char *val = misa_ext_info_arr[idx].description;
g_assert(val != NULL);
return val;
}
#define MISA_CFG(_bit, _enabled) \
{.misa_bit = _bit, .enabled = _enabled}
static RISCVCPUMisaExtConfig misa_ext_cfgs[] = {
MISA_CFG(RVA, true),
MISA_CFG(RVC, true),
MISA_CFG(RVD, true),
MISA_CFG(RVF, true),
MISA_CFG(RVI, true),
MISA_CFG(RVE, false),
MISA_CFG(RVM, true),
MISA_CFG(RVS, true),
MISA_CFG(RVU, true),
MISA_CFG(RVH, true),
MISA_CFG(RVJ, false),
MISA_CFG(RVV, false),
MISA_CFG(RVG, false),
target/riscv: remove cpu->cfg.ext_a Create a new "a" RISCVCPUMisaExtConfig property that will update env->misa_ext* with RVA. Instances of cpu->cfg.ext_a and similar are replaced with riscv_has_ext(env, RVA). Remove the old "a" property and 'ext_a' from RISCVCPUConfig. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:36 +03:00
};
target/riscv: introduce riscv_cpu_add_misa_properties() Ever since RISCVCPUConfig got introduced users are able to set CPU extensions in the command line. User settings are reflected in the cpu->cfg object for later use. These properties are used in the target/riscv/cpu.c code, most notably in riscv_cpu_validate_set_extensions(), where most of our realize time validations are made. And then there's env->misa_ext, the field where the MISA extensions are set, that is read everywhere else. We need to keep env->misa_ext updated with cpu->cfg settings, since our validations rely on it, forcing us to make register_cpu_props() write cpu->cfg.ext_N flags to cover for named CPUs that aren't used named properties but also needs to go through the same validation steps. Failing to so will make those name CPUs fail validation (see c66ffcd5358b for more info). Not only that, but we also need to sync env->misa_ext with cpu->cfg again during realize() time to catch any change the user might have done, since the rest of the code relies on that. Making cpu->cfg.ext_N and env->misa_ext reflect each other is not needed. What we want is a way for users to enable/disable MISA extensions, and there's nothing stopping us from letting the user write env->misa_ext directly. Here are the artifacts that will enable us to do that: - RISCVCPUMisaExtConfig will declare each MISA property; - cpu_set_misa_ext_cfg() is the setter for each property. We'll write env->misa_ext and env->misa_ext_mask with the appropriate misa_bit; cutting off cpu->cfg.ext_N from the logic; - cpu_get_misa_ext_cfg() is a getter that will retrieve the current val of the property based on env->misa_ext; - riscv_cpu_add_misa_properties() will be called in register_cpu_props() to init all MISA properties from the misa_ext_cfgs[] array. With this infrastructure we'll start to get rid of each cpu->cfg.ext_N attribute in the next patches. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:35 +03:00
target/riscv/cpu.c: honor user choice in cpu_cfg_ext_auto_update() Add a new cpu_cfg_ext_is_user_set() helper to check if an extension was set by the user in the command line. Use it inside cpu_cfg_ext_auto_update() to verify if the user set a certain extension and, if that's the case, do not change its value. This will make us honor user choice instead of overwriting the values. Users will then be informed whether they're using an incompatible set of extensions instead of QEMU setting a magic value that works. The reason why we're not implementing user choice for MISA extensions right now is because, today, we do not silently change any MISA bit during realize() time (we do warn when enabling bits if RVG is enabled). We do that - a lot - with multi-letter extensions though, so we're handling the most immediate concern first. After this patch, we'll now error out if the user explicitly set 'zce' to true and 'zca' to false: $ ./build/qemu-system-riscv64 -M virt -cpu rv64,zce=true,zca=false -nographic qemu-system-riscv64: Zcf/Zcd/Zcb/Zcmp/Zcmt extensions require Zca extension This didn't happen before because we were enabling 'zca' if 'zce' was enabled regardless if the user set 'zca' to false. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:22 +03:00
/*
* We do not support user choice tracking for MISA
* extensions yet because, so far, we do not silently
* change MISA bits during realize() (RVG enables MISA
* bits but the user is warned about it).
*/
target/riscv: introduce riscv_cpu_add_misa_properties() Ever since RISCVCPUConfig got introduced users are able to set CPU extensions in the command line. User settings are reflected in the cpu->cfg object for later use. These properties are used in the target/riscv/cpu.c code, most notably in riscv_cpu_validate_set_extensions(), where most of our realize time validations are made. And then there's env->misa_ext, the field where the MISA extensions are set, that is read everywhere else. We need to keep env->misa_ext updated with cpu->cfg settings, since our validations rely on it, forcing us to make register_cpu_props() write cpu->cfg.ext_N flags to cover for named CPUs that aren't used named properties but also needs to go through the same validation steps. Failing to so will make those name CPUs fail validation (see c66ffcd5358b for more info). Not only that, but we also need to sync env->misa_ext with cpu->cfg again during realize() time to catch any change the user might have done, since the rest of the code relies on that. Making cpu->cfg.ext_N and env->misa_ext reflect each other is not needed. What we want is a way for users to enable/disable MISA extensions, and there's nothing stopping us from letting the user write env->misa_ext directly. Here are the artifacts that will enable us to do that: - RISCVCPUMisaExtConfig will declare each MISA property; - cpu_set_misa_ext_cfg() is the setter for each property. We'll write env->misa_ext and env->misa_ext_mask with the appropriate misa_bit; cutting off cpu->cfg.ext_N from the logic; - cpu_get_misa_ext_cfg() is a getter that will retrieve the current val of the property based on env->misa_ext; - riscv_cpu_add_misa_properties() will be called in register_cpu_props() to init all MISA properties from the misa_ext_cfgs[] array. With this infrastructure we'll start to get rid of each cpu->cfg.ext_N attribute in the next patches. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:35 +03:00
static void riscv_cpu_add_misa_properties(Object *cpu_obj)
{
int i;
for (i = 0; i < ARRAY_SIZE(misa_ext_cfgs); i++) {
target/riscv/cpu: add misa_ext_info_arr[] Next patch will add KVM specific user properties for both MISA and multi-letter extensions. For MISA extensions we want to make use of what is already available in misa_ext_cfgs[] to avoid code repetition. misa_ext_info_arr[] array will hold name and description for each MISA extension that misa_ext_cfgs[] is declaring. We'll then use this new array in KVM code to avoid duplicating strings. Two getters were added to allow KVM to retrieve the 'name' and 'description' for each MISA property. There's nothing holding us back from doing the same with multi-letter extensions. For now doing just with MISA extensions is enough. It is worth documenting that even using the __bultin_ctz() directive to populate the misa_ext_info_arr[] we are forced to assign 'name' and 'description' during runtime in riscv_cpu_add_misa_properties(). The reason is that some Gitlab runners ('clang-user' and 'tsan-build') will throw errors like this if we fetch 'name' and 'description' from the array in the MISA_CFG() macro: ../target/riscv/cpu.c:1624:5: error: initializer element is not a compile-time constant MISA_CFG(RVA, true), ^~~~~~~~~~~~~~~~~~~ ../target/riscv/cpu.c:1619:53: note: expanded from macro 'MISA_CFG' {.name = misa_ext_info_arr[MISA_INFO_IDX(_bit)].name, \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ gcc and others compilers/builders were fine with that change. We can't ignore failures in the Gitlab pipeline though, so code was changed to make every runner happy. As a side effect, misa_ext_cfg[] is no longer a 'const' array because it must be set during runtime. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:29 +03:00
RISCVCPUMisaExtConfig *misa_cfg = &misa_ext_cfgs[i];
int bit = misa_cfg->misa_bit;
misa_cfg->name = riscv_get_misa_ext_name(bit);
misa_cfg->description = riscv_get_misa_ext_description(bit);
target/riscv: introduce riscv_cpu_add_misa_properties() Ever since RISCVCPUConfig got introduced users are able to set CPU extensions in the command line. User settings are reflected in the cpu->cfg object for later use. These properties are used in the target/riscv/cpu.c code, most notably in riscv_cpu_validate_set_extensions(), where most of our realize time validations are made. And then there's env->misa_ext, the field where the MISA extensions are set, that is read everywhere else. We need to keep env->misa_ext updated with cpu->cfg settings, since our validations rely on it, forcing us to make register_cpu_props() write cpu->cfg.ext_N flags to cover for named CPUs that aren't used named properties but also needs to go through the same validation steps. Failing to so will make those name CPUs fail validation (see c66ffcd5358b for more info). Not only that, but we also need to sync env->misa_ext with cpu->cfg again during realize() time to catch any change the user might have done, since the rest of the code relies on that. Making cpu->cfg.ext_N and env->misa_ext reflect each other is not needed. What we want is a way for users to enable/disable MISA extensions, and there's nothing stopping us from letting the user write env->misa_ext directly. Here are the artifacts that will enable us to do that: - RISCVCPUMisaExtConfig will declare each MISA property; - cpu_set_misa_ext_cfg() is the setter for each property. We'll write env->misa_ext and env->misa_ext_mask with the appropriate misa_bit; cutting off cpu->cfg.ext_N from the logic; - cpu_get_misa_ext_cfg() is a getter that will retrieve the current val of the property based on env->misa_ext; - riscv_cpu_add_misa_properties() will be called in register_cpu_props() to init all MISA properties from the misa_ext_cfgs[] array. With this infrastructure we'll start to get rid of each cpu->cfg.ext_N attribute in the next patches. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:35 +03:00
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 13:17:30 +03:00
/* Check if KVM already created the property */
if (object_property_find(cpu_obj, misa_cfg->name)) {
continue;
}
target/riscv: introduce riscv_cpu_add_misa_properties() Ever since RISCVCPUConfig got introduced users are able to set CPU extensions in the command line. User settings are reflected in the cpu->cfg object for later use. These properties are used in the target/riscv/cpu.c code, most notably in riscv_cpu_validate_set_extensions(), where most of our realize time validations are made. And then there's env->misa_ext, the field where the MISA extensions are set, that is read everywhere else. We need to keep env->misa_ext updated with cpu->cfg settings, since our validations rely on it, forcing us to make register_cpu_props() write cpu->cfg.ext_N flags to cover for named CPUs that aren't used named properties but also needs to go through the same validation steps. Failing to so will make those name CPUs fail validation (see c66ffcd5358b for more info). Not only that, but we also need to sync env->misa_ext with cpu->cfg again during realize() time to catch any change the user might have done, since the rest of the code relies on that. Making cpu->cfg.ext_N and env->misa_ext reflect each other is not needed. What we want is a way for users to enable/disable MISA extensions, and there's nothing stopping us from letting the user write env->misa_ext directly. Here are the artifacts that will enable us to do that: - RISCVCPUMisaExtConfig will declare each MISA property; - cpu_set_misa_ext_cfg() is the setter for each property. We'll write env->misa_ext and env->misa_ext_mask with the appropriate misa_bit; cutting off cpu->cfg.ext_N from the logic; - cpu_get_misa_ext_cfg() is a getter that will retrieve the current val of the property based on env->misa_ext; - riscv_cpu_add_misa_properties() will be called in register_cpu_props() to init all MISA properties from the misa_ext_cfgs[] array. With this infrastructure we'll start to get rid of each cpu->cfg.ext_N attribute in the next patches. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:35 +03:00
object_property_add(cpu_obj, misa_cfg->name, "bool",
cpu_get_misa_ext_cfg,
cpu_set_misa_ext_cfg,
NULL, (void *)misa_cfg);
object_property_set_description(cpu_obj, misa_cfg->name,
misa_cfg->description);
object_property_set_bool(cpu_obj, misa_cfg->name,
misa_cfg->enabled, NULL);
}
}
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
typedef struct RISCVCPUMultiExtConfig {
const char *name;
uint32_t offset;
bool enabled;
} RISCVCPUMultiExtConfig;
#define MULTI_EXT_CFG_BOOL(_name, _prop, _defval) \
{.name = _name, .offset = CPU_CFG_OFFSET(_prop), \
.enabled = _defval}
static RISCVCPUMultiExtConfig riscv_cpu_extensions[] = {
target/riscv: Organise the CPU properties Organise the CPU properties so that standard extensions come first then followed by experimental extensions. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: b6598570f60c5ee7f402be56d837bb44b289cc4d.1634531504.git.alistair.francis@wdc.com
2021-10-18 07:32:15 +03:00
/* Defaults for standard extensions */
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
MULTI_EXT_CFG_BOOL("sscofpmf", ext_sscofpmf, false),
MULTI_EXT_CFG_BOOL("Zifencei", ext_ifencei, true),
MULTI_EXT_CFG_BOOL("Zicsr", ext_icsr, true),
MULTI_EXT_CFG_BOOL("Zihintntl", ext_zihintntl, true),
MULTI_EXT_CFG_BOOL("Zihintpause", ext_zihintpause, true),
MULTI_EXT_CFG_BOOL("Zawrs", ext_zawrs, true),
MULTI_EXT_CFG_BOOL("Zfa", ext_zfa, true),
MULTI_EXT_CFG_BOOL("Zfh", ext_zfh, false),
MULTI_EXT_CFG_BOOL("Zfhmin", ext_zfhmin, false),
MULTI_EXT_CFG_BOOL("Zve32f", ext_zve32f, false),
MULTI_EXT_CFG_BOOL("Zve64f", ext_zve64f, false),
MULTI_EXT_CFG_BOOL("Zve64d", ext_zve64d, false),
MULTI_EXT_CFG_BOOL("sstc", ext_sstc, true),
MULTI_EXT_CFG_BOOL("smstateen", ext_smstateen, false),
MULTI_EXT_CFG_BOOL("svadu", ext_svadu, true),
MULTI_EXT_CFG_BOOL("svinval", ext_svinval, false),
MULTI_EXT_CFG_BOOL("svnapot", ext_svnapot, false),
MULTI_EXT_CFG_BOOL("svpbmt", ext_svpbmt, false),
MULTI_EXT_CFG_BOOL("zba", ext_zba, true),
MULTI_EXT_CFG_BOOL("zbb", ext_zbb, true),
MULTI_EXT_CFG_BOOL("zbc", ext_zbc, true),
MULTI_EXT_CFG_BOOL("zbkb", ext_zbkb, false),
MULTI_EXT_CFG_BOOL("zbkc", ext_zbkc, false),
MULTI_EXT_CFG_BOOL("zbkx", ext_zbkx, false),
MULTI_EXT_CFG_BOOL("zbs", ext_zbs, true),
MULTI_EXT_CFG_BOOL("zk", ext_zk, false),
MULTI_EXT_CFG_BOOL("zkn", ext_zkn, false),
MULTI_EXT_CFG_BOOL("zknd", ext_zknd, false),
MULTI_EXT_CFG_BOOL("zkne", ext_zkne, false),
MULTI_EXT_CFG_BOOL("zknh", ext_zknh, false),
MULTI_EXT_CFG_BOOL("zkr", ext_zkr, false),
MULTI_EXT_CFG_BOOL("zks", ext_zks, false),
MULTI_EXT_CFG_BOOL("zksed", ext_zksed, false),
MULTI_EXT_CFG_BOOL("zksh", ext_zksh, false),
MULTI_EXT_CFG_BOOL("zkt", ext_zkt, false),
MULTI_EXT_CFG_BOOL("zdinx", ext_zdinx, false),
MULTI_EXT_CFG_BOOL("zfinx", ext_zfinx, false),
MULTI_EXT_CFG_BOOL("zhinx", ext_zhinx, false),
MULTI_EXT_CFG_BOOL("zhinxmin", ext_zhinxmin, false),
MULTI_EXT_CFG_BOOL("zicbom", ext_icbom, true),
MULTI_EXT_CFG_BOOL("zicboz", ext_icboz, true),
MULTI_EXT_CFG_BOOL("zmmul", ext_zmmul, false),
MULTI_EXT_CFG_BOOL("zca", ext_zca, false),
MULTI_EXT_CFG_BOOL("zcb", ext_zcb, false),
MULTI_EXT_CFG_BOOL("zcd", ext_zcd, false),
MULTI_EXT_CFG_BOOL("zce", ext_zce, false),
MULTI_EXT_CFG_BOOL("zcf", ext_zcf, false),
MULTI_EXT_CFG_BOOL("zcmp", ext_zcmp, false),
MULTI_EXT_CFG_BOOL("zcmt", ext_zcmt, false),
MULTI_EXT_CFG_BOOL("zicond", ext_zicond, false),
target/riscv: Move zc* out of the experimental properties Zc* extensions (version 1.0) are ratified. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-Id: <20230510030040.20528-1-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-05-10 06:00:40 +03:00
target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[] Our goal is to make riscv_cpu_extensions[] hold only ratified, non-vendor extensions. Create a new riscv_cpu_vendor_exts[] array for them, changing riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() accordingly. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:09 +03:00
DEFINE_PROP_END_OF_LIST(),
};
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
static RISCVCPUMultiExtConfig riscv_cpu_vendor_exts[] = {
MULTI_EXT_CFG_BOOL("xtheadba", ext_xtheadba, false),
MULTI_EXT_CFG_BOOL("xtheadbb", ext_xtheadbb, false),
MULTI_EXT_CFG_BOOL("xtheadbs", ext_xtheadbs, false),
MULTI_EXT_CFG_BOOL("xtheadcmo", ext_xtheadcmo, false),
MULTI_EXT_CFG_BOOL("xtheadcondmov", ext_xtheadcondmov, false),
MULTI_EXT_CFG_BOOL("xtheadfmemidx", ext_xtheadfmemidx, false),
MULTI_EXT_CFG_BOOL("xtheadfmv", ext_xtheadfmv, false),
MULTI_EXT_CFG_BOOL("xtheadmac", ext_xtheadmac, false),
MULTI_EXT_CFG_BOOL("xtheadmemidx", ext_xtheadmemidx, false),
MULTI_EXT_CFG_BOOL("xtheadmempair", ext_xtheadmempair, false),
MULTI_EXT_CFG_BOOL("xtheadsync", ext_xtheadsync, false),
MULTI_EXT_CFG_BOOL("xventanacondops", ext_XVentanaCondOps, false),
target/riscv: Add XVentanaCondOps custom extension This adds the decoder and translation for the XVentanaCondOps custom extension (vendor-defined by Ventana Micro Systems), which is documented at https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf This commit then also adds a guard-function (has_XVentanaCondOps_p) and the decoder function to the table of decoders, enabling the support for the XVentanaCondOps extension. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20220202005249.3566542-7-philipp.tomsich@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-02-02 03:52:48 +03:00
target/riscv/cpu.c: split non-ratified exts from riscv_cpu_extensions[] Create a new riscv_cpu_experimental_exts[] to store the non-ratified extensions properties. Once they are ratified we'll move them back to riscv_cpu_extensions[]. riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are changed to keep adding non-ratified properties to users. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:08 +03:00
DEFINE_PROP_END_OF_LIST(),
};
target/riscv: expose properties for Zc* extension Expose zca,zcb,zcf,zcd,zcmp,zcmt properties. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230307081403.61950-9-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-03-07 11:14:01 +03:00
target/riscv/cpu.c: split non-ratified exts from riscv_cpu_extensions[] Create a new riscv_cpu_experimental_exts[] to store the non-ratified extensions properties. Once they are ratified we'll move them back to riscv_cpu_extensions[]. riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are changed to keep adding non-ratified properties to users. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:08 +03:00
/* These are experimental so mark with 'x-' */
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
static RISCVCPUMultiExtConfig riscv_cpu_experimental_exts[] = {
target/riscv: Update the ePMP CSR address Update the ePMP CSRs to match the 0.9.3 ePMP spec https://github.com/riscv/riscv-tee/blob/61455747230a26002d741f64879dd78cc9689323/Smepmp/Smepmp.pdf Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: 28c908de60b9b04fa20e63d113885c98586053f3.1630543194.git.alistair.francis@wdc.com
2021-09-02 03:40:10 +03:00
/* ePMP 0.9.3 */
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
MULTI_EXT_CFG_BOOL("x-epmp", epmp, false),
MULTI_EXT_CFG_BOOL("x-smaia", ext_smaia, false),
MULTI_EXT_CFG_BOOL("x-ssaia", ext_ssaia, false),
target/riscv: Add a config option for ePMP Add a config option to enable experimental support for ePMP. This is disabled by default and can be enabled with 'x-epmp=true'. Signed-off-by: Hongzheng-Li <Ethan.Lee.QNL@gmail.com> Signed-off-by: Hou Weiying <weiying_hou@outlook.com> Signed-off-by: Myriad-Dreamin <camiyoru@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-id: a22ccdaf9314078bc735d3b323f966623f8af020.1618812899.git.alistair.francis@wdc.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2021-04-19 09:17:25 +03:00
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
MULTI_EXT_CFG_BOOL("x-zvfh", ext_zvfh, false),
MULTI_EXT_CFG_BOOL("x-zvfhmin", ext_zvfhmin, false),
target/riscv: Expose properties for Zv* extensions Expose Zve64d,Zvfh,Zvfhmin properties. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230215020539.4788-15-liweiwei@iscas.ac.cn> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-02-15 05:05:39 +03:00
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
MULTI_EXT_CFG_BOOL("x-zfbfmin", ext_zfbfmin, false),
MULTI_EXT_CFG_BOOL("x-zvfbfmin", ext_zvfbfmin, false),
MULTI_EXT_CFG_BOOL("x-zvfbfwma", ext_zvfbfwma, false),
target/riscv: Expose properties for BF16 extensions Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230615063302.102409-6-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-06-15 09:33:01 +03:00
target/riscv: Add Zvbc ISA extension support This commit adds support for the Zvbc vector-crypto extension, which consists of the following instructions: * vclmulh.[vx,vv] * vclmul.[vx,vv] Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Co-authored-by: Max Chou <max.chou@sifive.com> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> [max.chou@sifive.com: Exposed x-zvbc property] Message-ID: <20230711165917.2629866-5-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:03 +03:00
/* Vector cryptography extensions */
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
MULTI_EXT_CFG_BOOL("x-zvbb", ext_zvbb, false),
MULTI_EXT_CFG_BOOL("x-zvbc", ext_zvbc, false),
MULTI_EXT_CFG_BOOL("x-zvkg", ext_zvkg, false),
MULTI_EXT_CFG_BOOL("x-zvkned", ext_zvkned, false),
MULTI_EXT_CFG_BOOL("x-zvknha", ext_zvknha, false),
MULTI_EXT_CFG_BOOL("x-zvknhb", ext_zvknhb, false),
MULTI_EXT_CFG_BOOL("x-zvksed", ext_zvksed, false),
MULTI_EXT_CFG_BOOL("x-zvksh", ext_zvksh, false),
target/riscv: Add Zvbc ISA extension support This commit adds support for the Zvbc vector-crypto extension, which consists of the following instructions: * vclmulh.[vx,vv] * vclmul.[vx,vv] Translation functions are defined in `target/riscv/insn_trans/trans_rvvk.c.inc` and helpers are defined in `target/riscv/vcrypto_helper.c`. Co-authored-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Co-authored-by: Max Chou <max.chou@sifive.com> Signed-off-by: Nazar Kazakov <nazar.kazakov@codethink.co.uk> Signed-off-by: Lawrence Hunter <lawrence.hunter@codethink.co.uk> Signed-off-by: Max Chou <max.chou@sifive.com> [max.chou@sifive.com: Exposed x-zvbc property] Message-ID: <20230711165917.2629866-5-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-11 19:59:03 +03:00
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
DEFINE_PROP_END_OF_LIST(),
};
target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[] We'll add a new CPU type that will enable a considerable amount of extensions. To make it easier for us we'll do a few cleanups in our existing riscv_cpu_extensions[] array. Start by splitting all CPU non-boolean options from it. Create a new riscv_cpu_options[] array for them. Add all these properties in riscv_cpu_add_user_properties() as it is already being done today. 'mmu' and 'pmp' aren't really extensions in the usual way we think about RISC-V extensions. These are closer to CPU features/options, so move both to riscv_cpu_options[] too. In the near future we'll need to match all extensions with all entries in isa_edata_arr[], and so it happens that both 'mmu' and 'pmp' do not have a riscv,isa string (thus, no priv spec version restriction). This further emphasizes the point that these are more a CPU option than an extension. No functional changes made. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:04 +03:00
static Property riscv_cpu_options[] = {
DEFINE_PROP_UINT8("pmu-num", RISCVCPU, cfg.pmu_num, 16),
DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
DEFINE_PROP_BOOL("pmp", RISCVCPU, cfg.pmp, true),
DEFINE_PROP_STRING("priv_spec", RISCVCPU, cfg.priv_spec),
DEFINE_PROP_STRING("vext_spec", RISCVCPU, cfg.vext_spec),
DEFINE_PROP_UINT16("vlen", RISCVCPU, cfg.vlen, 128),
DEFINE_PROP_UINT16("elen", RISCVCPU, cfg.elen, 64),
DEFINE_PROP_UINT16("cbom_blocksize", RISCVCPU, cfg.cbom_blocksize, 64),
DEFINE_PROP_UINT16("cboz_blocksize", RISCVCPU, cfg.cboz_blocksize, 64),
target/riscv: add DEFINE_PROP_END_OF_LIST() to riscv_cpu_options[] Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when iterating in the riscv_cpu_options[] array, making it similar to what we already do when working with riscv_cpu_extensions[]. We also have a more sophisticated motivation behind this change. In the future we might need to export riscv_cpu_options[] to other files, and ARRAY_LIST() doesn't work properly in that case because the array size isn't exposed to the header file. Here's a future sight of what we would deal with: ./target/riscv/kvm.c:1057:5: error: nested extern declaration of 'riscv_cpu_add_misa_properties' [-Werror=nested-externs] n file included from ../target/riscv/kvm.c:19: home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ | ^~~~~~~~~~ ./target/riscv/kvm.c:1059:5: note: in expansion of macro 'ADD_UNAVAIL_KVM_PROP_ARRAY' 1059 | ADD_UNAVAIL_KVM_PROP_ARRAY(obj, riscv_cpu_extensions); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ Homogenize the present and change the future by using DEFINE_PROP_END_OF_LIST() in riscv_cpu_options[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:07 +03:00
DEFINE_PROP_END_OF_LIST(),
target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[] We'll add a new CPU type that will enable a considerable amount of extensions. To make it easier for us we'll do a few cleanups in our existing riscv_cpu_extensions[] array. Start by splitting all CPU non-boolean options from it. Create a new riscv_cpu_options[] array for them. Add all these properties in riscv_cpu_add_user_properties() as it is already being done today. 'mmu' and 'pmp' aren't really extensions in the usual way we think about RISC-V extensions. These are closer to CPU features/options, so move both to riscv_cpu_options[] too. In the near future we'll need to match all extensions with all entries in isa_edata_arr[], and so it happens that both 'mmu' and 'pmp' do not have a riscv,isa string (thus, no priv spec version restriction). This further emphasizes the point that these are more a CPU option than an extension. No functional changes made. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:04 +03:00
};
target/riscv/cpu.c: create KVM mock properties KVM-specific properties are being created inside target/riscv/kvm.c. But at this moment we're gathering all the remaining properties from TCG and adding them as is when running KVM. This creates a situation where non-KVM properties are setting flags to 'true' due to its default settings (e.g. Zawrs). Users can also freely enable them via command line. This doesn't impact runtime per se because KVM doesn't care about these flags, but code such as riscv_isa_string_ext() take those flags into account. The result is that, for a KVM guest, setting non-KVM properties will make them appear in the riscv,isa DT. We want to keep the same API for both TCG and KVM and at the same time, when running KVM, forbid non-KVM extensions to be enabled internally. We accomplish both by changing riscv_cpu_add_user_properties() to add a mock boolean property for every non-KVM extension in riscv_cpu_extensions[]. Then, when running KVM, users are still free to set extensions at will, but we'll error out if a non-KVM extension is enabled. Setting such extension to 'false' will be ignored. 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-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:35 +03:00
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
static void cpu_set_multi_ext_cfg(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
const RISCVCPUMultiExtConfig *multi_ext_cfg = opaque;
bool value;
if (!visit_type_bool(v, name, &value, errp)) {
return;
}
isa_ext_update_enabled(RISCV_CPU(obj), multi_ext_cfg->offset, value);
g_hash_table_insert(multi_ext_user_opts,
GUINT_TO_POINTER(multi_ext_cfg->offset),
(gpointer)value);
}
static void cpu_get_multi_ext_cfg(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
const RISCVCPUMultiExtConfig *multi_ext_cfg = opaque;
bool value = isa_ext_is_enabled(RISCV_CPU(obj), multi_ext_cfg->offset);
visit_type_bool(v, name, &value, errp);
}
static void cpu_add_multi_ext_prop(Object *cpu_obj,
RISCVCPUMultiExtConfig *multi_cfg)
{
object_property_add(cpu_obj, multi_cfg->name, "bool",
cpu_get_multi_ext_cfg,
cpu_set_multi_ext_cfg,
NULL, (void *)multi_cfg);
/*
* Set def val directly instead of using
* object_property_set_bool() to save the set()
* callback hash for user inputs.
*/
isa_ext_update_enabled(RISCV_CPU(cpu_obj), multi_cfg->offset,
multi_cfg->enabled);
}
static void riscv_cpu_add_multiext_prop_array(Object *obj,
RISCVCPUMultiExtConfig *array)
target/riscv/cpu.c: add riscv_cpu_add_qdev_prop_array() The code inside riscv_cpu_add_user_properties() became quite repetitive after recent changes. Add a helper to hide the repetition away. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:10 +03:00
{
g_assert(array);
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
for (RISCVCPUMultiExtConfig *prop = array; prop && prop->name; prop++) {
cpu_add_multi_ext_prop(obj, prop);
target/riscv/cpu.c: add riscv_cpu_add_qdev_prop_array() The code inside riscv_cpu_add_user_properties() became quite repetitive after recent changes. Add a helper to hide the repetition away. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:10 +03:00
}
}
target/riscv/cpu.c: split kvm prop handling to its own helper Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:06 +03:00
#ifdef CONFIG_KVM
target/riscv/cpu.c: create KVM mock properties KVM-specific properties are being created inside target/riscv/kvm.c. But at this moment we're gathering all the remaining properties from TCG and adding them as is when running KVM. This creates a situation where non-KVM properties are setting flags to 'true' due to its default settings (e.g. Zawrs). Users can also freely enable them via command line. This doesn't impact runtime per se because KVM doesn't care about these flags, but code such as riscv_isa_string_ext() take those flags into account. The result is that, for a KVM guest, setting non-KVM properties will make them appear in the riscv,isa DT. We want to keep the same API for both TCG and KVM and at the same time, when running KVM, forbid non-KVM extensions to be enabled internally. We accomplish both by changing riscv_cpu_add_user_properties() to add a mock boolean property for every non-KVM extension in riscv_cpu_extensions[]. Then, when running KVM, users are still free to set extensions at will, but we'll error out if a non-KVM extension is enabled. Setting such extension to 'false' will be ignored. 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-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:35 +03:00
static void cpu_set_cfg_unavailable(Object *obj, Visitor *v,
const char *name,
void *opaque, Error **errp)
{
const char *propname = opaque;
bool value;
if (!visit_type_bool(v, name, &value, errp)) {
return;
}
if (value) {
error_setg(errp, "extension %s is not available with KVM",
propname);
}
}
target/riscv/cpu.c: split kvm prop handling to its own helper Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:06 +03:00
static void riscv_cpu_add_kvm_unavail_prop(Object *obj, const char *prop_name)
{
/* Check if KVM created the property already */
if (object_property_find(obj, prop_name)) {
return;
}
/*
* Set the default to disabled for every extension
* unknown to KVM and error out if the user attempts
* to enable any of them.
*/
object_property_add(obj, prop_name, "bool",
NULL, cpu_set_cfg_unavailable,
NULL, (void *)prop_name);
}
target/riscv/cpu.c: add riscv_cpu_add_kvm_unavail_prop_array() Use a helper in riscv_cpu_add_kvm_properties() to eliminate some of its code repetition. 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: <20230912132423.268494-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:11 +03:00
static void riscv_cpu_add_kvm_unavail_prop_array(Object *obj,
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
RISCVCPUMultiExtConfig *array)
target/riscv/cpu.c: add riscv_cpu_add_kvm_unavail_prop_array() Use a helper in riscv_cpu_add_kvm_properties() to eliminate some of its code repetition. 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: <20230912132423.268494-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:11 +03:00
{
g_assert(array);
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
for (RISCVCPUMultiExtConfig *prop = array; prop && prop->name; prop++) {
target/riscv/cpu.c: add riscv_cpu_add_kvm_unavail_prop_array() Use a helper in riscv_cpu_add_kvm_properties() to eliminate some of its code repetition. 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: <20230912132423.268494-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:11 +03:00
riscv_cpu_add_kvm_unavail_prop(obj, prop->name);
}
}
target/riscv/cpu.c: split kvm prop handling to its own helper Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:06 +03:00
void kvm_riscv_cpu_add_kvm_properties(Object *obj)
{
Property *prop;
DeviceState *dev = DEVICE(obj);
kvm_riscv_init_user_properties(obj);
riscv_cpu_add_misa_properties(obj);
target/riscv/cpu.c: add riscv_cpu_add_kvm_unavail_prop_array() Use a helper in riscv_cpu_add_kvm_properties() to eliminate some of its code repetition. 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: <20230912132423.268494-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:11 +03:00
riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_extensions);
riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_vendor_exts);
riscv_cpu_add_kvm_unavail_prop_array(obj, riscv_cpu_experimental_exts);
target/riscv/cpu.c: split non-ratified exts from riscv_cpu_extensions[] Create a new riscv_cpu_experimental_exts[] to store the non-ratified extensions properties. Once they are ratified we'll move them back to riscv_cpu_extensions[]. riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are changed to keep adding non-ratified properties to users. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:08 +03:00
target/riscv: add DEFINE_PROP_END_OF_LIST() to riscv_cpu_options[] Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when iterating in the riscv_cpu_options[] array, making it similar to what we already do when working with riscv_cpu_extensions[]. We also have a more sophisticated motivation behind this change. In the future we might need to export riscv_cpu_options[] to other files, and ARRAY_LIST() doesn't work properly in that case because the array size isn't exposed to the header file. Here's a future sight of what we would deal with: ./target/riscv/kvm.c:1057:5: error: nested extern declaration of 'riscv_cpu_add_misa_properties' [-Werror=nested-externs] n file included from ../target/riscv/kvm.c:19: home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ | ^~~~~~~~~~ ./target/riscv/kvm.c:1059:5: note: in expansion of macro 'ADD_UNAVAIL_KVM_PROP_ARRAY' 1059 | ADD_UNAVAIL_KVM_PROP_ARRAY(obj, riscv_cpu_extensions); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ Homogenize the present and change the future by using DEFINE_PROP_END_OF_LIST() in riscv_cpu_options[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:07 +03:00
for (prop = riscv_cpu_options; prop && prop->name; prop++) {
target/riscv/cpu.c: split kvm prop handling to its own helper Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:06 +03:00
/* Check if KVM created the property already */
target/riscv: add DEFINE_PROP_END_OF_LIST() to riscv_cpu_options[] Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when iterating in the riscv_cpu_options[] array, making it similar to what we already do when working with riscv_cpu_extensions[]. We also have a more sophisticated motivation behind this change. In the future we might need to export riscv_cpu_options[] to other files, and ARRAY_LIST() doesn't work properly in that case because the array size isn't exposed to the header file. Here's a future sight of what we would deal with: ./target/riscv/kvm.c:1057:5: error: nested extern declaration of 'riscv_cpu_add_misa_properties' [-Werror=nested-externs] n file included from ../target/riscv/kvm.c:19: home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ | ^~~~~~~~~~ ./target/riscv/kvm.c:1059:5: note: in expansion of macro 'ADD_UNAVAIL_KVM_PROP_ARRAY' 1059 | ADD_UNAVAIL_KVM_PROP_ARRAY(obj, riscv_cpu_extensions); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ Homogenize the present and change the future by using DEFINE_PROP_END_OF_LIST() in riscv_cpu_options[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:07 +03:00
if (object_property_find(obj, prop->name)) {
target/riscv/cpu.c: split kvm prop handling to its own helper Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:06 +03:00
continue;
}
target/riscv: add DEFINE_PROP_END_OF_LIST() to riscv_cpu_options[] Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when iterating in the riscv_cpu_options[] array, making it similar to what we already do when working with riscv_cpu_extensions[]. We also have a more sophisticated motivation behind this change. In the future we might need to export riscv_cpu_options[] to other files, and ARRAY_LIST() doesn't work properly in that case because the array size isn't exposed to the header file. Here's a future sight of what we would deal with: ./target/riscv/kvm.c:1057:5: error: nested extern declaration of 'riscv_cpu_add_misa_properties' [-Werror=nested-externs] n file included from ../target/riscv/kvm.c:19: home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ | ^~~~~~~~~~ ./target/riscv/kvm.c:1059:5: note: in expansion of macro 'ADD_UNAVAIL_KVM_PROP_ARRAY' 1059 | ADD_UNAVAIL_KVM_PROP_ARRAY(obj, riscv_cpu_extensions); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ Homogenize the present and change the future by using DEFINE_PROP_END_OF_LIST() in riscv_cpu_options[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:07 +03:00
qdev_property_add_static(dev, prop);
target/riscv/cpu.c: split kvm prop handling to its own helper Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:06 +03:00
}
}
target/riscv/cpu.c: create KVM mock properties KVM-specific properties are being created inside target/riscv/kvm.c. But at this moment we're gathering all the remaining properties from TCG and adding them as is when running KVM. This creates a situation where non-KVM properties are setting flags to 'true' due to its default settings (e.g. Zawrs). Users can also freely enable them via command line. This doesn't impact runtime per se because KVM doesn't care about these flags, but code such as riscv_isa_string_ext() take those flags into account. The result is that, for a KVM guest, setting non-KVM properties will make them appear in the riscv,isa DT. We want to keep the same API for both TCG and KVM and at the same time, when running KVM, forbid non-KVM extensions to be enabled internally. We accomplish both by changing riscv_cpu_add_user_properties() to add a mock boolean property for every non-KVM extension in riscv_cpu_extensions[]. Then, when running KVM, users are still free to set extensions at will, but we'll error out if a non-KVM extension is enabled. Setting such extension to 'false' will be ignored. 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-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:35 +03:00
#endif
target/riscv/cpu: set cpu->cfg in register_cpu_props() There is an informal contract between the cpu_init() functions and riscv_cpu_realize(): if cpu->env.misa_ext is zero, assume that the default settings were loaded via register_cpu_props() and do validations to set env.misa_ext. If it's not zero, skip this whole process and assume that the board somehow did everything. At this moment, all SiFive CPUs are setting a non-zero misa_ext during their cpu_init() and skipping a good chunk of riscv_cpu_realize(). This causes problems when the code being skipped in riscv_cpu_realize() contains fixes or assumptions that affects all CPUs, meaning that SiFive CPUs are missing out. To allow this code to not be skipped anymore, all the cpu->cfg.ext_* attributes needs to be set during cpu_init() time. At this moment this is being done in register_cpu_props(). The SiFive boards are setting their own extensions during cpu_init() though, meaning that they don't want all the defaults from register_cpu_props(). Let's move the contract between *_cpu_init() and riscv_cpu_realize() to register_cpu_props(). Inside this function we'll check if cpu->env.misa_ext was set and, if that's the case, set all relevant cpu->cfg.ext_* attributes, and only that. Leave the 'misa_ext' = 0 case as is today, i.e. loading all the defaults from riscv_cpu_extensions[]. register_cpu_props() can then be called by all the cpu_init() functions, including the SiFive ones. This will make all CPUs behave more in line with what riscv_cpu_realize() expects. This will also make the cpu_init() functions even more alike, but at this moment we would need some design changes in how we're initializing extensions/attributes (e.g. some CPUs are setting cfg options after register_cpu_props(), so we can't simply add the function to a common post_init() hook) to make a common cpu_init() code across all CPUs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230113175230.473975-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-01-13 20:52:29 +03:00
/*
target/riscv/cpu.c: redesign register_cpu_props() The function is now a no-op for all cpu_init() callers that are setting a non-zero misa value in set_misa(), since it's no longer used to sync cpu->cfg props with env->misa_ext bits. Remove it in those cases. While we're at it, rename the function to match what it's actually doing: create user properties to set/remove CPU extensions. Make a note that it will overwrite env->misa_ext with the defaults set by each user property. Update the MISA bits comment in cpu.h as well. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:51 +03:00
* Add CPU properties with user-facing flags.
*
* This will overwrite existing env->misa_ext values with the
* defaults set via riscv_cpu_add_misa_properties().
target/riscv/cpu: set cpu->cfg in register_cpu_props() There is an informal contract between the cpu_init() functions and riscv_cpu_realize(): if cpu->env.misa_ext is zero, assume that the default settings were loaded via register_cpu_props() and do validations to set env.misa_ext. If it's not zero, skip this whole process and assume that the board somehow did everything. At this moment, all SiFive CPUs are setting a non-zero misa_ext during their cpu_init() and skipping a good chunk of riscv_cpu_realize(). This causes problems when the code being skipped in riscv_cpu_realize() contains fixes or assumptions that affects all CPUs, meaning that SiFive CPUs are missing out. To allow this code to not be skipped anymore, all the cpu->cfg.ext_* attributes needs to be set during cpu_init() time. At this moment this is being done in register_cpu_props(). The SiFive boards are setting their own extensions during cpu_init() though, meaning that they don't want all the defaults from register_cpu_props(). Let's move the contract between *_cpu_init() and riscv_cpu_realize() to register_cpu_props(). Inside this function we'll check if cpu->env.misa_ext was set and, if that's the case, set all relevant cpu->cfg.ext_* attributes, and only that. Leave the 'misa_ext' = 0 case as is today, i.e. loading all the defaults from riscv_cpu_extensions[]. register_cpu_props() can then be called by all the cpu_init() functions, including the SiFive ones. This will make all CPUs behave more in line with what riscv_cpu_realize() expects. This will also make the cpu_init() functions even more alike, but at this moment we would need some design changes in how we're initializing extensions/attributes (e.g. some CPUs are setting cfg options after register_cpu_props(), so we can't simply add the function to a common post_init() hook) to make a common cpu_init() code across all CPUs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230113175230.473975-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-01-13 20:52:29 +03:00
*/
target/riscv/cpu.c: redesign register_cpu_props() The function is now a no-op for all cpu_init() callers that are setting a non-zero misa value in set_misa(), since it's no longer used to sync cpu->cfg props with env->misa_ext bits. Remove it in those cases. While we're at it, rename the function to match what it's actually doing: create user properties to set/remove CPU extensions. Make a note that it will overwrite env->misa_ext with the defaults set by each user property. Update the MISA bits comment in cpu.h as well. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:51 +03:00
static void riscv_cpu_add_user_properties(Object *obj)
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03: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 13:17:24 +03:00
#ifndef CONFIG_USER_ONLY
target/riscv/cpu.c: add satp_mode properties earlier riscv_cpu_add_user_properties() ended up with an excess of "#ifndef CONFIG_USER_ONLY" blocks after changes that added KVM properties handling. KVM specific properties are required to be created earlier than their TCG counterparts, but the remaining props can be created at any order. Move riscv_add_satp_mode_properties() to the start of the function, inside the !CONFIG_USER_ONLY block already present there, to remove the last ifndef block. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-16-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:33 +03:00
riscv_add_satp_mode_properties(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 13:17:24 +03:00
if (kvm_enabled()) {
target/riscv/cpu.c: split kvm prop handling to its own helper Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:06 +03:00
kvm_riscv_cpu_add_kvm_properties(obj);
return;
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 13:17:24 +03:00
}
#endif
target/riscv: introduce riscv_cpu_add_misa_properties() Ever since RISCVCPUConfig got introduced users are able to set CPU extensions in the command line. User settings are reflected in the cpu->cfg object for later use. These properties are used in the target/riscv/cpu.c code, most notably in riscv_cpu_validate_set_extensions(), where most of our realize time validations are made. And then there's env->misa_ext, the field where the MISA extensions are set, that is read everywhere else. We need to keep env->misa_ext updated with cpu->cfg settings, since our validations rely on it, forcing us to make register_cpu_props() write cpu->cfg.ext_N flags to cover for named CPUs that aren't used named properties but also needs to go through the same validation steps. Failing to so will make those name CPUs fail validation (see c66ffcd5358b for more info). Not only that, but we also need to sync env->misa_ext with cpu->cfg again during realize() time to catch any change the user might have done, since the rest of the code relies on that. Making cpu->cfg.ext_N and env->misa_ext reflect each other is not needed. What we want is a way for users to enable/disable MISA extensions, and there's nothing stopping us from letting the user write env->misa_ext directly. Here are the artifacts that will enable us to do that: - RISCVCPUMisaExtConfig will declare each MISA property; - cpu_set_misa_ext_cfg() is the setter for each property. We'll write env->misa_ext and env->misa_ext_mask with the appropriate misa_bit; cutting off cpu->cfg.ext_N from the logic; - cpu_get_misa_ext_cfg() is a getter that will retrieve the current val of the property based on env->misa_ext; - riscv_cpu_add_misa_properties() will be called in register_cpu_props() to init all MISA properties from the misa_ext_cfgs[] array. With this infrastructure we'll start to get rid of each cpu->cfg.ext_N attribute in the next patches. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230406180351.570807-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-06 21:03:35 +03:00
riscv_cpu_add_misa_properties(obj);
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
riscv_cpu_add_multiext_prop_array(obj, riscv_cpu_extensions);
riscv_cpu_add_multiext_prop_array(obj, riscv_cpu_vendor_exts);
riscv_cpu_add_multiext_prop_array(obj, riscv_cpu_experimental_exts);
for (Property *prop = riscv_cpu_options; prop && prop->name; prop++) {
qdev_property_add_static(DEVICE(obj), prop);
}
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
}
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
/*
* The 'max' type CPU will have all possible ratified
* non-vendor extensions enabled.
*/
static void riscv_init_max_cpu_extensions(Object *obj)
{
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
target/riscv/cpu.c: introduce RISCVCPUMultiExtConfig If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:20 +03:00
RISCVCPUMultiExtConfig *prop;
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
/* Enable RVG, RVJ and RVV that are disabled by default */
set_misa(env, env->misa_mxl, env->misa_ext | RVG | RVJ | RVV);
for (prop = riscv_cpu_extensions; prop && prop->name; prop++) {
target/riscv: use isa_ext_update_enabled() in init_max_cpu_extensions() Before adding support to detect if an extension was user set we need to handle how we're enabling extensions in riscv_init_max_cpu_extensions(). object_property_set_bool() calls the set() callback for the property, and we're going to use this callback to set the 'multi_ext_user_opts' hash. This means that, as is today, all extensions we're setting for the 'max' CPU will be seen as user set in the future. Let's change set_bool() to isa_ext_update_enabled() that will just enable/disable the flag on a certain offset. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:21 +03:00
isa_ext_update_enabled(cpu, prop->offset, true);
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
}
/* set vector version */
env->vext_ver = VEXT_VERSION_1_00_0;
/* Zfinx is not compatible with F. Disable it */
target/riscv: use isa_ext_update_enabled() in init_max_cpu_extensions() Before adding support to detect if an extension was user set we need to handle how we're enabling extensions in riscv_init_max_cpu_extensions(). object_property_set_bool() calls the set() callback for the property, and we're going to use this callback to set the 'multi_ext_user_opts' hash. This means that, as is today, all extensions we're setting for the 'max' CPU will be seen as user set in the future. Let's change set_bool() to isa_ext_update_enabled() that will just enable/disable the flag on a certain offset. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:21 +03:00
isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_zfinx), false);
isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_zdinx), false);
isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_zhinx), false);
isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_zhinxmin), false);
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
target/riscv: use isa_ext_update_enabled() in init_max_cpu_extensions() Before adding support to detect if an extension was user set we need to handle how we're enabling extensions in riscv_init_max_cpu_extensions(). object_property_set_bool() calls the set() callback for the property, and we're going to use this callback to set the 'multi_ext_user_opts' hash. This means that, as is today, all extensions we're setting for the 'max' CPU will be seen as user set in the future. Let's change set_bool() to isa_ext_update_enabled() that will just enable/disable the flag on a certain offset. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:21 +03:00
isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_zce), false);
isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_zcmp), false);
isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_zcmt), false);
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
if (env->misa_mxl != MXL_RV32) {
target/riscv: use isa_ext_update_enabled() in init_max_cpu_extensions() Before adding support to detect if an extension was user set we need to handle how we're enabling extensions in riscv_init_max_cpu_extensions(). object_property_set_bool() calls the set() callback for the property, and we're going to use this callback to set the 'multi_ext_user_opts' hash. This means that, as is today, all extensions we're setting for the 'max' CPU will be seen as user set in the future. Let's change set_bool() to isa_ext_update_enabled() that will just enable/disable the flag on a certain offset. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:21 +03:00
isa_ext_update_enabled(cpu, CPU_CFG_OFFSET(ext_zcf), false);
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
}
}
target/riscv: Don't expose the CPU properties on names CPUs There are currently two types of RISC-V CPUs: - Generic CPUs (base or any) that allow complete custimisation - "Named" CPUs that match existing hardware Users can use the base CPUs to custimise the extensions that they want, for example -cpu rv64,v=true. We originally exposed these as part of the named CPUs as well, but that was by accident. Exposing the CPU properties to named CPUs means that we accidently enable extensions that don't exist on the CPUs by default. For example the SiFive E CPU currently support the zba extension, which is a bug. This patch instead only exposes the CPU extensions to the generic CPUs. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20220608061437.314434-1-alistair.francis@opensource.wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-08 09:14:37 +03:00
static Property riscv_cpu_properties[] = {
DEFINE_PROP_BOOL("debug", RISCVCPU, cfg.debug, true),
target/riscv: Set the CPU resetvec directly Instead of using our properties to set a config value which then might be used to set the resetvec (depending on your timing), let's instead just set the resetvec directly in the env struct. This allows us to set the reset vec from the command line with: -global driver=riscv.hart_array,property=resetvec,value=0x20000400 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220914101108.82571-2-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-09-14 13:11:06 +03:00
#ifndef CONFIG_USER_ONLY
DEFINE_PROP_UINT64("resetvec", RISCVCPU, env.resetvec, DEFAULT_RSTVEC),
#endif
target/riscv: Add short-isa-string option Because some operating systems don't correctly parse long ISA extension string, this commit adds short-isa-string boolean option to disable generating long ISA extension strings on Device Tree. For instance, enabling Zfinx and Zdinx extensions and booting Linux (5.17 or earlier) with FPU support caused a kernel panic. Operating Systems which short-isa-string might be helpful: 1. Linux (5.17 or earlier) 2. FreeBSD (at least 14.0-CURRENT) 3. OpenBSD (at least current development version) Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <7c1fe5f06b0a7646a47e9bcdddb1042bb60c69c8.1652181972.git.research_trasio@irq.a4lg.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-05-10 14:29:08 +03:00
DEFINE_PROP_BOOL("short-isa-string", RISCVCPU, cfg.short_isa_string, false),
target/riscv: rvv: Add option 'rvv_ta_all_1s' to enable optional tail agnostic behavior According to v-spec, tail agnostic behavior can be either kept as undisturbed or set elements' bits to all 1s. To distinguish the difference of tail policies, QEMU should be able to simulate the tail agnostic behavior as "set tail elements' bits to all 1s". There are multiple possibility for agnostic elements according to v-spec. The main intent of this patch-set tries to add option that can distinguish between tail policies. Setting agnostic elements to all 1s allows QEMU to express this. This commit adds option 'rvv_ta_all_1s' is added to enable the behavior, it is default as disabled. Signed-off-by: eop Chen <eop.chen@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <165449614532.19704.7000832880482980398-16@git.sr.ht> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-06 09:16:56 +03:00
DEFINE_PROP_BOOL("rvv_ta_all_1s", RISCVCPU, cfg.rvv_ta_all_1s, false),
target/riscv: rvv: Add option 'rvv_ma_all_1s' to enable optional mask agnostic behavior According to v-spec, mask agnostic behavior can be either kept as undisturbed or set elements' bits to all 1s. To distinguish the difference of mask policies, QEMU should be able to simulate the mask agnostic behavior as "set mask elements' bits to all 1s". There are multiple possibility for agnostic elements according to v-spec. The main intent of this patch-set tries to add option that can distinguish between mask policies. Setting agnostic elements to all 1s allows QEMU to express this. This commit adds option 'rvv_ma_all_1s' is added to enable the behavior, it is default as disabled. Signed-off-by: eop Chen <eop.chen@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <165570784143.17634.35095816584573691-10@git.sr.ht> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-06-20 09:51:11 +03:00
DEFINE_PROP_BOOL("rvv_ma_all_1s", RISCVCPU, cfg.rvv_ma_all_1s, false),
target/riscv: allow MISA writes as experimental At this moment, and apparently since ever, we have no way of enabling RISCV_FEATURE_MISA. This means that all the code from write_misa(), all the nuts and bolts that handles how to properly write this CSR, has always been a no-op as well because write_misa() will always exit earlier. This seems to be benign in the majority of cases. Booting an Ubuntu 'virt' guest and logging all the calls to 'write_misa' shows that no writes to MISA CSR was attempted. Writing MISA, i.e. enabling/disabling RISC-V extensions after the machine is powered on, seems to be a niche use. After discussions in the mailing list, most notably in [1], we reached the consensus that this code is not suited to be exposed to users because it's not well tested, but at the same time removing it is a bit extreme because we would like to fix it, and it's easier to do so with the code available to use instead of fetching it from git log. The approach taken here is to get rid of RISCV_FEATURE_MISA altogether and use a new experimental flag called x-misa-w. The default value is false, meaning that we're keeping the existing behavior of doing nothing if a write_misa() is attempted. As with any existing experimental flag, x-misa-w is also a temporary flag that we need to remove once we fix write_misa(). [1] https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg05092.html Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Weiwei Li<liweiwei@iscas.ac.cn> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20230222185205.355361-4-dbarboza@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-02-22 21:51:58 +03:00
/*
* write_misa() is marked as experimental for now so mark
* it with -x and default to 'false'.
*/
DEFINE_PROP_BOOL("x-misa-w", RISCVCPU, cfg.misa_w, false),
target/riscv: Create settable CPU properties Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-04-20 05:24:01 +03:00
DEFINE_PROP_END_OF_LIST(),
};
hw/core/cpu: Return static value with gdb_arch_name() All implementations of gdb_arch_name() returns dynamic duplicates of static strings. It's also unlikely that there will be an implementation of gdb_arch_name() that returns a truly dynamic value due to the nature of the function returning a well-known identifiers. Qualify the value gdb_arch_name() with const and make all of its implementations return static strings. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230912224107.29669-8-akihiko.odaki@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231009164104.369749-15-alex.bennee@linaro.org>
2023-10-09 19:40:53 +03:00
static const gchar *riscv_gdb_arch_name(CPUState *cs)
gdb: riscv: Add target description Target description is not currently implemented in RISC-V architecture. Thus GDB won't set it properly when attached. The patch implements the target description response. Signed-off-by: Sylvain Pelissier <sylvain.pelissier@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210106204141.14027-1-sylvain.pelissier@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-01-06 23:41:41 +03:00
{
RISCVCPU *cpu = RISCV_CPU(cs);
CPURISCVState *env = &cpu->env;
target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl Shortly, the set of supported XL will not be just 32 and 64, and representing that properly using the enumeration will be imperative. Two places, booting and gdb, intentionally use misa_mxl_max to emphasize the use of the reset value of misa.mxl, and not the current cpu state. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-5-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:58 +03:00
switch (riscv_cpu_mxl(env)) {
case MXL_RV32:
hw/core/cpu: Return static value with gdb_arch_name() All implementations of gdb_arch_name() returns dynamic duplicates of static strings. It's also unlikely that there will be an implementation of gdb_arch_name() that returns a truly dynamic value due to the nature of the function returning a well-known identifiers. Qualify the value gdb_arch_name() with const and make all of its implementations return static strings. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230912224107.29669-8-akihiko.odaki@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231009164104.369749-15-alex.bennee@linaro.org>
2023-10-09 19:40:53 +03:00
return "riscv:rv32";
target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl Shortly, the set of supported XL will not be just 32 and 64, and representing that properly using the enumeration will be imperative. Two places, booting and gdb, intentionally use misa_mxl_max to emphasize the use of the reset value of misa.mxl, and not the current cpu state. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-5-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:58 +03:00
case MXL_RV64:
target/riscv: setup everything for rv64 to support rv128 execution This patch adds the support of the '-cpu rv128' option to qemu-system-riscv64 so that we can indicate that we want to run rv128 executables. Still, there is no support for 128-bit insns at that stage so qemu fails miserably (as expected) if launched with this option. Signed-off-by: Frédéric Pétrot <frederic.petrot@univ-grenoble-alpes.fr> Co-authored-by: Fabien Portas <fabien.portas@grenoble-inp.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20220106210108.138226-8-frederic.petrot@univ-grenoble-alpes.fr [ Changed by AF - Rename CPU to "x-rv128" ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-07 00:00:57 +03:00
case MXL_RV128:
hw/core/cpu: Return static value with gdb_arch_name() All implementations of gdb_arch_name() returns dynamic duplicates of static strings. It's also unlikely that there will be an implementation of gdb_arch_name() that returns a truly dynamic value due to the nature of the function returning a well-known identifiers. Qualify the value gdb_arch_name() with const and make all of its implementations return static strings. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230912224107.29669-8-akihiko.odaki@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231009164104.369749-15-alex.bennee@linaro.org>
2023-10-09 19:40:53 +03:00
return "riscv:rv64";
target/riscv: Replace riscv_cpu_is_32bit with riscv_cpu_mxl Shortly, the set of supported XL will not be just 32 and 64, and representing that properly using the enumeration will be imperative. Two places, booting and gdb, intentionally use misa_mxl_max to emphasize the use of the reset value of misa.mxl, and not the current cpu state. Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20211020031709.359469-5-richard.henderson@linaro.org Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-10-20 06:16:58 +03:00
default:
g_assert_not_reached();
gdb: riscv: Add target description Target description is not currently implemented in RISC-V architecture. Thus GDB won't set it properly when attached. The patch implements the target description response. Signed-off-by: Sylvain Pelissier <sylvain.pelissier@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210106204141.14027-1-sylvain.pelissier@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-01-06 23:41:41 +03:00
}
}
target/riscv: Generate the GDB XML file for CSR registers dynamically At present QEMU RISC-V uses a hardcoded XML to report the feature "org.gnu.gdb.riscv.csr" [1]. There are two major issues with the approach being used currently: - The XML does not specify the "regnum" field of a CSR entry, hence consecutive numbers are used by the remote GDB client to access CSRs. In QEMU we have to maintain a map table to convert the GDB number to the hardware number which is error prone. - The XML contains some CSRs that QEMU does not implement at all, which causes an "E14" response sent to remote GDB client. Change to generate the CSR register list dynamically, based on the availability presented in the CSR function table. This new approach will reflect a correct list of CSRs that QEMU actually implements. [1] https://sourceware.org/gdb/current/onlinedocs/gdb/RISC_002dV-Features.html#RISC_002dV-Features Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210116054123.5457-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-01-16 08:41:22 +03:00
static const char *riscv_gdb_get_dynamic_xml(CPUState *cs, const char *xmlname)
{
RISCVCPU *cpu = RISCV_CPU(cs);
if (strcmp(xmlname, "riscv-csr.xml") == 0) {
return cpu->dyn_csr_xml;
target/riscv: gdb: support vector registers for rv64 & rv32 Signed-off-by: Hsiangkai Wang <kai.wang@sifive.com> Signed-off-by: Greentime Hu <greentime.hu@sifive.com> Signed-off-by: Frank Chang <frank.chang@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20211210075704.23951-69-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-12-10 10:56:54 +03:00
} else if (strcmp(xmlname, "riscv-vector.xml") == 0) {
return cpu->dyn_vreg_xml;
target/riscv: Generate the GDB XML file for CSR registers dynamically At present QEMU RISC-V uses a hardcoded XML to report the feature "org.gnu.gdb.riscv.csr" [1]. There are two major issues with the approach being used currently: - The XML does not specify the "regnum" field of a CSR entry, hence consecutive numbers are used by the remote GDB client to access CSRs. In QEMU we have to maintain a map table to convert the GDB number to the hardware number which is error prone. - The XML contains some CSRs that QEMU does not implement at all, which causes an "E14" response sent to remote GDB client. Change to generate the CSR register list dynamically, based on the availability presented in the CSR function table. This new approach will reflect a correct list of CSRs that QEMU actually implements. [1] https://sourceware.org/gdb/current/onlinedocs/gdb/RISC_002dV-Features.html#RISC_002dV-Features Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210116054123.5457-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-01-16 08:41:22 +03:00
}
return NULL;
}
cpu: Introduce SysemuCPUOps structure Introduce a structure to hold handler specific to sysemu. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-15-f4bug@amsat.org> [rth: Squash "restrict hw/core/sysemu-cpu-ops.h" patch] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-17 13:51:31 +03:00
#ifndef CONFIG_USER_ONLY
target/riscv: cpu: Implement get_arch_id callback Implement the callback for getting the architecture-dependent CPU ID ie mhartid. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230303065055.915652-2-mchitale@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 09:50:54 +03:00
static int64_t riscv_get_arch_id(CPUState *cs)
{
RISCVCPU *cpu = RISCV_CPU(cs);
return cpu->env.mhartid;
}
cpu: Introduce SysemuCPUOps structure Introduce a structure to hold handler specific to sysemu. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-15-f4bug@amsat.org> [rth: Squash "restrict hw/core/sysemu-cpu-ops.h" patch] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-17 13:51:31 +03:00
#include "hw/core/sysemu-cpu-ops.h"
static const struct SysemuCPUOps riscv_sysemu_ops = {
cpu: Move CPUClass::get_phys_page_debug to SysemuCPUOps Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-21-f4bug@amsat.org> [rth: Drop declaration movement from target/*/cpu.h] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-17 13:51:37 +03:00
.get_phys_page_debug = riscv_cpu_get_phys_page_debug,
cpu: Move CPUClass::write_elf* to SysemuCPUOps The write_elf*() handlers are used to dump vmcore images. This feature is only meaningful for system emulation. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-19-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-17 13:51:35 +03:00
.write_elf64_note = riscv_cpu_write_elf64_note,
.write_elf32_note = riscv_cpu_write_elf32_note,
cpu: Move CPUClass::vmsd to SysemuCPUOps Migration is specific to system emulation. - Move the CPUClass::vmsd field to SysemuCPUOps, - restrict VMSTATE_CPU() macro to sysemu, - vmstate_dummy is now unused, remove it. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-16-f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-17 13:51:32 +03:00
.legacy_vmsd = &vmstate_riscv_cpu,
cpu: Introduce SysemuCPUOps structure Introduce a structure to hold handler specific to sysemu. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-15-f4bug@amsat.org> [rth: Squash "restrict hw/core/sysemu-cpu-ops.h" patch] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-17 13:51:31 +03:00
};
#endif
target/riscv/cpu.c: restrict 'mvendorid' value We're going to change the handling of mvendorid/marchid/mimpid by the KVM driver. Since these are always present in all CPUs let's put the same validation for everyone. It doesn't make sense to allow 'mvendorid' to be different than it is already set in named (vendor) CPUs. Generic (dynamic) CPUs can have any 'mvendorid' they want. Change 'mvendorid' to be a class property created via 'object_class_property_add', instead of using the DEFINE_PROP_UINT32() macro. This allow us to define a custom setter for it that will verify, for named CPUs, if mvendorid is different than it is already set by the CPU. This is the error thrown for the 'veyron-v1' CPU if 'mvendorid' is set to an invalid value: $ qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mvendorid=2 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mvendorid=2: Unable to change veyron-v1-riscv-cpu mvendorid (0x61f) 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-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:21 +03:00
static bool riscv_cpu_is_dynamic(Object *cpu_obj)
{
return object_dynamic_cast(cpu_obj, TYPE_RISCV_DYNAMIC_CPU) != NULL;
}
static void cpu_set_mvendorid(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
bool dynamic_cpu = riscv_cpu_is_dynamic(obj);
RISCVCPU *cpu = RISCV_CPU(obj);
uint32_t prev_val = cpu->cfg.mvendorid;
uint32_t value;
if (!visit_type_uint32(v, name, &value, errp)) {
return;
}
if (!dynamic_cpu && prev_val != value) {
error_setg(errp, "Unable to change %s mvendorid (0x%x)",
object_get_typename(obj), prev_val);
return;
}
cpu->cfg.mvendorid = value;
}
static void cpu_get_mvendorid(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
bool value = RISCV_CPU(obj)->cfg.mvendorid;
visit_type_bool(v, name, &value, errp);
}
target/riscv/cpu.c: restrict 'mimpid' value Following the same logic used with 'mvendorid' let's also restrict 'mimpid' for named CPUs. Generic CPUs keep setting the value freely. Note that we're getting rid of the default RISCV_CPU_MARCHID value. The reason is that this is not a good default since it's dynamic, changing with with every QEMU version, regardless of whether the actual implementation of the CPU changed from one QEMU version to the other. Named CPU should set it to a meaningful value instead and generic CPUs can set whatever they want. This is the error thrown for an invalid 'mimpid' value for the veyron-v1 CPU: $ ./qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mimpid=2 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mimpid=2: Unable to change veyron-v1-riscv-cpu mimpid (0x111) 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-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:22 +03:00
static void cpu_set_mimpid(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
bool dynamic_cpu = riscv_cpu_is_dynamic(obj);
RISCVCPU *cpu = RISCV_CPU(obj);
uint64_t prev_val = cpu->cfg.mimpid;
uint64_t value;
if (!visit_type_uint64(v, name, &value, errp)) {
return;
}
if (!dynamic_cpu && prev_val != value) {
error_setg(errp, "Unable to change %s mimpid (0x%" PRIu64 ")",
object_get_typename(obj), prev_val);
return;
}
cpu->cfg.mimpid = value;
}
static void cpu_get_mimpid(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
bool value = RISCV_CPU(obj)->cfg.mimpid;
visit_type_bool(v, name, &value, errp);
}
target/riscv/cpu.c: restrict 'marchid' value 'marchid' shouldn't be set to a different value as previously set for named CPUs. For all other CPUs it shouldn't be freely set either - the spec requires that 'marchid' can't have the MSB (most significant bit) set and every other bit set to zero, i.e. 0x80000000 is an invalid 'marchid' value for 32 bit CPUs. As with 'mimpid', setting a default value based on the current QEMU version is not a good idea because it implies that the CPU implementation changes from one QEMU version to the other. Named CPUs should set 'marchid' to a meaningful value instead, and generic CPUs can set to any valid value. For the 'veyron-v1' CPU this is the error thrown if 'marchid' is set to a different val: $ ./build/qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,marchid=0x80000000 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.marchid=0x80000000: Unable to change veyron-v1-riscv-cpu marchid (0x8000000000010000) And, for generics CPUs, this is the error when trying to set to an invalid val: $ ./build/qemu-system-riscv64 -M virt -nographic -cpu rv64,marchid=0x8000000000000000 qemu-system-riscv64: can't apply global rv64-riscv-cpu.marchid=0x8000000000000000: Unable to set marchid with MSB (64) bit set and the remaining bits zero 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-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:23 +03:00
static void cpu_set_marchid(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
bool dynamic_cpu = riscv_cpu_is_dynamic(obj);
RISCVCPU *cpu = RISCV_CPU(obj);
uint64_t prev_val = cpu->cfg.marchid;
uint64_t value, invalid_val;
uint32_t mxlen = 0;
if (!visit_type_uint64(v, name, &value, errp)) {
return;
}
if (!dynamic_cpu && prev_val != value) {
error_setg(errp, "Unable to change %s marchid (0x%" PRIu64 ")",
object_get_typename(obj), prev_val);
return;
}
switch (riscv_cpu_mxl(&cpu->env)) {
case MXL_RV32:
mxlen = 32;
break;
case MXL_RV64:
case MXL_RV128:
mxlen = 64;
break;
default:
g_assert_not_reached();
}
invalid_val = 1LL << (mxlen - 1);
if (value == invalid_val) {
error_setg(errp, "Unable to set marchid with MSB (%u) bit set "
"and the remaining bits zero", mxlen);
return;
}
cpu->cfg.marchid = value;
}
static void cpu_get_marchid(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
bool value = RISCV_CPU(obj)->cfg.marchid;
visit_type_bool(v, name, &value, errp);
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
static void riscv_cpu_class_init(ObjectClass *c, void *data)
{
RISCVCPUClass *mcc = RISCV_CPU_CLASS(c);
CPUClass *cc = CPU_CLASS(c);
DeviceClass *dc = DEVICE_CLASS(c);
target/riscv: Convert to 3-phase reset Convert the riscv CPU class to use 3-phase reset, so it doesn't need to use device_class_set_parent_reset() any more. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Edgar E. Iglesias <edgar@zeroasic.com> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-id: 20221124115023.2437291-15-peter.maydell@linaro.org
2022-11-24 14:50:17 +03:00
ResettableClass *rc = RESETTABLE_CLASS(c);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
riscv/cpu: use device_class_set_parent_realize Signed-off-by: Mao Zhongyi <maozhongyi@cmss.chinamobile.com> Reviewed-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2018-11-26 06:20:38 +03:00
device_class_set_parent_realize(dc, riscv_cpu_realize,
&mcc->parent_realize);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
target/riscv: Convert to 3-phase reset Convert the riscv CPU class to use 3-phase reset, so it doesn't need to use device_class_set_parent_reset() any more. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Edgar E. Iglesias <edgar@zeroasic.com> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-id: 20221124115023.2437291-15-peter.maydell@linaro.org
2022-11-24 14:50:17 +03:00
resettable_class_set_parent_phases(rc, NULL, riscv_cpu_reset_hold, NULL,
&mcc->parent_phases);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
cc->class_by_name = riscv_cpu_class_by_name;
cc->has_work = riscv_cpu_has_work;
cc->dump_state = riscv_cpu_dump_state;
cc->set_pc = riscv_cpu_set_pc;
hw/core: Add CPUClass.get_pc Populate this new method for all targets. Always match the result that would be given by cpu_get_tb_cpu_state, as we will want these values to correspond in the logs. Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (target/sparc) Signed-off-by: Richard Henderson <richard.henderson@linaro.org> --- Cc: Eduardo Habkost <eduardo@habkost.net> (supporter:Machine core) Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com> (supporter:Machine core) Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org> (reviewer:Machine core) Cc: Yanan Wang <wangyanan55@huawei.com> (reviewer:Machine core) Cc: Michael Rolnik <mrolnik@gmail.com> (maintainer:AVR TCG CPUs) Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> (maintainer:CRIS TCG CPUs) Cc: Taylor Simpson <tsimpson@quicinc.com> (supporter:Hexagon TCG CPUs) Cc: Song Gao <gaosong@loongson.cn> (maintainer:LoongArch TCG CPUs) Cc: Xiaojuan Yang <yangxiaojuan@loongson.cn> (maintainer:LoongArch TCG CPUs) Cc: Laurent Vivier <laurent@vivier.eu> (maintainer:M68K TCG CPUs) Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> (reviewer:MIPS TCG CPUs) Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com> (reviewer:MIPS TCG CPUs) Cc: Chris Wulff <crwulff@gmail.com> (maintainer:NiosII TCG CPUs) Cc: Marek Vasut <marex@denx.de> (maintainer:NiosII TCG CPUs) Cc: Stafford Horne <shorne@gmail.com> (odd fixer:OpenRISC TCG CPUs) Cc: Yoshinori Sato <ysato@users.sourceforge.jp> (reviewer:RENESAS RX CPUs) Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (maintainer:SPARC TCG CPUs) Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> (maintainer:TriCore TCG CPUs) Cc: Max Filippov <jcmvbkbc@gmail.com> (maintainer:Xtensa TCG CPUs) Cc: qemu-arm@nongnu.org (open list:ARM TCG CPUs) Cc: qemu-ppc@nongnu.org (open list:PowerPC TCG CPUs) Cc: qemu-riscv@nongnu.org (open list:RISC-V TCG CPUs) Cc: qemu-s390x@nongnu.org (open list:S390 TCG CPUs)
2022-09-30 20:31:21 +03:00
cc->get_pc = riscv_cpu_get_pc;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
cc->gdb_read_register = riscv_cpu_gdb_read_register;
cc->gdb_write_register = riscv_cpu_gdb_write_register;
RISC-V: Add hooks to use the gdb xml files. The gdb CSR xml file has registers in documentation order, not numerical order, so we need a table to map the register numbers. This also adds fairly standard gdb hooks to access xml specified registers. notice: The fpu xml from gdb 8.3 has unused register #, 65 and make first csr register # become 69. We register extra register on gdb to correct csr offset calculation Signed-off-by: Jim Wilson <jimw@sifive.com> Signed-off-by: Chih-Min Chao <chihmin.chao@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-03-15 13:26:59 +03:00
cc->gdb_num_core_regs = 33;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
cc->gdb_stop_before_watchpoint = true;
cc->disas_set_info = riscv_cpu_disas_set_info;
target/riscv: Convert to CPUClass::tlb_fill Note that env->pc is removed from the qemu_log as that value is garbage. The PC isn't recovered until cpu_restore_state, called from cpu_loop_exit_restore, called from riscv_raise_exception. Cc: qemu-riscv@nongnu.org Cc: Palmer Dabbelt <palmer@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-04-02 13:12:38 +03:00
#ifndef CONFIG_USER_ONLY
cpu: Introduce SysemuCPUOps structure Introduce a structure to hold handler specific to sysemu. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20210517105140.1062037-15-f4bug@amsat.org> [rth: Squash "restrict hw/core/sysemu-cpu-ops.h" patch] Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-05-17 13:51:31 +03:00
cc->sysemu_ops = &riscv_sysemu_ops;
target/riscv: cpu: Implement get_arch_id callback Implement the callback for getting the architecture-dependent CPU ID ie mhartid. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230303065055.915652-2-mchitale@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-03 09:50:54 +03:00
cc->get_arch_id = riscv_get_arch_id;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
#endif
gdb: riscv: Add target description Target description is not currently implemented in RISC-V architecture. Thus GDB won't set it properly when attached. The patch implements the target description response. Signed-off-by: Sylvain Pelissier <sylvain.pelissier@gmail.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210106204141.14027-1-sylvain.pelissier@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-01-06 23:41:41 +03:00
cc->gdb_arch_name = riscv_gdb_arch_name;
target/riscv: Generate the GDB XML file for CSR registers dynamically At present QEMU RISC-V uses a hardcoded XML to report the feature "org.gnu.gdb.riscv.csr" [1]. There are two major issues with the approach being used currently: - The XML does not specify the "regnum" field of a CSR entry, hence consecutive numbers are used by the remote GDB client to access CSRs. In QEMU we have to maintain a map table to convert the GDB number to the hardware number which is error prone. - The XML contains some CSRs that QEMU does not implement at all, which causes an "E14" response sent to remote GDB client. Change to generate the CSR register list dynamically, based on the availability presented in the CSR function table. This new approach will reflect a correct list of CSRs that QEMU actually implements. [1] https://sourceware.org/gdb/current/onlinedocs/gdb/RISC_002dV-Features.html#RISC_002dV-Features Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210116054123.5457-2-bmeng.cn@gmail.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-01-16 08:41:22 +03:00
cc->gdb_get_dynamic_xml = riscv_gdb_get_dynamic_xml;
target/riscv: remove CONFIG_TCG, as it is always TCG for now only TCG is allowed as an accelerator for riscv, so remove the CONFIG_TCG use. Signed-off-by: Claudio Fontana <cfontana@suse.de> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20210204163931.7358-3-cfontana@suse.de> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-02-04 19:39:10 +03:00
target/riscv/cpu.c: restrict 'mvendorid' value We're going to change the handling of mvendorid/marchid/mimpid by the KVM driver. Since these are always present in all CPUs let's put the same validation for everyone. It doesn't make sense to allow 'mvendorid' to be different than it is already set in named (vendor) CPUs. Generic (dynamic) CPUs can have any 'mvendorid' they want. Change 'mvendorid' to be a class property created via 'object_class_property_add', instead of using the DEFINE_PROP_UINT32() macro. This allow us to define a custom setter for it that will verify, for named CPUs, if mvendorid is different than it is already set by the CPU. This is the error thrown for the 'veyron-v1' CPU if 'mvendorid' is set to an invalid value: $ qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mvendorid=2 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mvendorid=2: Unable to change veyron-v1-riscv-cpu mvendorid (0x61f) 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-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:21 +03:00
object_class_property_add(c, "mvendorid", "uint32", cpu_get_mvendorid,
cpu_set_mvendorid, NULL, NULL);
target/riscv/cpu.c: restrict 'mimpid' value Following the same logic used with 'mvendorid' let's also restrict 'mimpid' for named CPUs. Generic CPUs keep setting the value freely. Note that we're getting rid of the default RISCV_CPU_MARCHID value. The reason is that this is not a good default since it's dynamic, changing with with every QEMU version, regardless of whether the actual implementation of the CPU changed from one QEMU version to the other. Named CPU should set it to a meaningful value instead and generic CPUs can set whatever they want. This is the error thrown for an invalid 'mimpid' value for the veyron-v1 CPU: $ ./qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mimpid=2 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mimpid=2: Unable to change veyron-v1-riscv-cpu mimpid (0x111) 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-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:22 +03:00
object_class_property_add(c, "mimpid", "uint64", cpu_get_mimpid,
cpu_set_mimpid, NULL, NULL);
target/riscv/cpu.c: restrict 'marchid' value 'marchid' shouldn't be set to a different value as previously set for named CPUs. For all other CPUs it shouldn't be freely set either - the spec requires that 'marchid' can't have the MSB (most significant bit) set and every other bit set to zero, i.e. 0x80000000 is an invalid 'marchid' value for 32 bit CPUs. As with 'mimpid', setting a default value based on the current QEMU version is not a good idea because it implies that the CPU implementation changes from one QEMU version to the other. Named CPUs should set 'marchid' to a meaningful value instead, and generic CPUs can set to any valid value. For the 'veyron-v1' CPU this is the error thrown if 'marchid' is set to a different val: $ ./build/qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,marchid=0x80000000 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.marchid=0x80000000: Unable to change veyron-v1-riscv-cpu marchid (0x8000000000010000) And, for generics CPUs, this is the error when trying to set to an invalid val: $ ./build/qemu-system-riscv64 -M virt -nographic -cpu rv64,marchid=0x8000000000000000 qemu-system-riscv64: can't apply global rv64-riscv-cpu.marchid=0x8000000000000000: Unable to set marchid with MSB (64) bit set and the remaining bits zero 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-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:23 +03:00
object_class_property_add(c, "marchid", "uint64", cpu_get_marchid,
cpu_set_marchid, NULL, NULL);
target/riscv/cpu.c: restrict 'mvendorid' value We're going to change the handling of mvendorid/marchid/mimpid by the KVM driver. Since these are always present in all CPUs let's put the same validation for everyone. It doesn't make sense to allow 'mvendorid' to be different than it is already set in named (vendor) CPUs. Generic (dynamic) CPUs can have any 'mvendorid' they want. Change 'mvendorid' to be a class property created via 'object_class_property_add', instead of using the DEFINE_PROP_UINT32() macro. This allow us to define a custom setter for it that will verify, for named CPUs, if mvendorid is different than it is already set by the CPU. This is the error thrown for the 'veyron-v1' CPU if 'mvendorid' is set to an invalid value: $ qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mvendorid=2 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mvendorid=2: Unable to change veyron-v1-riscv-cpu mvendorid (0x61f) 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-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-06 13:17:21 +03:00
qdev: set properties with device_class_set_props() The following patch will need to handle properties registration during class_init time. Let's use a device_class_set_props() setter. spatch --macro-file scripts/cocci-macro-file.h --sp-file ./scripts/coccinelle/qdev-set-props.cocci --keep-comments --in-place --dir . @@ typedef DeviceClass; DeviceClass *d; expression val; @@ - d->props = val + device_class_set_props(d, val) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20200110153039.1379601-20-marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-01-10 18:30:32 +03:00
device_class_set_props(dc, riscv_cpu_properties);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
target/riscv: Fix lines with over 80 characters Fix lines with over 80 characters for both code and comments. Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230405085813.40643-5-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-05 11:58:13 +03:00
static void riscv_isa_string_ext(RISCVCPU *cpu, char **isa_str,
int max_str_len)
target/riscv: Add isa extenstion strings to the device tree The Linux kernel parses the ISA extensions from "riscv,isa" DT property. It used to parse only the single letter base extensions until now. A generic ISA extension parsing framework was proposed[1] recently that can parse multi-letter ISA extensions as well. Generate the extended ISA string by appending the available ISA extensions to the "riscv,isa" string if it is enabled so that kernel can process it. [1] https://lkml.org/lkml/2022/2/15/263 Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Suggested-by: Heiko Stubner <heiko@sntech.de> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-Id: <20220329195657.1725425-1-atishp@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-03-29 22:56:57 +03:00
{
char *old = *isa_str;
char *new = *isa_str;
int i;
for (i = 0; i < ARRAY_SIZE(isa_edata_arr); i++) {
target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabled We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:16 +03:00
if (isa_ext_is_enabled(cpu, isa_edata_arr[i].ext_enable_offset)) {
target/riscv: Add isa extenstion strings to the device tree The Linux kernel parses the ISA extensions from "riscv,isa" DT property. It used to parse only the single letter base extensions until now. A generic ISA extension parsing framework was proposed[1] recently that can parse multi-letter ISA extensions as well. Generate the extended ISA string by appending the available ISA extensions to the "riscv,isa" string if it is enabled so that kernel can process it. [1] https://lkml.org/lkml/2022/2/15/263 Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Suggested-by: Heiko Stubner <heiko@sntech.de> Signed-off-by: Atish Patra <atishp@rivosinc.com> Message-Id: <20220329195657.1725425-1-atishp@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-03-29 22:56:57 +03:00
new = g_strconcat(old, "_", isa_edata_arr[i].name, NULL);
g_free(old);
old = new;
}
}
*isa_str = new;
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
char *riscv_isa_string(RISCVCPU *cpu)
{
int i;
target/riscv: misa to ISA string conversion fix Some bits in RISC-V `misa' CSR should not be reflected in the ISA string. For instance, `S' and `U' (represents existence of supervisor and user mode, respectively) in `misa' CSR must not be copied since neither `S' nor `U' are valid single-letter extensions. This commit also removes all reserved/dropped single-letter "extensions" from the list. - "B": Not going to be a single-letter extension (misa.B is reserved). - "J": Not going to be a single-letter extension (misa.J is reserved). - "K": Not going to be a single-letter extension (misa.K is reserved). - "L": Dropped. - "N": Dropped. - "T": Dropped. It also clarifies that the variable `riscv_single_letter_exts' is a single-letter extension order list. Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <4a4c11213a161a7eedabe46abe58b351bb0e2ef2.1648473008.git.research_trasio@irq.a4lg.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-03-28 16:11:23 +03:00
const size_t maxlen = sizeof("rv128") + sizeof(riscv_single_letter_exts);
RISC-V: Fix riscv_isa_string memory size bug This version uses a constant size memory buffer sized for the maximum possible ISA string length. It also uses g_new instead of g_new0, uses more efficient logic to append extensions and adds manual zero termination of the string. Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> [PMM: Use qemu_tolower() rather than tolower()] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-20 00:18:49 +03:00
char *isa_str = g_new(char, maxlen);
char *p = isa_str + snprintf(isa_str, maxlen, "rv%d", TARGET_LONG_BITS);
target/riscv: misa to ISA string conversion fix Some bits in RISC-V `misa' CSR should not be reflected in the ISA string. For instance, `S' and `U' (represents existence of supervisor and user mode, respectively) in `misa' CSR must not be copied since neither `S' nor `U' are valid single-letter extensions. This commit also removes all reserved/dropped single-letter "extensions" from the list. - "B": Not going to be a single-letter extension (misa.B is reserved). - "J": Not going to be a single-letter extension (misa.J is reserved). - "K": Not going to be a single-letter extension (misa.K is reserved). - "L": Dropped. - "N": Dropped. - "T": Dropped. It also clarifies that the variable `riscv_single_letter_exts' is a single-letter extension order list. Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <4a4c11213a161a7eedabe46abe58b351bb0e2ef2.1648473008.git.research_trasio@irq.a4lg.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-03-28 16:11:23 +03:00
for (i = 0; i < sizeof(riscv_single_letter_exts) - 1; i++) {
if (cpu->env.misa_ext & RV(riscv_single_letter_exts[i])) {
*p++ = qemu_tolower(riscv_single_letter_exts[i]);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
}
RISC-V: Fix riscv_isa_string memory size bug This version uses a constant size memory buffer sized for the maximum possible ISA string length. It also uses g_new instead of g_new0, uses more efficient logic to append extensions and adds manual zero termination of the string. Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> [PMM: Use qemu_tolower() rather than tolower()] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-20 00:18:49 +03:00
*p = '\0';
target/riscv: Add short-isa-string option Because some operating systems don't correctly parse long ISA extension string, this commit adds short-isa-string boolean option to disable generating long ISA extension strings on Device Tree. For instance, enabling Zfinx and Zdinx extensions and booting Linux (5.17 or earlier) with FPU support caused a kernel panic. Operating Systems which short-isa-string might be helpful: 1. Linux (5.17 or earlier) 2. FreeBSD (at least 14.0-CURRENT) 3. OpenBSD (at least current development version) Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <7c1fe5f06b0a7646a47e9bcdddb1042bb60c69c8.1652181972.git.research_trasio@irq.a4lg.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-05-10 14:29:08 +03:00
if (!cpu->cfg.short_isa_string) {
riscv_isa_string_ext(cpu, &isa_str, maxlen);
}
RISC-V: Fix riscv_isa_string memory size bug This version uses a constant size memory buffer sized for the maximum possible ISA string length. It also uses g_new instead of g_new0, uses more efficient logic to append extensions and adds manual zero termination of the string. Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> [PMM: Use qemu_tolower() rather than tolower()] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-20 00:18:49 +03:00
return isa_str;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
static gint riscv_cpu_list_compare(gconstpointer a, gconstpointer b)
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
{
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
ObjectClass *class_a = (ObjectClass *)a;
ObjectClass *class_b = (ObjectClass *)b;
const char *name_a, *name_b;
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
name_a = object_class_get_name(class_a);
name_b = object_class_get_name(class_b);
return strcmp(name_a, name_b);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
static void riscv_cpu_list_entry(gpointer data, gpointer user_data)
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
{
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
const char *typename = object_class_get_name(OBJECT_CLASS(data));
int len = strlen(typename) - strlen(RISCV_CPU_TYPE_SUFFIX);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
target: Simplify how the TARGET_cpu_list() print The various TARGET_cpu_list() take an fprintf()-like callback and a FILE * to pass to it. Their callers (vl.c's main() via list_cpus(), bsd-user/main.c's main(), linux-user/main.c's main()) all pass fprintf() and stdout. Thus, the flexibility provided by the (rather tiresome) indirection isn't actually used. Drop the callback, and call qemu_printf() instead. Calling printf() would also work, but would make the code unsuitable for monitor context without making it simpler. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190417191805.28198-10-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-04-17 22:17:57 +03:00
qemu_printf("%.*s\n", len, typename);
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
}
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
target: Simplify how the TARGET_cpu_list() print The various TARGET_cpu_list() take an fprintf()-like callback and a FILE * to pass to it. Their callers (vl.c's main() via list_cpus(), bsd-user/main.c's main(), linux-user/main.c's main()) all pass fprintf() and stdout. Thus, the flexibility provided by the (rather tiresome) indirection isn't actually used. Drop the callback, and call qemu_printf() instead. Calling printf() would also work, but would make the code unsuitable for monitor context without making it simpler. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190417191805.28198-10-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-04-17 22:17:57 +03:00
void riscv_cpu_list(void)
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
{
GSList *list;
list = object_class_get_list(TYPE_RISCV_CPU, false);
list = g_slist_sort(list, riscv_cpu_list_compare);
target: Simplify how the TARGET_cpu_list() print The various TARGET_cpu_list() take an fprintf()-like callback and a FILE * to pass to it. Their callers (vl.c's main() via list_cpus(), bsd-user/main.c's main(), linux-user/main.c's main()) all pass fprintf() and stdout. Thus, the flexibility provided by the (rather tiresome) indirection isn't actually used. Drop the callback, and call qemu_printf() instead. Calling printf() would also work, but would make the code unsuitable for monitor context without making it simpler. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190417191805.28198-10-armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-04-17 22:17:57 +03:00
g_slist_foreach(list, riscv_cpu_list_entry, NULL);
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
g_slist_free(list);
RISC-V CPU Core Definition Add CPU state header, CPU definitions and initialization routines Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Sagar Karandikar <sagark@eecs.berkeley.edu> Signed-off-by: Michael Clark <mjc@sifive.com>
2018-03-02 15:31:10 +03:00
}
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
#define DEFINE_CPU(type_name, initfn) \
{ \
.name = type_name, \
.parent = TYPE_RISCV_CPU, \
.instance_init = initfn \
}
target/riscv: add TYPE_RISCV_DYNAMIC_CPU This new abstract type will be used to differentiate between static and non-static CPUs in query-cpu-definitions. All generic CPUs were changed to be of this type. Named CPUs are kept as TYPE_RISCV_CPU and will still be considered static. This is the output of query-cpu-definitions after this change for the riscv64 target: $ ./build/qemu-system-riscv64 -S -M virt -display none -qmp stdio {"QMP": {"version": (...)} {"execute": "qmp_capabilities", "arguments": {"enable": ["oob"]}} {"return": {}} {"execute": "query-cpu-definitions"} {"return": [ {"name": "rv64", "typename": "rv64-riscv-cpu", "static": false, "deprecated": false}, {"name": "sifive-e51", "typename": "sifive-e51-riscv-cpu", "static": true, "deprecated": false}, {"name": "any", "typename": "any-riscv-cpu", "static": false, "deprecated": false}, {"name": "x-rv128", "typename": "x-rv128-riscv-cpu", "static": false, "deprecated": false}, {"name": "shakti-c", "typename": "shakti-c-riscv-cpu", "static": true, "deprecated": false}, {"name": "thead-c906", "typename": "thead-c906-riscv-cpu", "static": true, "deprecated": false}, {"name": "sifive-u54", "typename": "sifive-u54-riscv-cpu", "static": true, "deprecated": false} ]} Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230411183511.189632-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-11 21:35:11 +03:00
#define DEFINE_DYNAMIC_CPU(type_name, initfn) \
{ \
.name = type_name, \
.parent = TYPE_RISCV_DYNAMIC_CPU, \
.instance_init = initfn \
}
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
static const TypeInfo riscv_cpu_type_infos[] = {
{
.name = TYPE_RISCV_CPU,
.parent = TYPE_CPU,
.instance_size = sizeof(RISCVCPU),
target/*: Add instance_align to all cpu base classes The omission of alignment has technically been wrong since 269bd5d8f61, where QEMU_ALIGNED was added to CPUTLBDescFast. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-09-14 01:06:21 +03:00
.instance_align = __alignof(RISCVCPU),
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
.instance_init = riscv_cpu_init,
.abstract = true,
.class_size = sizeof(RISCVCPUClass),
.class_init = riscv_cpu_class_init,
},
target/riscv: add TYPE_RISCV_DYNAMIC_CPU This new abstract type will be used to differentiate between static and non-static CPUs in query-cpu-definitions. All generic CPUs were changed to be of this type. Named CPUs are kept as TYPE_RISCV_CPU and will still be considered static. This is the output of query-cpu-definitions after this change for the riscv64 target: $ ./build/qemu-system-riscv64 -S -M virt -display none -qmp stdio {"QMP": {"version": (...)} {"execute": "qmp_capabilities", "arguments": {"enable": ["oob"]}} {"return": {}} {"execute": "query-cpu-definitions"} {"return": [ {"name": "rv64", "typename": "rv64-riscv-cpu", "static": false, "deprecated": false}, {"name": "sifive-e51", "typename": "sifive-e51-riscv-cpu", "static": true, "deprecated": false}, {"name": "any", "typename": "any-riscv-cpu", "static": false, "deprecated": false}, {"name": "x-rv128", "typename": "x-rv128-riscv-cpu", "static": false, "deprecated": false}, {"name": "shakti-c", "typename": "shakti-c-riscv-cpu", "static": true, "deprecated": false}, {"name": "thead-c906", "typename": "thead-c906-riscv-cpu", "static": true, "deprecated": false}, {"name": "sifive-u54", "typename": "sifive-u54-riscv-cpu", "static": true, "deprecated": false} ]} Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230411183511.189632-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-11 21:35:11 +03:00
{
.name = TYPE_RISCV_DYNAMIC_CPU,
.parent = TYPE_RISCV_CPU,
.abstract = true,
},
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_ANY, riscv_any_cpu_init),
target/riscv: add 'max' CPU type The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-12 16:24:13 +03:00
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_MAX, riscv_max_cpu_init),
target/riscv: Add host cpu type 'host' type cpu is set isa to RV32 or RV64 simply, more isa info will obtain from KVM in kvm_arch_init_vcpu() 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-10-jiangyifei@huawei.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2022-01-12 11:13:25 +03:00
#if defined(CONFIG_KVM)
DEFINE_CPU(TYPE_RISCV_CPU_HOST, riscv_host_cpu_init),
#endif
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
#if defined(TARGET_RISCV32)
target/riscv: add TYPE_RISCV_DYNAMIC_CPU This new abstract type will be used to differentiate between static and non-static CPUs in query-cpu-definitions. All generic CPUs were changed to be of this type. Named CPUs are kept as TYPE_RISCV_CPU and will still be considered static. This is the output of query-cpu-definitions after this change for the riscv64 target: $ ./build/qemu-system-riscv64 -S -M virt -display none -qmp stdio {"QMP": {"version": (...)} {"execute": "qmp_capabilities", "arguments": {"enable": ["oob"]}} {"return": {}} {"execute": "query-cpu-definitions"} {"return": [ {"name": "rv64", "typename": "rv64-riscv-cpu", "static": false, "deprecated": false}, {"name": "sifive-e51", "typename": "sifive-e51-riscv-cpu", "static": true, "deprecated": false}, {"name": "any", "typename": "any-riscv-cpu", "static": false, "deprecated": false}, {"name": "x-rv128", "typename": "x-rv128-riscv-cpu", "static": false, "deprecated": false}, {"name": "shakti-c", "typename": "shakti-c-riscv-cpu", "static": true, "deprecated": false}, {"name": "thead-c906", "typename": "thead-c906-riscv-cpu", "static": true, "deprecated": false}, {"name": "sifive-u54", "typename": "sifive-u54-riscv-cpu", "static": true, "deprecated": false} ]} Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230411183511.189632-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-11 21:35:11 +03:00
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE32, rv32_base_cpu_init),
target/riscv: Rename IBEX CPU init routine Current IBEX CPU init routine name seems to be too generic. Since it uses a different reset vector from the generic one, it merits a dedicated name. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1592268641-7478-2-git-send-email-bmeng.cn@gmail.com Message-Id: <1592268641-7478-2-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-16 03:50:37 +03:00
DEFINE_CPU(TYPE_RISCV_CPU_IBEX, rv32_ibex_cpu_init),
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E31, rv32_sifive_e_cpu_init),
riscv: Keep the CPU init routine names consistent Adding a _ to keep some consistency among the CPU init routines. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <1591837729-27486-4-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2020-06-11 04:08:49 +03:00
DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E34, rv32_imafcu_nommu_cpu_init),
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U34, rv32_sifive_u_cpu_init),
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
#elif defined(TARGET_RISCV64)
target/riscv: add TYPE_RISCV_DYNAMIC_CPU This new abstract type will be used to differentiate between static and non-static CPUs in query-cpu-definitions. All generic CPUs were changed to be of this type. Named CPUs are kept as TYPE_RISCV_CPU and will still be considered static. This is the output of query-cpu-definitions after this change for the riscv64 target: $ ./build/qemu-system-riscv64 -S -M virt -display none -qmp stdio {"QMP": {"version": (...)} {"execute": "qmp_capabilities", "arguments": {"enable": ["oob"]}} {"return": {}} {"execute": "query-cpu-definitions"} {"return": [ {"name": "rv64", "typename": "rv64-riscv-cpu", "static": false, "deprecated": false}, {"name": "sifive-e51", "typename": "sifive-e51-riscv-cpu", "static": true, "deprecated": false}, {"name": "any", "typename": "any-riscv-cpu", "static": false, "deprecated": false}, {"name": "x-rv128", "typename": "x-rv128-riscv-cpu", "static": false, "deprecated": false}, {"name": "shakti-c", "typename": "shakti-c-riscv-cpu", "static": true, "deprecated": false}, {"name": "thead-c906", "typename": "thead-c906-riscv-cpu", "static": true, "deprecated": false}, {"name": "sifive-u54", "typename": "sifive-u54-riscv-cpu", "static": true, "deprecated": false} ]} Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230411183511.189632-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-11 21:35:11 +03:00
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE64, rv64_base_cpu_init),
target/riscv: Specify the XLEN for CPUs Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bin.meng@windriver.com> Tested-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Acked-by: Palmer Dabbelt <palmerdabbelt@google.com> Message-id: c1da66affbb83ec4a2fbeb0194293bd24d65f5dc.1608142916.git.alistair.francis@wdc.com
2020-12-16 21:22:54 +03:00
DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_E51, rv64_sifive_e_cpu_init),
DEFINE_CPU(TYPE_RISCV_CPU_SIFIVE_U54, rv64_sifive_u_cpu_init),
target/riscv: Add Shakti C class CPU C-Class is a member of the SHAKTI family of processors from IIT-M. It is an extremely configurable and commercial-grade 5-stage in-order core supporting the standard RV64GCSUN ISA extensions. Signed-off-by: Vijai Kumar K <vijai@behindbytes.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210401181457.73039-2-vijai@behindbytes.com Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2021-04-01 21:14:54 +03:00
DEFINE_CPU(TYPE_RISCV_CPU_SHAKTI_C, rv64_sifive_u_cpu_init),
RISC-V: Add initial support for T-Head C906 This patch adds the T-Head C906 to the list of known CPUs. Selecting this CPUs will automatically enable the available ISA extensions of the CPUs (incl. vendor extensions). Co-developed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230131202013.2541053-13-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-01-31 23:20:11 +03:00
DEFINE_CPU(TYPE_RISCV_CPU_THEAD_C906, rv64_thead_c906_cpu_init),
target/riscv: add Ventana's Veyron V1 CPU Add a virtual CPU for Ventana's first CPU named veyron-v1. It runs exclusively for the rv64 target. It's tested with the 'virt' board. CPU specs and general information can be found here: https://www.nextplatform.com/2023/02/02/the-first-risc-v-shot-across-the-datacenter-bow/ Signed-off-by: Rahul Pathak <rpathak@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230418123624.16414-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-18 15:36:24 +03:00
DEFINE_CPU(TYPE_RISCV_CPU_VEYRON_V1, rv64_veyron_v1_cpu_init),
target/riscv: add TYPE_RISCV_DYNAMIC_CPU This new abstract type will be used to differentiate between static and non-static CPUs in query-cpu-definitions. All generic CPUs were changed to be of this type. Named CPUs are kept as TYPE_RISCV_CPU and will still be considered static. This is the output of query-cpu-definitions after this change for the riscv64 target: $ ./build/qemu-system-riscv64 -S -M virt -display none -qmp stdio {"QMP": {"version": (...)} {"execute": "qmp_capabilities", "arguments": {"enable": ["oob"]}} {"return": {}} {"execute": "query-cpu-definitions"} {"return": [ {"name": "rv64", "typename": "rv64-riscv-cpu", "static": false, "deprecated": false}, {"name": "sifive-e51", "typename": "sifive-e51-riscv-cpu", "static": true, "deprecated": false}, {"name": "any", "typename": "any-riscv-cpu", "static": false, "deprecated": false}, {"name": "x-rv128", "typename": "x-rv128-riscv-cpu", "static": false, "deprecated": false}, {"name": "shakti-c", "typename": "shakti-c-riscv-cpu", "static": true, "deprecated": false}, {"name": "thead-c906", "typename": "thead-c906-riscv-cpu", "static": true, "deprecated": false}, {"name": "sifive-u54", "typename": "sifive-u54-riscv-cpu", "static": true, "deprecated": false} ]} Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230411183511.189632-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-04-11 21:35:11 +03:00
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE128, rv128_base_cpu_init),
RISC-V: Convert cpu definition to future model - Model borrowed from target/sh4/cpu.c - Rewrote riscv_cpu_list to use object_class_get_list - Dropped 'struct RISCVCPUInfo' and used TypeInfo array - Replaced riscv_cpu_register_types with DEFINE_TYPES - Marked base class as abstract - Fixes -cpu list Cc: Igor Mammedov <imammedo@redhat.com> Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Signed-off-by: Michael Clark <mjc@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2018-03-09 01:12:31 +03:00
#endif
};
DEFINE_TYPES(riscv_cpu_type_infos)
Reference in New Issue Copy Permalink