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

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

2956 lines
89 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"
target/riscv: move 'vlen' to riscv_cpu_properties[] Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared with KVM. And, as done with every option we migrated to riscv_cpu_properties[], vendor CPUs can't have their 'vlen' value changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:37 +03:00
#include "hw/core/qdev-prop-internal.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 new isa extension detection devicetree properties A few months ago I submitted a patch to various lists, deprecating "riscv,isa" with a lengthy commit message [0] that is now commit aeb71e42caae ("dt-bindings: riscv: deprecate riscv,isa") in the Linux kernel tree. Primarily, the goal was to replace "riscv,isa" with a new set of properties that allowed for strictly defining the meaning of various extensions, where "riscv,isa" was tied to whatever definitions inflicted upon us by the ISA manual, which have seen some variance over time. Two new properties were introduced: "riscv,isa-base" and "riscv,isa-extensions". The former is a simple string to communicate the base ISA implemented by a hart and the latter an array of strings used to communicate the set of ISA extensions supported, per the definitions of each substring in extensions.yaml [1]. A beneficial side effect was also the ability to define vendor extensions in a more "official" way, as the ISA manual and other RVI specifications only covered the format for vendor extensions in the ISA string, but not the meaning of vendor extensions, for obvious reasons. Add support for setting these two new properties in the devicetrees for the various devicetree platforms supported by QEMU for RISC-V. The Linux kernel already supports parsing ISA extensions from these new properties, and documenting them in the dt-binding is a requirement for new extension detection being added to the kernel. A side effect of the implementation is that the meaning for elements in "riscv,isa" and in "riscv,isa-extensions" are now tied together as they are constructed from the same source. The same applies to the ISA string provided in ACPI tables, but there does not appear to be any strict definitions of meanings in ACPI land either. Link: https://lore.kernel.org/qemu-riscv/20230702-eats-scorebook-c951f170d29f@spud/ [0] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/riscv/extensions.yaml [1] Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240124-unvarying-foothold-9dde2aaf95d4@spud> [ Changes by AF: - Rebase on recent changes ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-24 15:55:50 +03:00
#include "sysemu/device_tree.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: move KVM only files to kvm subdir Move the files to a 'kvm' dir to promote more code separation between accelerators and making our lives easier supporting build options such as --disable-tcg. Rename kvm.c to kvm-cpu.c to keep it in line with its TCG counterpart. 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-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:57:02 +03:00
#include "kvm/kvm_riscv.h"
target/riscv/tcg: add tcg_cpu_finalize_features() The query-cpu-model-expansion API is capable of passing extra properties to a given CPU model and tell callers if this custom configuration is valid. The RISC-V version of the API is not quite there yet. The reason is the realize() flow in the TCG driver, where most of the validation is done in tcg_cpu_realizefn(). riscv_cpu_finalize_features() is then used to validate satp_mode for both TCG and KVM CPUs. Our ARM friends uses a concept of 'finalize_features()', a step done in the end of realize() where the CPU features are validated. We have a riscv_cpu_finalize_features() helper that, at this moment, is only validating satp_mode. Re-use this existing helper to do all CPU extension validation we required after at the end of realize(). Make it public to allow APIs to use it. At this moment only the TCG driver requires a realize() time validation, thus, to avoid adding accelerator specific helpers in the API, riscv_cpu_finalize_features() uses riscv_tcg_cpu_finalize_features() if we are running TCG. The API will then use riscv_cpu_finalize_features() regardless of the current accelerator. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-18 22:56:35 +03:00
#include "tcg/tcg-cpu.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: Add infrastructure for 'B' MISA extension Add the infrastructure for the 'B' extension which is the union of the Zba, Zbb and Zbs instructions. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240111161644.33630-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-11 19:16:43 +03:00
static const char riscv_single_letter_exts[] = "IEMAFDQCBPVH";
target/riscv/kvm: do not use riscv_cpu_add_misa_properties() riscv_cpu_add_misa_properties() is being used to fill the missing KVM MISA properties but it is a TCG helper that was adapted to do so. We'll move it to tcg-cpu.c in the next patches, meaning that KVM needs to fill the remaining MISA properties on its own. Do not use riscv_cpu_add_misa_properties(). Let's create a new array with all available MISA bits we support that can be read by KVM. The array is zero terminate to allow us to iterate through it without knowing its size. Then, inside kvm_riscv_add_cpu_user_properties(), we'll create all KVM MISA properties as usual and then use this array to add any missing MISA properties with the riscv_cpu_add_kvm_unavail_prop() helper. Note that we're creating misa_bits[], and not using the existing 'riscv_single_letter_exts[]', because the latter is tuned for riscv,isa related functions and it doesn't have all MISA bits we support. Commit 0e2c377023 ("target/riscv: misa to ISA string conversion fix") has the full context. While we're at it, move both satp and the multi-letter extension properties to kvm_riscv_add_cpu_user_properties() as well. 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: <20230925175709.35696-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:57:03 +03:00
const uint32_t misa_bits[] = {RVI, RVE, RVM, RVA, RVF, RVD, RVV,
target/riscv: Add infrastructure for 'B' MISA extension Add the infrastructure for the 'B' extension which is the union of the Zba, Zbb and Zbs instructions. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240111161644.33630-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-11 19:16:43 +03:00
RVC, RVS, RVU, RVH, RVJ, RVG, RVB, 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
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/cpu.c: add riscv_cpu_is_32bit() Next patch will need to retrieve if a given RISCVCPU is 32 or 64 bit. The existing helper riscv_is_32bit() (hw/riscv/boot.c) will always check the first CPU of a given hart array, not any given CPU. Create a helper to retrieve the info for any given CPU, not the first CPU of the hart array. The helper is using the same 32 bit check that riscv_cpu_satp_mode_finalize() was doing. 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: <20231218125334.37184-23-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:30 +03:00
bool riscv_cpu_is_32bit(RISCVCPU *cpu)
{
return riscv_cpu_mxl(&cpu->env) == MXL_RV32;
}
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
/* Hash that stores general user set numeric options */
static GHashTable *general_user_opts;
static void cpu_option_add_user_setting(const char *optname, uint32_t value)
{
g_hash_table_insert(general_user_opts, (gpointer)optname,
GUINT_TO_POINTER(value));
}
target/riscv: create finalize_features() for KVM To turn cbom_blocksize and cboz_blocksize into class properties we need KVM specific changes. KVM is creating its own version of these options with a customized setter() that prevents users from picking an invalid value during init() time. This comes at the cost of duplicating each option that KVM supports. This will keep happening for each new shared option KVM implements in the future. We can avoid that by using the same property TCG uses and adding specific KVM handling during finalize() time, like TCG already does with riscv_tcg_cpu_finalize_features(). To do that, the common CPU property offers a way of knowing if an option was user set or not, sparing us from doing unneeded syscalls. riscv_kvm_cpu_finalize_features() is then created using the same KVMScratch CPU we already use during init() time, since finalize() time is still too early to use the official KVM CPU for it. cbom_blocksize and cboz_blocksize are then handled during finalize() in the same way they're handled by their KVM specific setter. With this change we can proceed with the blocksize changes in the common code without breaking the KVM driver. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:54 +03:00
bool riscv_cpu_option_set(const char *optname)
{
return g_hash_table_contains(general_user_opts, optname);
}
target/riscv/cpu.c: export isa_edata_arr[] This array will be read by the TCG accel class, allowing it to handle priv spec verifications on its own. The array will remain here in cpu.c because it's also used by the riscv,isa string function. To export it we'll finish it with an empty element since ARRAY_SIZE() won't work outside of cpu.c. Get rid of its ARRAY_SIZE() usage now to alleviate the changes for the next patch. 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: <20230925175709.35696-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:57:08 +03:00
#define ISA_EXT_DATA_ENTRY(_name, _min_ver, _prop) \
{#_name, _min_ver, CPU_CFG_OFFSET(_prop)}
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
*/
target/riscv/cpu.c: export isa_edata_arr[] This array will be read by the TCG accel class, allowing it to handle priv spec verifications on its own. The array will remain here in cpu.c because it's also used by the riscv,isa string function. To export it we'll finish it with an empty element since ARRAY_SIZE() won't work outside of cpu.c. Get rid of its ARRAY_SIZE() usage now to alleviate the changes for the next patch. 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: <20230925175709.35696-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:57:08 +03:00
const RISCVIsaExtData isa_edata_arr[] = {
target/riscv: add riscv,isa to named features Further discussions after the introduction of rva22 support in QEMU revealed that what we've been calling 'named features' are actually regular extensions, with their respective riscv,isa DTs. This is clarified in [1]. [2] is a bug tracker asking for the profile spec to be less cryptic about it. As far as QEMU goes we understand extensions as something that the user can enable/disable in the command line. This isn't the case for named features, so we'll have to reach a middle ground. We'll keep our existing nomenclature 'named features' to refer to any extension that the user can't control in the command line. We'll also do the following: - 'svade' and 'zic64b' flags are renamed to 'ext_svade' and 'ext_zic64b'. 'ext_svade' and 'ext_zic64b' now have riscv,isa strings and priv_spec versions; - skip name feature check in cpu_bump_multi_ext_priv_ver(). Now that named features have a riscv,isa and an entry in isa_edata_arr[] we don't need to gate the call to cpu_cfg_ext_get_min_version() anymore. [1] https://github.com/riscv/riscv-profiles/issues/121 [2] https://github.com/riscv/riscv-profiles/issues/142 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: <20240215223955.969568-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:51 +03:00
ISA_EXT_DATA_ENTRY(zic64b, PRIV_VERSION_1_12_0, ext_zic64b),
target/riscv: rename ext_icbom to ext_zicbom Add a leading 'z' to improve grepping. When one wants to search for uses of zicbom they're more likely to do 'grep -i zicbom' than 'grep -i icbom'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:03 +03:00
ISA_EXT_DATA_ENTRY(zicbom, PRIV_VERSION_1_12_0, ext_zicbom),
target/riscv: add zicbop extension flag QEMU already implements zicbom (Cache Block Management Operations) and zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv: add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for what would be the instructions for zicbop (Cache Block Prefetch Operations), which are now no-ops. The RVA22U64 profile mandates zicbop, which means that applications that run with this profile might expect zicbop to be present in the riscv,isa DT and might behave badly if it's absent. Adding zicbop as an extension will make our future RVA22U64 implementation more in line with what userspace expects and, if/when cache block prefetch operations became relevant to QEMU, we already have the extension flag to turn then on/off as needed. 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: <20231218125334.37184-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:13 +03:00
ISA_EXT_DATA_ENTRY(zicbop, PRIV_VERSION_1_12_0, ext_zicbop),
target/riscv: rename ext_icboz to ext_zicboz Add a leading 'z' to improve grepping. When one wants to search for uses of zicboz they're more likely to do 'grep -i zicboz' than 'grep -i icboz'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:04 +03:00
ISA_EXT_DATA_ENTRY(zicboz, PRIV_VERSION_1_12_0, ext_zicboz),
target/riscv: do not enable all named features by default Commit 3b8022269c added the capability of named features/profile extensions to be added in riscv,isa. To do that we had to assign priv versions for each one of them in isa_edata_arr[]. But this resulted in a side-effect: vendor CPUs that aren't running priv_version_latest started to experience warnings for these profile extensions [1]: | $ qemu-system-riscv32 -M sifive_e | qemu-system-riscv32: warning: disabling zic64b extension for hart 0x00000000 because privilege spec version does not match | qemu-system-riscv32: warning: disabling ziccamoa extension for hart 0x00000000 because privilege spec version does not match This is benign as far as the CPU behavior is concerned since disabling both extensions is a no-op (aside from riscv,isa). But the warnings are unpleasant to deal with, especially because we're sending user warnings for extensions that users can't enable/disable. Instead of enabling all named features all the time, separate them by priv version. During finalize() time, after we decided which priv_version the CPU is running, enable/disable all the named extensions based on the priv spec chosen. This will be enough for a bug fix, but as a future work we should look into how we can name these extensions in a way that we don't need an explicit ext_name => priv_ver as we're doing here. The named extensions being added in isa_edata_arr[] that will be enabled/disabled based solely on priv version can be removed from riscv_cpu_named_features[]. 'zic64b' is an extension that can be disabled based on block sizes so it'll retain its own flag and entry. [1] https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg02592.html Reported-by: Clément Chigot <chigot@adacore.com> Fixes: 3b8022269c ("target/riscv: add riscv,isa to named features") Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Tested-by: Clément Chigot <chigot@adacore.com> Message-ID: <20240312203214.350980-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-12 23:32:14 +03:00
ISA_EXT_DATA_ENTRY(ziccamoa, PRIV_VERSION_1_11_0, has_priv_1_11),
ISA_EXT_DATA_ENTRY(ziccif, PRIV_VERSION_1_11_0, has_priv_1_11),
ISA_EXT_DATA_ENTRY(zicclsm, PRIV_VERSION_1_11_0, has_priv_1_11),
ISA_EXT_DATA_ENTRY(ziccrse, PRIV_VERSION_1_11_0, has_priv_1_11),
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(zicond, PRIV_VERSION_1_12_0, ext_zicond),
target/riscv: add zicntr extension flag for TCG zicntr is the Base Counters and Timers extension described in chapter 12 of the unprivileged spec. It describes support for RDCYCLE, RDTIME and RDINSTRET. QEMU already implements it in TCG way before it was a discrete extension. zicntr is part of the RVA22 profile, so let's add it to QEMU to make the future profile implementation flag complete. Given than it represents an already existing feature, default it to 'true' for all CPUs. For TCG, we need a way to disable zicntr if the user wants to. This is done by restricting access to the CYCLE, TIME, and INSTRET counters via the 'ctr()' predicate when we're about to access them. Disabling zicntr happens via the command line or if its dependency, zicsr, happens to be disabled. We'll check for zicsr during realize() and, in case it's absent, disable zicntr. However, if the user was explicit about having zicntr support, error out instead of disabling it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-23 18:39:24 +03:00
ISA_EXT_DATA_ENTRY(zicntr, PRIV_VERSION_1_12_0, ext_zicntr),
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
ISA_EXT_DATA_ENTRY(zicsr, PRIV_VERSION_1_10_0, ext_zicsr),
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
ISA_EXT_DATA_ENTRY(zifencei, PRIV_VERSION_1_10_0, ext_zifencei),
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: add zihpm extension flag for TCG zihpm is the Hardware Performance Counters extension described in chapter 12 of the unprivileged spec. It describes support for 29 unprivileged performance counters, hpmcounter3-hpmcounter31. As with zicntr, QEMU already implements zihpm before it was even an extension. zihpm is also part of the RVA22 profile, so add it to QEMU to complement the future profile implementation. Default it to 'true' for all existing CPUs since it was always present in the code. As for disabling it, there is already code in place in target/riscv/csr.c in all predicates for these counters (ctr() and mctr()) that disables them if cpu->cfg.pmu_num is zero. Thus, setting cpu->cfg.pmu_num to zero if 'zihpm=false' is enough to disable the extension. Set cpu->pmu_avail_ctrs mask to zero as well since this is also checked to verify if the counters exist. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-23 18:39:26 +03:00
ISA_EXT_DATA_ENTRY(zihpm, PRIV_VERSION_1_12_0, ext_zihpm),
target/riscv: Add zimop extension Zimop extension defines an encoding space for 40 MOPs.The Zimop extension defines 32 MOP instructions named MOP.R.n, where n is an integer between 0 and 31, inclusive. The Zimop extension additionally defines 8 MOP instructions named MOP.RR.n, where n is an integer between 0 and 7. These 40 MOPs initially are defined to simply write zero to x[rd], but are designed to be redefined by later extensions to perform some other action. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Deepak Gupta <debug@rivosinc.com> Message-ID: <20240709113652.1239-2-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-09 14:36:42 +03:00
ISA_EXT_DATA_ENTRY(zimop, PRIV_VERSION_1_13_0, ext_zimop),
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: do not enable all named features by default Commit 3b8022269c added the capability of named features/profile extensions to be added in riscv,isa. To do that we had to assign priv versions for each one of them in isa_edata_arr[]. But this resulted in a side-effect: vendor CPUs that aren't running priv_version_latest started to experience warnings for these profile extensions [1]: | $ qemu-system-riscv32 -M sifive_e | qemu-system-riscv32: warning: disabling zic64b extension for hart 0x00000000 because privilege spec version does not match | qemu-system-riscv32: warning: disabling ziccamoa extension for hart 0x00000000 because privilege spec version does not match This is benign as far as the CPU behavior is concerned since disabling both extensions is a no-op (aside from riscv,isa). But the warnings are unpleasant to deal with, especially because we're sending user warnings for extensions that users can't enable/disable. Instead of enabling all named features all the time, separate them by priv version. During finalize() time, after we decided which priv_version the CPU is running, enable/disable all the named extensions based on the priv spec chosen. This will be enough for a bug fix, but as a future work we should look into how we can name these extensions in a way that we don't need an explicit ext_name => priv_ver as we're doing here. The named extensions being added in isa_edata_arr[] that will be enabled/disabled based solely on priv version can be removed from riscv_cpu_named_features[]. 'zic64b' is an extension that can be disabled based on block sizes so it'll retain its own flag and entry. [1] https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg02592.html Reported-by: Clément Chigot <chigot@adacore.com> Fixes: 3b8022269c ("target/riscv: add riscv,isa to named features") Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Tested-by: Clément Chigot <chigot@adacore.com> Message-ID: <20240312203214.350980-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-12 23:32:14 +03:00
ISA_EXT_DATA_ENTRY(za64rs, PRIV_VERSION_1_12_0, has_priv_1_11),
target/riscv: Expose Zaamo and Zalrsc extensions Expose the newly added extensions to the guest and allow their control through the CPU properties. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240123111030.15074-4-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-23 14:10:30 +03:00
ISA_EXT_DATA_ENTRY(zaamo, PRIV_VERSION_1_12_0, ext_zaamo),
target/riscv: Expose zabha extension as a cpu property Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240709113652.1239-11-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-09 14:36:51 +03:00
ISA_EXT_DATA_ENTRY(zabha, PRIV_VERSION_1_13_0, ext_zabha),
target/riscv: Add support for Zacas extension Add support for amocas.w/d/q instructions which are part of the ratified Zacas extension: https://github.com/riscv/riscv-zacas Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231207153842.32401-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-07 18:32:30 +03:00
ISA_EXT_DATA_ENTRY(zacas, PRIV_VERSION_1_12_0, ext_zacas),
target/riscv: Support Zama16b extension Zama16b is the property that misaligned load/stores/atomics within a naturally aligned 16-byte region are atomic. According to the specification, Zama16b applies only to AMOs, loads and stores defined in the base ISAs, and loads and stores of no more than XLEN bits defined in the F, D, and Q extensions. Thus it should not apply to zacas or RVC instructions. For an instruction in that set, if all accessed bytes lie within 16B granule, the instruction will not raise an exception for reasons of address alignment, and the instruction will give rise to only one memory operation for the purposes of RVWMO—i.e., it will execute atomically. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240709113652.1239-6-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-09 14:36:46 +03:00
ISA_EXT_DATA_ENTRY(zama16b, PRIV_VERSION_1_13_0, ext_zama16b),
target/riscv: Expose Zaamo and Zalrsc extensions Expose the newly added extensions to the guest and allow their control through the CPU properties. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240123111030.15074-4-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-23 14:10:30 +03:00
ISA_EXT_DATA_ENTRY(zalrsc, PRIV_VERSION_1_12_0, ext_zalrsc),
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),
target/riscv: Add zcmop extension Zcmop defines eight 16-bit MOP instructions named C.MOP.n, where n is an odd integer between 1 and 15, inclusive. C.MOP.n is encoded in the reserved encoding space corresponding to C.LUI xn, 0. Unlike the MOPs defined in the Zimop extension, the C.MOP.n instructions are defined to not write any register. In current implementation, C.MOP.n only has an check function, without any other more behavior. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Deepak Gupta <debug@rivosinc.com> Message-ID: <20240709113652.1239-4-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-09 14:36:44 +03:00
ISA_EXT_DATA_ENTRY(zcmop, PRIV_VERSION_1_13_0, ext_zcmop),
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(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),
RISC-V: Add support for Ztso The Ztso extension is already ratified, this adds it as a CPU property and adds various fences throughout the port in order to allow TSO targets to function on weaker hosts. We need no fences for AMOs as they're already SC, the places we need barriers are described. These fences are placed in the RISC-V backend rather than TCG as is planned for x86-on-arm64 because RISC-V allows heterogeneous (and likely soon dynamic) hart memory models. Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-ID: <20240207122256.902627-2-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-07 15:22:54 +03:00
ISA_EXT_DATA_ENTRY(ztso, PRIV_VERSION_1_12_0, ext_ztso),
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),
target/riscv: Add support for Zve32x extension Add support for Zve32x extension and replace some checks for Zve32f with Zve32x, since Zve32f depends on Zve32x. Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240328022343.6871-2-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-28 05:23:10 +03:00
ISA_EXT_DATA_ENTRY(zve32x, PRIV_VERSION_1_10_0, ext_zve32x),
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(zve64f, PRIV_VERSION_1_10_0, ext_zve64f),
ISA_EXT_DATA_ENTRY(zve64d, PRIV_VERSION_1_10_0, ext_zve64d),
target/riscv: Add support for Zve64x extension Add support for Zve64x extension. Enabling Zve64f enables Zve64x and enabling Zve64x enables Zve32x according to their dependency. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2107 Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240328022343.6871-3-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-28 05:23:11 +03:00
ISA_EXT_DATA_ENTRY(zve64x, PRIV_VERSION_1_10_0, ext_zve64x),
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: Expose Zvkb extension property Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-6-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-26 18:18:12 +03:00
ISA_EXT_DATA_ENTRY(zvkb, PRIV_VERSION_1_12_0, ext_zvkb),
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: Expose Zvkn[c|g] extnesion properties Expose the properties of NIST Algorithm Suite related extensions (Zvkn, Zvknc, Zvkng). Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-8-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-26 18:18:14 +03:00
ISA_EXT_DATA_ENTRY(zvkn, PRIV_VERSION_1_12_0, ext_zvkn),
ISA_EXT_DATA_ENTRY(zvknc, PRIV_VERSION_1_12_0, ext_zvknc),
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: Expose Zvkn[c|g] extnesion properties Expose the properties of NIST Algorithm Suite related extensions (Zvkn, Zvknc, Zvkng). Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-8-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-26 18:18:14 +03:00
ISA_EXT_DATA_ENTRY(zvkng, PRIV_VERSION_1_12_0, ext_zvkng),
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: Expose Zvks[c|g] extnesion properties Expose the properties of ShangMi Algorithm Suite related extensions (Zvks, Zvksc, Zvksg). Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-10-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-26 18:18:16 +03:00
ISA_EXT_DATA_ENTRY(zvks, PRIV_VERSION_1_12_0, ext_zvks),
ISA_EXT_DATA_ENTRY(zvksc, PRIV_VERSION_1_12_0, ext_zvksc),
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: Expose Zvks[c|g] extnesion properties Expose the properties of ShangMi Algorithm Suite related extensions (Zvks, Zvksc, Zvksg). Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-10-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-26 18:18:16 +03:00
ISA_EXT_DATA_ENTRY(zvksg, PRIV_VERSION_1_12_0, ext_zvksg),
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: Expose Zvkt extension property Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-26 18:18:09 +03:00
ISA_EXT_DATA_ENTRY(zvkt, PRIV_VERSION_1_12_0, ext_zvkt),
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: Add cycle & instret privilege mode filtering properties This adds the properties for ISA extension smcntrpmf. Patches implementing it will follow. Signed-off-by: Kaiwen Xue <kaiwenx@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240711-smcntrpmf_v7-v8-3-b7c38ae7b263@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-12 01:31:06 +03:00
ISA_EXT_DATA_ENTRY(smcntrpmf, PRIV_VERSION_1_12_0, ext_smcntrpmf),
Add epmp to extensions list and rename it to smepmp Smepmp is a ratified extension which qemu refers to as epmp. Rename epmp to smepmp and add it to extension list so that it is added to the isa string. Signed-off-by: Himanshu Chauhan <hchauhan@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065546.1431579-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-19 09:55:46 +03:00
ISA_EXT_DATA_ENTRY(smepmp, PRIV_VERSION_1_12_0, ext_smepmp),
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),
target/riscv: do not enable all named features by default Commit 3b8022269c added the capability of named features/profile extensions to be added in riscv,isa. To do that we had to assign priv versions for each one of them in isa_edata_arr[]. But this resulted in a side-effect: vendor CPUs that aren't running priv_version_latest started to experience warnings for these profile extensions [1]: | $ qemu-system-riscv32 -M sifive_e | qemu-system-riscv32: warning: disabling zic64b extension for hart 0x00000000 because privilege spec version does not match | qemu-system-riscv32: warning: disabling ziccamoa extension for hart 0x00000000 because privilege spec version does not match This is benign as far as the CPU behavior is concerned since disabling both extensions is a no-op (aside from riscv,isa). But the warnings are unpleasant to deal with, especially because we're sending user warnings for extensions that users can't enable/disable. Instead of enabling all named features all the time, separate them by priv version. During finalize() time, after we decided which priv_version the CPU is running, enable/disable all the named extensions based on the priv spec chosen. This will be enough for a bug fix, but as a future work we should look into how we can name these extensions in a way that we don't need an explicit ext_name => priv_ver as we're doing here. The named extensions being added in isa_edata_arr[] that will be enabled/disabled based solely on priv version can be removed from riscv_cpu_named_features[]. 'zic64b' is an extension that can be disabled based on block sizes so it'll retain its own flag and entry. [1] https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg02592.html Reported-by: Clément Chigot <chigot@adacore.com> Fixes: 3b8022269c ("target/riscv: add riscv,isa to named features") Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Tested-by: Clément Chigot <chigot@adacore.com> Message-ID: <20240312203214.350980-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-12 23:32:14 +03:00
ISA_EXT_DATA_ENTRY(ssccptr, PRIV_VERSION_1_11_0, has_priv_1_11),
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(sscofpmf, PRIV_VERSION_1_12_0, ext_sscofpmf),
target/riscv: do not enable all named features by default Commit 3b8022269c added the capability of named features/profile extensions to be added in riscv,isa. To do that we had to assign priv versions for each one of them in isa_edata_arr[]. But this resulted in a side-effect: vendor CPUs that aren't running priv_version_latest started to experience warnings for these profile extensions [1]: | $ qemu-system-riscv32 -M sifive_e | qemu-system-riscv32: warning: disabling zic64b extension for hart 0x00000000 because privilege spec version does not match | qemu-system-riscv32: warning: disabling ziccamoa extension for hart 0x00000000 because privilege spec version does not match This is benign as far as the CPU behavior is concerned since disabling both extensions is a no-op (aside from riscv,isa). But the warnings are unpleasant to deal with, especially because we're sending user warnings for extensions that users can't enable/disable. Instead of enabling all named features all the time, separate them by priv version. During finalize() time, after we decided which priv_version the CPU is running, enable/disable all the named extensions based on the priv spec chosen. This will be enough for a bug fix, but as a future work we should look into how we can name these extensions in a way that we don't need an explicit ext_name => priv_ver as we're doing here. The named extensions being added in isa_edata_arr[] that will be enabled/disabled based solely on priv version can be removed from riscv_cpu_named_features[]. 'zic64b' is an extension that can be disabled based on block sizes so it'll retain its own flag and entry. [1] https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg02592.html Reported-by: Clément Chigot <chigot@adacore.com> Fixes: 3b8022269c ("target/riscv: add riscv,isa to named features") Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Tested-by: Clément Chigot <chigot@adacore.com> Message-ID: <20240312203214.350980-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-12 23:32:14 +03:00
ISA_EXT_DATA_ENTRY(sscounterenw, PRIV_VERSION_1_12_0, has_priv_1_12),
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(sstc, PRIV_VERSION_1_12_0, ext_sstc),
target/riscv: do not enable all named features by default Commit 3b8022269c added the capability of named features/profile extensions to be added in riscv,isa. To do that we had to assign priv versions for each one of them in isa_edata_arr[]. But this resulted in a side-effect: vendor CPUs that aren't running priv_version_latest started to experience warnings for these profile extensions [1]: | $ qemu-system-riscv32 -M sifive_e | qemu-system-riscv32: warning: disabling zic64b extension for hart 0x00000000 because privilege spec version does not match | qemu-system-riscv32: warning: disabling ziccamoa extension for hart 0x00000000 because privilege spec version does not match This is benign as far as the CPU behavior is concerned since disabling both extensions is a no-op (aside from riscv,isa). But the warnings are unpleasant to deal with, especially because we're sending user warnings for extensions that users can't enable/disable. Instead of enabling all named features all the time, separate them by priv version. During finalize() time, after we decided which priv_version the CPU is running, enable/disable all the named extensions based on the priv spec chosen. This will be enough for a bug fix, but as a future work we should look into how we can name these extensions in a way that we don't need an explicit ext_name => priv_ver as we're doing here. The named extensions being added in isa_edata_arr[] that will be enabled/disabled based solely on priv version can be removed from riscv_cpu_named_features[]. 'zic64b' is an extension that can be disabled based on block sizes so it'll retain its own flag and entry. [1] https://lists.gnu.org/archive/html/qemu-devel/2024-03/msg02592.html Reported-by: Clément Chigot <chigot@adacore.com> Fixes: 3b8022269c ("target/riscv: add riscv,isa to named features") Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Tested-by: Clément Chigot <chigot@adacore.com> Message-ID: <20240312203214.350980-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-12 23:32:14 +03:00
ISA_EXT_DATA_ENTRY(sstvala, PRIV_VERSION_1_12_0, has_priv_1_12),
ISA_EXT_DATA_ENTRY(sstvecd, PRIV_VERSION_1_12_0, has_priv_1_12),
target/riscv: add riscv,isa to named features Further discussions after the introduction of rva22 support in QEMU revealed that what we've been calling 'named features' are actually regular extensions, with their respective riscv,isa DTs. This is clarified in [1]. [2] is a bug tracker asking for the profile spec to be less cryptic about it. As far as QEMU goes we understand extensions as something that the user can enable/disable in the command line. This isn't the case for named features, so we'll have to reach a middle ground. We'll keep our existing nomenclature 'named features' to refer to any extension that the user can't control in the command line. We'll also do the following: - 'svade' and 'zic64b' flags are renamed to 'ext_svade' and 'ext_zic64b'. 'ext_svade' and 'ext_zic64b' now have riscv,isa strings and priv_spec versions; - skip name feature check in cpu_bump_multi_ext_priv_ver(). Now that named features have a riscv,isa and an entry in isa_edata_arr[] we don't need to gate the call to cpu_cfg_ext_get_min_version() anymore. [1] https://github.com/riscv/riscv-profiles/issues/121 [2] https://github.com/riscv/riscv-profiles/issues/142 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: <20240215223955.969568-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:51 +03:00
ISA_EXT_DATA_ENTRY(svade, PRIV_VERSION_1_11_0, ext_svade),
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(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/cpu.c: export isa_edata_arr[] This array will be read by the TCG accel class, allowing it to handle priv spec verifications on its own. The array will remain here in cpu.c because it's also used by the riscv,isa string function. To export it we'll finish it with an empty element since ARRAY_SIZE() won't work outside of cpu.c. Get rid of its ARRAY_SIZE() usage now to alleviate the changes for the next patch. 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: <20230925175709.35696-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:57:08 +03:00
DEFINE_PROP_END_OF_LIST(),
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: 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: make riscv_cpu_is_vendor() public We'll use this function in target/riscv/cpu.c to implement setters that won't allow vendor CPU options to be changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:31 +03:00
bool riscv_cpu_is_vendor(Object *cpu_obj)
{
return object_dynamic_cast(cpu_obj, TYPE_RISCV_VENDOR_CPU) != NULL;
}
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: 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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
void riscv_cpu_set_misa_ext(CPURISCVState *env, 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_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
}
target/riscv: use misa_mxl_max to populate isa string rather than TARGET_LONG_BITS A cpu may not have the same xlen as the compile time target, and misa_mxl_max is the source of truth for what the hart supports. The conversion from misa_mxl_max to xlen already has one user, so introduce a helper and use that to populate the isa string. Link: https://lore.kernel.org/qemu-riscv/20240108-efa3f83dcd3997dc0af458d7@orel/ Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240124-swear-monthly-56c281f809a6@spud> [ Changes by AF: - Convert to use RISCVCPUClass *mcc ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-24 15:55:49 +03:00
int riscv_cpu_max_xlen(RISCVCPUClass *mcc)
{
return 16 << mcc->misa_mxl_max;
}
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)
{
target/riscv: add rv64i CPU We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile support, a way to load a multitude of extensions with a single flag. Profile support is going to be implemented shortly, so let's add a CPU for it. The new 'rv64i' CPU will have only RVI loaded. It is inspired in the profile specification that dictates, for RVA22U64 [1]: "RVA22U64 Mandatory Base RV64I is the mandatory base ISA for RVA22U64" And so it seems that RV64I is the mandatory base ISA for all profiles listed in [1], making it an ideal CPU to use with profile support. rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features from pre-existent CPUs: - it allows extensions to be enabled, like generic CPUs; - it will not inherit extension defaults, like vendor CPUs. This is the minimum extension set to boot OpenSBI and buildroot using rv64i: ./build/qemu-system-riscv64 -nographic -M virt \ -cpu rv64i,sv39=true,g=true,c=true,s=true,u=true Our minimal riscv,isa in this case will be: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd# [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc 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: <20231218125334.37184-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:12 +03:00
/*
* Bare CPUs do not default to the max available.
* Users must set a valid satp_mode in the command
* line.
*/
if (object_dynamic_cast(OBJECT(cpu), TYPE_RISCV_BARE_CPU) != NULL) {
warn_report("No satp mode set. Defaulting to 'bare'");
cpu->cfg.satp_mode.map = (1 << VM_1_10_MBARE);
return;
}
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.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
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;
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
cpu->cfg.mmu = true;
target/riscv: move 'pmp' to riscv_cpu_properties[] Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:34 +03:00
cpu->cfg.pmp = true;
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +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
env->priv_ver = PRIV_VERSION_LATEST;
#ifndef CONFIG_USER_ONLY
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
#ifdef TARGET_RISCV32
set_satp_mode_max_supported(cpu, VM_1_10_SV32);
#else
set_satp_mode_max_supported(cpu, VM_1_10_SV57);
#endif
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
#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
{
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
cpu->cfg.mmu = true;
target/riscv: move 'pmp' to riscv_cpu_properties[] Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:34 +03:00
cpu->cfg.pmp = true;
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, 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() */
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
cpu->cfg.ext_zifencei = true;
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
cpu->cfg.ext_zicsr = 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
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, 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() */
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
cpu->cfg.ext_zifencei = true;
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
cpu->cfg.ext_zicsr = 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
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, 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);
riscv: thead: Add th.sxstatus CSR emulation The th.sxstatus CSR can be used to identify available custom extension on T-Head CPUs. The CSR is documented here: https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadsxstatus.adoc An important property of this patch is, that the th.sxstatus MAEE field is not set (indicating that XTheadMae is not available). XTheadMae is a memory attribute extension (similar to Svpbmt) which is implemented in many T-Head CPUs (C906, C910, etc.) and utilizes bits in PTEs that are marked as reserved. QEMU maintainers prefer to not implement XTheadMae, so we need give kernels a mechanism to identify if XTheadMae is available in a system or not. And this patch introduces this mechanism in QEMU in a way that's compatible with real HW (i.e., probing the th.sxstatus.MAEE bit). Further context can be found on the list: https://lists.gnu.org/archive/html/qemu-devel/2024-02/msg00775.html Reviewed-by: LIU Zhiwei <zhiwe_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-ID: <20240429073656.2486732-1-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-04-29 10:36:56 +03:00
th_register_custom_csrs(cpu);
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/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);
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, RVG | RVC | RVS | RVU | RVH);
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
env->priv_ver = PRIV_VERSION_1_12_0;
/* Enable ISA extensions */
cpu->cfg.mmu = true;
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
cpu->cfg.ext_zifencei = true;
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
cpu->cfg.ext_zicsr = 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.pmp = true;
target/riscv: rename ext_icbom to ext_zicbom Add a leading 'z' to improve grepping. When one wants to search for uses of zicbom they're more likely to do 'grep -i zicbom' than 'grep -i icbom'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:03 +03:00
cpu->cfg.ext_zicbom = 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.cbom_blocksize = 64;
cpu->cfg.cboz_blocksize = 64;
target/riscv: rename ext_icboz to ext_zicboz Add a leading 'z' to improve grepping. When one wants to search for uses of zicboz they're more likely to do 'grep -i zicboz' than 'grep -i icboz'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:04 +03:00
cpu->cfg.ext_zicboz = 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_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: Restrict 'rv128' machine to TCG accelerator We only build for 32/64-bit hosts, so TCG is required for 128-bit targets. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230626232007.8933-5-philmd@linaro.org>
2023-06-26 23:36:10 +03:00
#ifdef CONFIG_TCG
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)
{
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
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
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);
}
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
cpu->cfg.mmu = true;
target/riscv: move 'pmp' to riscv_cpu_properties[] Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:34 +03:00
cpu->cfg.pmp = true;
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
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: Restrict 'rv128' machine to TCG accelerator We only build for 32/64-bit hosts, so TCG is required for 128-bit targets. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230626232007.8933-5-philmd@linaro.org>
2023-06-26 23:36:10 +03:00
#endif /* CONFIG_TCG */
target/riscv: add rv64i CPU We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile support, a way to load a multitude of extensions with a single flag. Profile support is going to be implemented shortly, so let's add a CPU for it. The new 'rv64i' CPU will have only RVI loaded. It is inspired in the profile specification that dictates, for RVA22U64 [1]: "RVA22U64 Mandatory Base RV64I is the mandatory base ISA for RVA22U64" And so it seems that RV64I is the mandatory base ISA for all profiles listed in [1], making it an ideal CPU to use with profile support. rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features from pre-existent CPUs: - it allows extensions to be enabled, like generic CPUs; - it will not inherit extension defaults, like vendor CPUs. This is the minimum extension set to boot OpenSBI and buildroot using rv64i: ./build/qemu-system-riscv64 -nographic -M virt \ -cpu rv64i,sv39=true,g=true,c=true,s=true,u=true Our minimal riscv,isa in this case will be: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd# [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc 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: <20231218125334.37184-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:12 +03:00
static void rv64i_bare_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, RVI);
target/riscv: add rv64i CPU We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile support, a way to load a multitude of extensions with a single flag. Profile support is going to be implemented shortly, so let's add a CPU for it. The new 'rv64i' CPU will have only RVI loaded. It is inspired in the profile specification that dictates, for RVA22U64 [1]: "RVA22U64 Mandatory Base RV64I is the mandatory base ISA for RVA22U64" And so it seems that RV64I is the mandatory base ISA for all profiles listed in [1], making it an ideal CPU to use with profile support. rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features from pre-existent CPUs: - it allows extensions to be enabled, like generic CPUs; - it will not inherit extension defaults, like vendor CPUs. This is the minimum extension set to boot OpenSBI and buildroot using rv64i: ./build/qemu-system-riscv64 -nographic -M virt \ -cpu rv64i,sv39=true,g=true,c=true,s=true,u=true Our minimal riscv,isa in this case will be: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd# [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc 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: <20231218125334.37184-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:12 +03:00
}
target/riscv: add rv32i, rv32e and rv64e CPUs A bare bones 32 bit RVI CPU, rv32i, will make users lives easier when a full customized 32 bit CPU is desired, and users won't need to disable defaults by hand as they would with the rv32 CPU. [1] has an example of a situation that would be avoided with rv32i. In fact, add bare bones CPUs for RVE as well. Trying to use RVE in QEMU requires one to disable every single default extension, including RVI, and then add the desirable extension set. Adding rv32e/rv64e makes it more pleasant to use embedded CPUs in QEMU. [1] https://lore.kernel.org/qemu-riscv/258be47f-97be-4308-bed5-dc34ef7ff954@Spark/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122123348.973288-3-dbarboza@ventanamicro.com> [ Changes by AF: - Rebase on latest changes ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 15:33:48 +03:00
static void rv64e_bare_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
riscv_cpu_set_misa_ext(env, RVE);
}
target/riscv: Restrict 'rv128' machine to TCG accelerator We only build for 32/64-bit hosts, so TCG is required for 128-bit targets. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230626232007.8933-5-philmd@linaro.org>
2023-06-26 23:36:10 +03:00
#else /* !TARGET_RISCV64 */
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)
{
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
CPURISCVState *env = &cpu->env;
cpu->cfg.mmu = true;
target/riscv: move 'pmp' to riscv_cpu_properties[] Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:34 +03:00
cpu->cfg.pmp = true;
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, 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() */
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
cpu->cfg.ext_zifencei = true;
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
cpu->cfg.ext_zicsr = 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
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, 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() */
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
cpu->cfg.ext_zifencei = true;
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
cpu->cfg.ext_zicsr = 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
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, RVI | RVM | RVC | RVU);
target/riscv: cpu: Set the OpenTitan priv to 1.12.0 Set the Ibex CPU priv to 1.12.0 to ensure that smepmp/epmp is correctly enabled. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231102003424.2003428-3-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-11-02 03:34:24 +03:00
env->priv_ver = PRIV_VERSION_1_12_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() */
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
cpu->cfg.ext_zifencei = true;
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
cpu->cfg.ext_zicsr = 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
cpu->cfg.pmp = true;
Add epmp to extensions list and rename it to smepmp Smepmp is a ratified extension which qemu refers to as epmp. Rename epmp to smepmp and add it to extension list so that it is added to the isa string. Signed-off-by: Himanshu Chauhan <hchauhan@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065546.1431579-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-19 09:55:46 +03:00
cpu->cfg.ext_smepmp = 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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
riscv_cpu_set_misa_ext(env, 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() */
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
cpu->cfg.ext_zifencei = true;
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
cpu->cfg.ext_zicsr = 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
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
}
target/riscv: add rv32i, rv32e and rv64e CPUs A bare bones 32 bit RVI CPU, rv32i, will make users lives easier when a full customized 32 bit CPU is desired, and users won't need to disable defaults by hand as they would with the rv32 CPU. [1] has an example of a situation that would be avoided with rv32i. In fact, add bare bones CPUs for RVE as well. Trying to use RVE in QEMU requires one to disable every single default extension, including RVI, and then add the desirable extension set. Adding rv32e/rv64e makes it more pleasant to use embedded CPUs in QEMU. [1] https://lore.kernel.org/qemu-riscv/258be47f-97be-4308-bed5-dc34ef7ff954@Spark/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122123348.973288-3-dbarboza@ventanamicro.com> [ Changes by AF: - Rebase on latest changes ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 15:33:48 +03:00
static void rv32i_bare_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
riscv_cpu_set_misa_ext(env, RVI);
}
static void rv32e_bare_cpu_init(Object *obj)
{
CPURISCVState *env = &RISCV_CPU(obj)->env;
riscv_cpu_set_misa_ext(env, RVE);
}
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
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);
cpu: Call object_class_dynamic_cast() once in cpu_class_by_name() For all targets, the CPU class returned from CPUClass::class_by_name() and object_class_dynamic_cast(oc, CPU_RESOLVING_TYPE) need to be compatible. Lets apply the check in cpu_class_by_name() for once, instead of having the check in CPUClass::class_by_name() for individual target. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Gavin Shan <gshan@redhat.com> Message-ID: <20231114235628.534334-4-gshan@redhat.com>
2023-09-08 11:09:23 +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
return oc;
}
target/riscv: add riscv_cpu_get_name() We'll introduce generic errors that will output a CPU type name via its RISCVCPU pointer. Create a helper for that. Use the helper in tcg_cpu_realizefn() instead of hardcoding the 'host' CPU name. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230926183109.165878-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-26 21:31:08 +03:00
char *riscv_cpu_get_name(RISCVCPU *cpu)
{
RISCVCPUClass *rcc = RISCV_CPU_GET_CLASS(cpu);
const char *typename = object_class_get_name(OBJECT_CLASS(rcc));
g_assert(g_str_has_suffix(typename, RISCV_CPU_TYPE_SUFFIX));
target: Use generic cpu_model_from_type() Use generic cpu_model_from_type() when the CPU model name needs to be extracted from the CPU type name. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231114235628.534334-23-gshan@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-11-15 02:56:19 +03:00
return cpu_model_from_type(typename);
target/riscv: add riscv_cpu_get_name() We'll introduce generic errors that will output a CPU type name via its RISCVCPU pointer. Create a helper for that. Use the helper in tcg_cpu_realizefn() instead of hardcoding the 'host' CPU name. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230926183109.165878-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-26 21:31:08 +03:00
}
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);
}
}
target/riscv: add 'vlenb' field in cpu->cfg Our usage of 'vlenb' is overwhelming superior than the use of 'vlen'. We're using 'vlenb' most of the time, having to do 'vlen >> 3' or 'vlen / 8' in every instance. In hindsight we would be better if the 'vlenb' property was introduced instead of 'vlen'. That's not what happened, and now we can't easily get rid of it due to user scripts all around. What we can do, however, is to change our internal representation to use 'vlenb'. Add a 'vlenb' field in cpu->cfg. It'll be set via the existing 'vlen' property, i.e. setting 'vlen' will also set 'vlenb'. We'll replace all 'vlen >> 3' code to use 'vlenb' directly. Start with the single instance we have in target/riscv/cpu.c. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 19:10:55 +03:00
uint16_t vlenb = cpu->cfg.vlenb;
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
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;
}
target: Set TCGCPUOps::cpu_exec_halt to target's has_work implementation Currently the TCGCPUOps::cpu_exec_halt method is optional, and if it is not set then the default is to call the CPUClass::has_work method (which has an identical function signature). We would like to make the cpu_exec_halt method mandatory so we can remove the runtime check and fallback handling. In preparation for that, make all the targets which don't need special handling in their cpu_exec_halt set it to their cpu_has_work implementation instead of leaving it unset. (This is every target except for arm and i386.) In the riscv case this requires us to make the function not be local to the source file it's defined in. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-04 18:57:10 +03:00
bool riscv_cpu_has_work(CPUState *cs)
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
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: Add M-mode virtual interrupt and IRQ filtering support. This change adds support for inserting virtual interrupts from M-mode into S-mode using mvien and mvip csrs. IRQ filtering is a use case of this change, i-e M-mode can stop delegating an interrupt to S-mode and instead enable it in MIE and receive those interrupts in M-mode and then selectively inject the interrupt using mvien and mvip. Also, the spec doesn't mandate the interrupt to be actually supported in hardware. Which allows M-mode to assert virtual interrupts to S-mode that have no connection to any real interrupt events. This is defined as part of the AIA specification [0], "5.3 Interrupt filtering and virtual interrupts for supervisor level". [0]: https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231016111736.28721-6-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-16 14:17:35 +03:00
return riscv_cpu_all_pending(env) != 0 ||
target/riscv: Add HS-mode virtual interrupt and IRQ filtering support. This change adds support for inserting virtual interrupts from HS-mode into VS-mode using hvien and hvip csrs. This also allows for IRQ filtering from HS-mode. Also, the spec doesn't mandate the interrupt to be actually supported in hardware. Which allows HS-mode to assert virtual interrupts to VS-mode that have no connection to any real interrupt events. This is defined as part of the AIA specification [0], "6.3.2 Virtual interrupts for VS level". [0]: https://github.com/riscv/riscv-aia/releases/download/1.0/riscv-interrupts-1.0.pdf Signed-off-by: Rajnesh Kanwal <rkanwal@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231016111736.28721-7-rkanwal@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-16 14:17:36 +03:00
riscv_cpu_sirq_pending(env) != RISCV_EXCP_NONE ||
riscv_cpu_vsirq_pending(env) != RISCV_EXCP_NONE;
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: Populate CPUClass.mmu_index Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-01-29 03:34:43 +03:00
static int riscv_cpu_mmu_index(CPUState *cs, bool ifetch)
{
return riscv_env_mmu_index(cpu_env(cs), ifetch);
}
hw, target: Add ResetType argument to hold and exit phase methods We pass a ResetType argument to the Resettable class enter phase method, but we don't pass it to hold and exit, even though the callsites have it readily available. This means that if a device cared about the ResetType it would need to record it in the enter phase method to use later on. Pass the type to all three of the phase methods to avoid having to do that. Commit created with for dir in hw target include; do \ spatch --macro-file scripts/cocci-macro-file.h \ --sp-file scripts/coccinelle/reset-type.cocci \ --keep-comments --smpl-spacing --in-place \ --include-headers --dir $dir; done and no manual edits. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@amd.com> Message-id: 20240412160809.1260625-5-peter.maydell@linaro.org
2024-04-12 19:08:07 +03:00
static void riscv_cpu_reset_hold(Object *obj, ResetType type)
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);
target: Replace CPU_GET_CLASS(cpu -> obj) in cpu_reset_hold() handler Since CPU() macro is a simple cast, the following are equivalent: Object *obj; CPUState *cs = CPU(obj) In order to ease static analysis when running scripts/coccinelle/cpu_env.cocci from the previous commit, replace: - CPU_GET_CLASS(cpu); + CPU_GET_CLASS(obj); Most code use the 'cs' variable name for CPUState handle. Replace few 's' -> 'cs' to unify cpu_reset_hold() style. No logical change in this patch. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240129164514.73104-7-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-29 19:44:48 +03:00
RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(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 = &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) {
hw, target: Add ResetType argument to hold and exit phase methods We pass a ResetType argument to the Resettable class enter phase method, but we don't pass it to hold and exit, even though the callsites have it readily available. This means that if a device cared about the ResetType it would need to record it in the enter phase method to use later on. Pass the type to all three of the phase methods to avoid having to do that. Commit created with for dir in hw target include; do \ spatch --macro-file scripts/cocci-macro-file.h \ --sp-file scripts/coccinelle/reset-type.cocci \ --keep-comments --smpl-spacing --in-place \ --include-headers --dir $dir; done and no manual edits. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Luc Michel <luc.michel@amd.com> Message-id: 20240412160809.1260625-5-peter.maydell@linaro.org
2024-04-12 19:08:07 +03:00
mcc->parent_phases.hold(obj, type);
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
}
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
env->misa_mxl = mcc->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: Gate hardware A/D PTE bit updating Gate hardware A/D PTE bit updating on {m,h}envcfg.ADUE and only enable menvcfg.ADUE on reset if svade has not been selected. Now that we also consider svade, we have four possible configurations: 1) !svade && !svadu use hardware updating and there's no way to disable it (the default, which maintains past behavior. Maintaining the default, even with !svadu is a change that fixes [1]) 2) !svade && svadu use hardware updating, but also provide {m,h}envcfg.ADUE, allowing software to switch to exception mode (being able to switch is a change which fixes [1]) 3) svade && !svadu use exception mode and there's no way to switch to hardware updating (this behavior change fixes [2]) 4) svade && svadu use exception mode, but also provide {m,h}envcfg.ADUE, allowing software to switch to hardware updating (this behavior change fixes [2]) Fixes: 0af3f115e68e ("target/riscv: Add *envcfg.HADE related check in address translation") [1] Fixes: 48531f5adb2a ("target/riscv: implement svade") [2] Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240215223955.969568-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:54 +03:00
(!cpu->cfg.ext_svade && cpu->cfg.ext_svadu ?
MENVCFG_ADUE : 0);
target/riscv: Reset henvcfg to zero The hypervisor should decide what it wants to enable. Zero all configuration enable bits on reset. Also, commit ed67d63798f2 ("target/riscv: Update CSR bits name for svadu extension") missed one reference to 'hade'. Change it now. Fixes: 0af3f115e68e ("target/riscv: Add *envcfg.HADE related check in address translation") Fixes: ed67d63798f2 ("target/riscv: Update CSR bits name for svadu extension") Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240215223955.969568-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:53 +03:00
env->henvcfg = 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);
target/riscv: pmp: Clear pmp/smepmp bits on reset As per the Priv and Smepmp specifications, certain bits such as the 'L' bit of pmp entries and mseccfg.MML can only be cleared upon reset and it is necessary to do so to allow 'M' mode firmware to correctly reinitialize the pmp/smpemp state across reboots. As required by the spec, also clear the 'A' field of pmp entries. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065644.1431798-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-19 09:56:44 +03:00
target/riscv: Ensure mideleg is set correctly on reset Bits 10, 6, 2 and 12 of mideleg are read only 1 when the Hypervisor is enabled. We currently only set them on accesses to mideleg, but they aren't correctly set on reset. Let's ensure they are always the correct value. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1617 Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240108001328.280222-4-alistair.francis@wdc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-08 03:13:28 +03:00
/*
* Bits 10, 6, 2 and 12 of mideleg are read only 1 when the Hypervisor
* extension is enabled.
*/
if (riscv_has_ext(env, RVH)) {
env->mideleg |= HS_MODE_INTERRUPTS;
}
target/riscv: pmp: Clear pmp/smepmp bits on reset As per the Priv and Smepmp specifications, certain bits such as the 'L' bit of pmp entries and mseccfg.MML can only be cleared upon reset and it is necessary to do so to allow 'M' mode firmware to correctly reinitialize the pmp/smpemp state across reboots. As required by the spec, also clear the 'A' field of pmp entries. Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065644.1431798-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-19 09:56:44 +03:00
/*
* Clear mseccfg and unlock all the PMP entries upon reset.
* This is allowed as per the priv and smepmp specifications
* and is needed to clear stale entries across reboots.
*/
if (riscv_cpu_cfg(env)->ext_smepmp) {
env->mseccfg = 0;
}
pmp_unlock_entries(env);
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
}
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)
{
target/riscv/cpu.c: add riscv_cpu_is_32bit() Next patch will need to retrieve if a given RISCVCPU is 32 or 64 bit. The existing helper riscv_is_32bit() (hw/riscv/boot.c) will always check the first CPU of a given hart array, not any given CPU. Create a helper to retrieve the info for any given CPU, not the first CPU of the hart array. The helper is using the same 32 bit check that riscv_cpu_satp_mode_finalize() was doing. 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: <20231218125334.37184-23-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:30 +03:00
bool rv32 = riscv_cpu_is_32bit(cpu);
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
target/riscv/tcg: add tcg_cpu_finalize_features() The query-cpu-model-expansion API is capable of passing extra properties to a given CPU model and tell callers if this custom configuration is valid. The RISC-V version of the API is not quite there yet. The reason is the realize() flow in the TCG driver, where most of the validation is done in tcg_cpu_realizefn(). riscv_cpu_finalize_features() is then used to validate satp_mode for both TCG and KVM CPUs. Our ARM friends uses a concept of 'finalize_features()', a step done in the end of realize() where the CPU features are validated. We have a riscv_cpu_finalize_features() helper that, at this moment, is only validating satp_mode. Re-use this existing helper to do all CPU extension validation we required after at the end of realize(). Make it public to allow APIs to use it. At this moment only the TCG driver requires a realize() time validation, thus, to avoid adding accelerator specific helpers in the API, riscv_cpu_finalize_features() uses riscv_tcg_cpu_finalize_features() if we are running TCG. The API will then use riscv_cpu_finalize_features() regardless of the current accelerator. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-18 22:56:35 +03:00
void riscv_cpu_finalize_features(RISCVCPU *cpu, Error **errp)
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 *local_err = NULL;
target/riscv/cpu.c: finalize satp_mode earlier Profiles will need to validate satp_mode during their own finalize methods. This will occur inside riscv_tcg_cpu_finalize_features() for TCG. Given that satp_mode does not have any pre-req from the accelerator finalize() method, it's safe to finalize it earlier. 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: <20231218125334.37184-22-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:29 +03:00
#ifndef CONFIG_USER_ONLY
riscv_cpu_satp_mode_finalize(cpu, &local_err);
if (local_err != NULL) {
error_propagate(errp, local_err);
return;
}
#endif
target/riscv/tcg: add tcg_cpu_finalize_features() The query-cpu-model-expansion API is capable of passing extra properties to a given CPU model and tell callers if this custom configuration is valid. The RISC-V version of the API is not quite there yet. The reason is the realize() flow in the TCG driver, where most of the validation is done in tcg_cpu_realizefn(). riscv_cpu_finalize_features() is then used to validate satp_mode for both TCG and KVM CPUs. Our ARM friends uses a concept of 'finalize_features()', a step done in the end of realize() where the CPU features are validated. We have a riscv_cpu_finalize_features() helper that, at this moment, is only validating satp_mode. Re-use this existing helper to do all CPU extension validation we required after at the end of realize(). Make it public to allow APIs to use it. At this moment only the TCG driver requires a realize() time validation, thus, to avoid adding accelerator specific helpers in the API, riscv_cpu_finalize_features() uses riscv_tcg_cpu_finalize_features() if we are running TCG. The API will then use riscv_cpu_finalize_features() regardless of the current accelerator. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-18 22:56:35 +03:00
if (tcg_enabled()) {
riscv_tcg_cpu_finalize_features(cpu, &local_err);
if (local_err != NULL) {
error_propagate(errp, local_err);
return;
}
target/riscv: Implement dynamic establishment of custom decoder In this patch, we modify the decoder to be a freely composable data structure instead of a hardcoded one. It can be dynamically builded up according to the extensions. This approach has several benefits: 1. Provides support for heterogeneous cpu architectures. As we add decoder in RISCVCPU, each cpu can have their own decoder, and the decoders can be different due to cpu's features. 2. Improve the decoding efficiency. We run the guard_func to see if the decoder can be added to the dynamic_decoder when building up the decoder. Therefore, there is no need to run the guard_func when decoding each instruction. It can improve the decoding efficiency 3. For vendor or dynamic cpus, it allows them to customize their own decoder functions to improve decoding efficiency, especially when vendor-defined instruction sets increase. Because of dynamic building up, it can skip the other decoder guard functions when decoding. 4. Pre patch for allowing adding a vendor decoder before decode_insn32() with minimal overhead for users that don't need this particular vendor decoder. Signed-off-by: Huang Tao <eric.huang@linux.alibaba.com> Suggested-by: Christoph Muellner <christoph.muellner@vrull.eu> Co-authored-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240506023607.29544-1-eric.huang@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-05-06 05:36:07 +03:00
riscv_tcg_cpu_finalize_dynamic_decoder(cpu);
target/riscv: create finalize_features() for KVM To turn cbom_blocksize and cboz_blocksize into class properties we need KVM specific changes. KVM is creating its own version of these options with a customized setter() that prevents users from picking an invalid value during init() time. This comes at the cost of duplicating each option that KVM supports. This will keep happening for each new shared option KVM implements in the future. We can avoid that by using the same property TCG uses and adding specific KVM handling during finalize() time, like TCG already does with riscv_tcg_cpu_finalize_features(). To do that, the common CPU property offers a way of knowing if an option was user set or not, sparing us from doing unneeded syscalls. riscv_kvm_cpu_finalize_features() is then created using the same KVMScratch CPU we already use during init() time, since finalize() time is still too early to use the official KVM CPU for it. cbom_blocksize and cboz_blocksize are then handled during finalize() in the same way they're handled by their KVM specific setter. With this change we can proceed with the blocksize changes in the common code without breaking the KVM driver. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:54 +03:00
} else if (kvm_enabled()) {
riscv_kvm_cpu_finalize_features(cpu, &local_err);
if (local_err != NULL) {
error_propagate(errp, local_err);
return;
}
target/riscv/tcg: add tcg_cpu_finalize_features() The query-cpu-model-expansion API is capable of passing extra properties to a given CPU model and tell callers if this custom configuration is valid. The RISC-V version of the API is not quite there yet. The reason is the realize() flow in the TCG driver, where most of the validation is done in tcg_cpu_realizefn(). riscv_cpu_finalize_features() is then used to validate satp_mode for both TCG and KVM CPUs. Our ARM friends uses a concept of 'finalize_features()', a step done in the end of realize() where the CPU features are validated. We have a riscv_cpu_finalize_features() helper that, at this moment, is only validating satp_mode. Re-use this existing helper to do all CPU extension validation we required after at the end of realize(). Make it public to allow APIs to use it. At this moment only the TCG driver requires a realize() time validation, thus, to avoid adding accelerator specific helpers in the API, riscv_cpu_finalize_features() uses riscv_tcg_cpu_finalize_features() if we are running TCG. The API will then use riscv_cpu_finalize_features() regardless of the current accelerator. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-18 22:56:35 +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
}
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;
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: add riscv_cpu_accelerator_compatible() Add an API to check if a given CPU is compatible with the current accelerator. This will allow query-cpu-model-expansion to work properly in conditions where QEMU supports both accelerators (TCG and KVM), QEMU is then launched using TCG, and the API requests information about a KVM only CPU (e.g. 'host' CPU). KVM doesn't have such restrictions and, at least in theory, all CPUs models should work with KVM. We will revisit this API in case we decide to restrict the amount of KVM CPUs we support. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231018195638.211151-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-18 22:56:37 +03:00
bool riscv_cpu_accelerator_compatible(RISCVCPU *cpu)
{
if (tcg_enabled()) {
return riscv_cpu_tcg_compatible(cpu);
}
return true;
}
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;
}
target/riscv: make riscv_add_satp_mode_properties() public This function is used for both accelerators. Make it public, and call it from kvm_riscv_cpu_add_kvm_properties(). This will make it easier to split KVM specific code for the KVM accelerator class in the next patch. 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-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:59 +03:00
void riscv_add_satp_mode_properties(Object *obj)
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
{
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 */
target/riscv/cpu.c: add .instance_post_init() All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU calls riscv_init_max_cpu_extensions(). Both can be moved to a common instance_post_init() callback, implemented in riscv_cpu_post_init(), called by all CPUs. The call order then becomes: riscv_cpu_init() -> cpu_init() of each CPU -> .instance_post_init() In the near future riscv_cpu_post_init() will call the init() function of the current accelerator, providing a hook for KVM and TCG accel classes to change the init() process of the CPU. 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: <20230925175709.35696-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:55 +03:00
static bool riscv_cpu_is_dynamic(Object *cpu_obj)
{
return object_dynamic_cast(cpu_obj, TYPE_RISCV_DYNAMIC_CPU) != NULL;
}
static void riscv_cpu_post_init(Object *obj)
{
target/riscv: introduce KVM AccelCPUClass Add a KVM accelerator class like we did with TCG. The difference is that, at least for now, we won't be using a realize() implementation for this accelerator. We'll start by assiging kvm_riscv_cpu_add_kvm_properties(), renamed to kvm_cpu_instance_init(), as a 'cpu_instance_init' implementation. Change riscv_cpu_post_init() to invoke accel_cpu_instance_init(), which will go through the 'cpu_instance_init' impl of the current acceleration (if available) and execute it. The end result is that the KVM initial setup, i.e. starting registers and adding its specific properties, will be done via this hook. Add a 'tcg_enabled()' condition in riscv_cpu_post_init() to avoid calling riscv_cpu_add_user_properties() when running KVM. We'll remove this condition when the TCG accel class get its own 'cpu_instance_init' implementation. 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-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:57:01 +03:00
accel_cpu_instance_init(CPU(obj));
target/riscv/cpu.c: add .instance_post_init() All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU calls riscv_init_max_cpu_extensions(). Both can be moved to a common instance_post_init() callback, implemented in riscv_cpu_post_init(), called by all CPUs. The call order then becomes: riscv_cpu_init() -> cpu_init() of each CPU -> .instance_post_init() In the near future riscv_cpu_post_init() will call the init() function of the current accelerator, providing a hook for KVM and TCG accel classes to change the init() process of the CPU. 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: <20230925175709.35696-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:55 +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 void riscv_cpu_init(Object *obj)
{
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(obj);
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
RISCVCPU *cpu = RISCV_CPU(obj);
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
CPURISCVState *env = &cpu->env;
env->misa_mxl = mcc->misa_mxl_max;
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
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: add zicntr extension flag for TCG zicntr is the Base Counters and Timers extension described in chapter 12 of the unprivileged spec. It describes support for RDCYCLE, RDTIME and RDINSTRET. QEMU already implements it in TCG way before it was a discrete extension. zicntr is part of the RVA22 profile, so let's add it to QEMU to make the future profile implementation flag complete. Given than it represents an already existing feature, default it to 'true' for all CPUs. For TCG, we need a way to disable zicntr if the user wants to. This is done by restricting access to the CYCLE, TIME, and INSTRET counters via the 'ctr()' predicate when we're about to access them. Disabling zicntr happens via the command line or if its dependency, zicsr, happens to be disabled. We'll check for zicsr during realize() and, in case it's absent, disable zicntr. However, if the user was explicit about having zicntr support, error out instead of disabling it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-23 18:39:24 +03:00
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
general_user_opts = g_hash_table_new(g_str_hash, g_str_equal);
target/riscv: add zicntr extension flag for TCG zicntr is the Base Counters and Timers extension described in chapter 12 of the unprivileged spec. It describes support for RDCYCLE, RDTIME and RDINSTRET. QEMU already implements it in TCG way before it was a discrete extension. zicntr is part of the RVA22 profile, so let's add it to QEMU to make the future profile implementation flag complete. Given than it represents an already existing feature, default it to 'true' for all CPUs. For TCG, we need a way to disable zicntr if the user wants to. This is done by restricting access to the CYCLE, TIME, and INSTRET counters via the 'ctr()' predicate when we're about to access them. Disabling zicntr happens via the command line or if its dependency, zicsr, happens to be disabled. We'll check for zicsr during realize() and, in case it's absent, disable zicntr. However, if the user was explicit about having zicntr support, error out instead of disabling it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-23 18:39:24 +03:00
/*
* The timer and performance counters extensions were supported
* in QEMU before they were added as discrete extensions in the
* ISA. To keep compatibility we'll always default them to 'true'
* for all CPUs. Each accelerator will decide what to do when
* users disable them.
*/
RISCV_CPU(obj)->cfg.ext_zicntr = true;
target/riscv: add zihpm extension flag for TCG zihpm is the Hardware Performance Counters extension described in chapter 12 of the unprivileged spec. It describes support for 29 unprivileged performance counters, hpmcounter3-hpmcounter31. As with zicntr, QEMU already implements zihpm before it was even an extension. zihpm is also part of the RVA22 profile, so add it to QEMU to complement the future profile implementation. Default it to 'true' for all existing CPUs since it was always present in the code. As for disabling it, there is already code in place in target/riscv/csr.c in all predicates for these counters (ctr() and mctr()) that disables them if cpu->cfg.pmu_num is zero. Thus, setting cpu->cfg.pmu_num to zero if 'zihpm=false' is enough to disable the extension. Set cpu->pmu_avail_ctrs mask to zero as well since this is also checked to verify if the counters exist. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-23 18:39:26 +03:00
RISCV_CPU(obj)->cfg.ext_zihpm = true;
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
/* Default values for non-bool cpu properties */
cpu->cfg.pmu_mask = MAKE_64BIT_MASK(3, 16);
target/riscv: add 'vlenb' field in cpu->cfg Our usage of 'vlenb' is overwhelming superior than the use of 'vlen'. We're using 'vlenb' most of the time, having to do 'vlen >> 3' or 'vlen / 8' in every instance. In hindsight we would be better if the 'vlenb' property was introduced instead of 'vlen'. That's not what happened, and now we can't easily get rid of it due to user scripts all around. What we can do, however, is to change our internal representation to use 'vlenb'. Add a 'vlenb' field in cpu->cfg. It'll be set via the existing 'vlen' property, i.e. setting 'vlen' will also set 'vlenb'. We'll replace all 'vlen >> 3' code to use 'vlenb' directly. Start with the single instance we have in target/riscv/cpu.c. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 19:10:55 +03:00
cpu->cfg.vlenb = 128 >> 3;
target/riscv: move 'elen' to riscv_cpu_properties[] Do the same thing we did with 'vlen' in the previous patch with 'elen'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:38 +03:00
cpu->cfg.elen = 64;
target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[] After adding a KVM finalize() implementation, turn cbom_blocksize into a class property. Follow the same design we used with 'vlen' and 'elen'. The duplicated 'cbom_blocksize' KVM property can be removed from kvm_riscv_add_cpu_user_properties(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:55 +03:00
cpu->cfg.cbom_blocksize = 64;
target/riscv: move 'cbop_blocksize' to riscv_cpu_properties[] Do the same we did with 'cbom_blocksize' in the previous patch. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:56 +03:00
cpu->cfg.cbop_blocksize = 64;
target/riscv: move 'cboz_blocksize' to riscv_cpu_properties[] And remove the now unused kvm_cpu_set_cbomz_blksize() setter. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:57 +03:00
cpu->cfg.cboz_blocksize = 64;
target/riscv: rework 'vext_spec' The same rework did in 'priv_spec' is done for 'vext_spec'. This time is simpler, since we only accept one value ("v1.0") and we'll always have env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to convert string to 'vext_ver' back and forth like we needed for 'priv_spec'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:36 +03:00
cpu->env.vext_ver = VEXT_VERSION_1_00_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
}
target/riscv/cpu.c: add riscv_bare_cpu_init() Next patch will add more bare CPUs. Their cpu_init() functions would be glorified copy/pastes of rv64i_bare_cpu_init(), differing only by a riscv_cpu_set_misa() call. Add a new .instance_init for the TYPE_RISCV_BARE_CPU typ to avoid this code repetition. While we're at it, add a better explanation on why we're disabling the timing extensions for bare CPUs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122123348.973288-2-dbarboza@ventanamicro.com> [ Changes by AF: - Rebase on latest changes ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 15:33:47 +03:00
static void riscv_bare_cpu_init(Object *obj)
{
RISCVCPU *cpu = RISCV_CPU(obj);
/*
* Bare CPUs do not inherit the timer and performance
* counters from the parent class (see riscv_cpu_init()
* for info on why the parent enables them).
*
* Users have to explicitly enable these counters for
* bare CPUs.
*/
cpu->cfg.ext_zicntr = false;
cpu->cfg.ext_zihpm = false;
/* Set to QEMU's first supported priv version */
cpu->env.priv_ver = PRIV_VERSION_1_10_0;
/*
* Support all available satp_mode settings. The default
* value will be set to MBARE if the user doesn't set
* satp_mode manually (see set_satp_mode_default()).
*/
#ifndef CONFIG_USER_ONLY
set_satp_mode_max_supported(cpu, VM_1_10_SV64);
#endif
}
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)"),
target/riscv: Remove experimental prefix from "B" extension This extension has now been ratified: https://jira.riscv.org/browse/RVS-2006 so the "x-" prefix can be removed. Since this is now a ratified extension add it to the list of extensions included in the "max" CPU variant. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20240514110217.22516-1-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-05-14 14:02:17 +03:00
MISA_EXT_INFO(RVB, "b", "Bit manipulation (Zba_Zbb_Zbs)")
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
};
target/riscv: Validate misa_mxl_max only once misa_mxl_max is now a class member and initialized only once for each class. This also moves the initialization of gdb_core_xml_file which will be referenced before realization in the future. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-3-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:10 +03:00
static void riscv_cpu_validate_misa_mxl(RISCVCPUClass *mcc)
{
CPUClass *cc = CPU_CLASS(mcc);
/* Validate that MISA_MXL is set properly. */
switch (mcc->misa_mxl_max) {
#ifdef TARGET_RISCV64
case MXL_RV64:
case MXL_RV128:
cc->gdb_core_xml_file = "riscv-64bit-cpu.xml";
break;
#endif
case MXL_RV32:
cc->gdb_core_xml_file = "riscv-32bit-cpu.xml";
break;
default:
g_assert_not_reached();
}
}
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
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;
}
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
#define MULTI_EXT_CFG_BOOL(_name, _prop, _defval) \
{.name = _name, .offset = CPU_CFG_OFFSET(_prop), \
.enabled = _defval}
target/riscv: move riscv_cpu_add_kvm_properties() to kvm.c We'll introduce the KVM accelerator class with a 'cpu_instance_init' implementation that is going to be invoked during the common riscv_cpu_post_init() (via accel_cpu_instance_init()). This instance_init will execute KVM exclusive code that TCG doesn't care about, such as adding KVM specific properties, initing registers using a KVM scratch CPU and so on. The core of the forementioned cpu_instance_init impl is the current riscv_cpu_add_kvm_properties() that is being used by the common code via riscv_cpu_add_user_properties() in cpu.c. Move it to kvm.c, together will all the relevant artifacts, exporting and renaming it to kvm_riscv_cpu_add_kvm_properties() so cpu.c can keep using it for now. To make this work we'll need to export riscv_cpu_extensions, riscv_cpu_vendor_exts and riscv_cpu_experimental_exts from cpu.c as well. The TCG accelerator will also need to access those in the near future so this export will benefit us in the long run. 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-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:58 +03:00
const 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),
target/riscv: Expose the Smcntrpmf config Create a new config for Smcntrpmf extension so that it can be enabled/ disabled from the qemu commandline. Signed-off-by: Atish Patra <atishp@rivosinc.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240711-smcntrpmf_v7-v8-13-b7c38ae7b263@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-12 01:31:16 +03:00
MULTI_EXT_CFG_BOOL("smcntrpmf", ext_smcntrpmf, false),
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
MULTI_EXT_CFG_BOOL("zifencei", ext_zifencei, true),
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
MULTI_EXT_CFG_BOOL("zicsr", ext_zicsr, true),
target/riscv: deprecate capital 'Z' CPU properties At this moment there are eleven CPU extension properties that starts with capital 'Z': Zifencei, Zicsr, Zihintntl, Zihintpause, Zawrs, Zfa, Zfh, Zfhmin, Zve32f, Zve64f and Zve64d. All other extensions are named with lower-case letters. We want all properties to be named with lower-case letters since it's consistent with the riscv-isa string that we create in the FDT. Having these 11 properties to be exceptions can be confusing. Deprecate all of them. Create their lower-case counterpart to be used as maintained CPU properties. When trying to use any deprecated property a warning message will be displayed, recommending users to switch to the lower-case variant: ./build/qemu-system-riscv64 -M virt -cpu rv64,Zifencei=true --nographic qemu-system-riscv64: warning: CPU property 'Zifencei' is deprecated. Please use 'zifencei' instead This will give users some time to change their scripts before we remove the capital 'Z' properties entirely. 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: <20231009112817.8896-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-09 14:28:17 +03:00
MULTI_EXT_CFG_BOOL("zihintntl", ext_zihintntl, true),
MULTI_EXT_CFG_BOOL("zihintpause", ext_zihintpause, true),
target/riscv: Add zimop extension Zimop extension defines an encoding space for 40 MOPs.The Zimop extension defines 32 MOP instructions named MOP.R.n, where n is an integer between 0 and 31, inclusive. The Zimop extension additionally defines 8 MOP instructions named MOP.RR.n, where n is an integer between 0 and 7. These 40 MOPs initially are defined to simply write zero to x[rd], but are designed to be redefined by later extensions to perform some other action. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Deepak Gupta <debug@rivosinc.com> Message-ID: <20240709113652.1239-2-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-09 14:36:42 +03:00
MULTI_EXT_CFG_BOOL("zimop", ext_zimop, false),
target/riscv: Add zcmop extension Zcmop defines eight 16-bit MOP instructions named C.MOP.n, where n is an odd integer between 1 and 15, inclusive. C.MOP.n is encoded in the reserved encoding space corresponding to C.LUI xn, 0. Unlike the MOPs defined in the Zimop extension, the C.MOP.n instructions are defined to not write any register. In current implementation, C.MOP.n only has an check function, without any other more behavior. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Deepak Gupta <debug@rivosinc.com> Message-ID: <20240709113652.1239-4-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-09 14:36:44 +03:00
MULTI_EXT_CFG_BOOL("zcmop", ext_zcmop, false),
target/riscv: Add support for Zacas extension Add support for amocas.w/d/q instructions which are part of the ratified Zacas extension: https://github.com/riscv/riscv-zacas Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231207153842.32401-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-07 18:32:30 +03:00
MULTI_EXT_CFG_BOOL("zacas", ext_zacas, false),
target/riscv: Support Zama16b extension Zama16b is the property that misaligned load/stores/atomics within a naturally aligned 16-byte region are atomic. According to the specification, Zama16b applies only to AMOs, loads and stores defined in the base ISAs, and loads and stores of no more than XLEN bits defined in the F, D, and Q extensions. Thus it should not apply to zacas or RVC instructions. For an instruction in that set, if all accessed bytes lie within 16B granule, the instruction will not raise an exception for reasons of address alignment, and the instruction will give rise to only one memory operation for the purposes of RVWMO—i.e., it will execute atomically. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240709113652.1239-6-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-09 14:36:46 +03:00
MULTI_EXT_CFG_BOOL("zama16b", ext_zama16b, false),
target/riscv: Expose zabha extension as a cpu property Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240709113652.1239-11-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-07-09 14:36:51 +03:00
MULTI_EXT_CFG_BOOL("zabha", ext_zabha, false),
target/riscv: move ratified/frozen exts to non-experimental smaia and ssaia were ratified in August 25th 2023 [1]. zvfh and zvfhmin were ratified in August 2nd 2023 [2]. zfbfmin and zvfbf(min|wma) are frozen and moved to public review since Dec 16th 2023 [3]. zaamo and zalrsc are both marked as "Frozen" since January 24th 2024 [4]. [1] https://jira.riscv.org/browse/RVS-438 [2] https://jira.riscv.org/browse/RVS-871 [3] https://jira.riscv.org/browse/RVS-704 [4] https://jira.riscv.org/browse/RVS-1995 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240301144053.265964-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-01 17:40:53 +03:00
MULTI_EXT_CFG_BOOL("zaamo", ext_zaamo, false),
MULTI_EXT_CFG_BOOL("zalrsc", ext_zalrsc, false),
target/riscv: deprecate capital 'Z' CPU properties At this moment there are eleven CPU extension properties that starts with capital 'Z': Zifencei, Zicsr, Zihintntl, Zihintpause, Zawrs, Zfa, Zfh, Zfhmin, Zve32f, Zve64f and Zve64d. All other extensions are named with lower-case letters. We want all properties to be named with lower-case letters since it's consistent with the riscv-isa string that we create in the FDT. Having these 11 properties to be exceptions can be confusing. Deprecate all of them. Create their lower-case counterpart to be used as maintained CPU properties. When trying to use any deprecated property a warning message will be displayed, recommending users to switch to the lower-case variant: ./build/qemu-system-riscv64 -M virt -cpu rv64,Zifencei=true --nographic qemu-system-riscv64: warning: CPU property 'Zifencei' is deprecated. Please use 'zifencei' instead This will give users some time to change their scripts before we remove the capital 'Z' properties entirely. 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: <20231009112817.8896-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-09 14:28:17 +03:00
MULTI_EXT_CFG_BOOL("zawrs", ext_zawrs, true),
MULTI_EXT_CFG_BOOL("zfa", ext_zfa, true),
target/riscv: move ratified/frozen exts to non-experimental smaia and ssaia were ratified in August 25th 2023 [1]. zvfh and zvfhmin were ratified in August 2nd 2023 [2]. zfbfmin and zvfbf(min|wma) are frozen and moved to public review since Dec 16th 2023 [3]. zaamo and zalrsc are both marked as "Frozen" since January 24th 2024 [4]. [1] https://jira.riscv.org/browse/RVS-438 [2] https://jira.riscv.org/browse/RVS-871 [3] https://jira.riscv.org/browse/RVS-704 [4] https://jira.riscv.org/browse/RVS-1995 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240301144053.265964-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-01 17:40:53 +03:00
MULTI_EXT_CFG_BOOL("zfbfmin", ext_zfbfmin, false),
target/riscv: deprecate capital 'Z' CPU properties At this moment there are eleven CPU extension properties that starts with capital 'Z': Zifencei, Zicsr, Zihintntl, Zihintpause, Zawrs, Zfa, Zfh, Zfhmin, Zve32f, Zve64f and Zve64d. All other extensions are named with lower-case letters. We want all properties to be named with lower-case letters since it's consistent with the riscv-isa string that we create in the FDT. Having these 11 properties to be exceptions can be confusing. Deprecate all of them. Create their lower-case counterpart to be used as maintained CPU properties. When trying to use any deprecated property a warning message will be displayed, recommending users to switch to the lower-case variant: ./build/qemu-system-riscv64 -M virt -cpu rv64,Zifencei=true --nographic qemu-system-riscv64: warning: CPU property 'Zifencei' is deprecated. Please use 'zifencei' instead This will give users some time to change their scripts before we remove the capital 'Z' properties entirely. 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: <20231009112817.8896-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-09 14:28:17 +03:00
MULTI_EXT_CFG_BOOL("zfh", ext_zfh, false),
MULTI_EXT_CFG_BOOL("zfhmin", ext_zfhmin, false),
MULTI_EXT_CFG_BOOL("zve32f", ext_zve32f, false),
target/riscv: Add support for Zve32x extension Add support for Zve32x extension and replace some checks for Zve32f with Zve32x, since Zve32f depends on Zve32x. Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240328022343.6871-2-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-28 05:23:10 +03:00
MULTI_EXT_CFG_BOOL("zve32x", ext_zve32x, false),
target/riscv: deprecate capital 'Z' CPU properties At this moment there are eleven CPU extension properties that starts with capital 'Z': Zifencei, Zicsr, Zihintntl, Zihintpause, Zawrs, Zfa, Zfh, Zfhmin, Zve32f, Zve64f and Zve64d. All other extensions are named with lower-case letters. We want all properties to be named with lower-case letters since it's consistent with the riscv-isa string that we create in the FDT. Having these 11 properties to be exceptions can be confusing. Deprecate all of them. Create their lower-case counterpart to be used as maintained CPU properties. When trying to use any deprecated property a warning message will be displayed, recommending users to switch to the lower-case variant: ./build/qemu-system-riscv64 -M virt -cpu rv64,Zifencei=true --nographic qemu-system-riscv64: warning: CPU property 'Zifencei' is deprecated. Please use 'zifencei' instead This will give users some time to change their scripts before we remove the capital 'Z' properties entirely. 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: <20231009112817.8896-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-09 14:28:17 +03:00
MULTI_EXT_CFG_BOOL("zve64f", ext_zve64f, false),
MULTI_EXT_CFG_BOOL("zve64d", ext_zve64d, false),
target/riscv: Add support for Zve64x extension Add support for Zve64x extension. Enabling Zve64f enables Zve64x and enabling Zve64x enables Zve32x according to their dependency. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2107 Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240328022343.6871-3-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-28 05:23:11 +03:00
MULTI_EXT_CFG_BOOL("zve64x", ext_zve64x, false),
target/riscv: move ratified/frozen exts to non-experimental smaia and ssaia were ratified in August 25th 2023 [1]. zvfh and zvfhmin were ratified in August 2nd 2023 [2]. zfbfmin and zvfbf(min|wma) are frozen and moved to public review since Dec 16th 2023 [3]. zaamo and zalrsc are both marked as "Frozen" since January 24th 2024 [4]. [1] https://jira.riscv.org/browse/RVS-438 [2] https://jira.riscv.org/browse/RVS-871 [3] https://jira.riscv.org/browse/RVS-704 [4] https://jira.riscv.org/browse/RVS-1995 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240301144053.265964-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-01 17:40:53 +03:00
MULTI_EXT_CFG_BOOL("zvfbfmin", ext_zvfbfmin, false),
MULTI_EXT_CFG_BOOL("zvfbfwma", ext_zvfbfwma, false),
MULTI_EXT_CFG_BOOL("zvfh", ext_zvfh, false),
MULTI_EXT_CFG_BOOL("zvfhmin", ext_zvfhmin, false),
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("sstc", ext_sstc, true),
target/riscv: move ratified/frozen exts to non-experimental smaia and ssaia were ratified in August 25th 2023 [1]. zvfh and zvfhmin were ratified in August 2nd 2023 [2]. zfbfmin and zvfbf(min|wma) are frozen and moved to public review since Dec 16th 2023 [3]. zaamo and zalrsc are both marked as "Frozen" since January 24th 2024 [4]. [1] https://jira.riscv.org/browse/RVS-438 [2] https://jira.riscv.org/browse/RVS-871 [3] https://jira.riscv.org/browse/RVS-704 [4] https://jira.riscv.org/browse/RVS-1995 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240301144053.265964-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-01 17:40:53 +03:00
MULTI_EXT_CFG_BOOL("smaia", ext_smaia, false),
Add epmp to extensions list and rename it to smepmp Smepmp is a ratified extension which qemu refers to as epmp. Rename epmp to smepmp and add it to extension list so that it is added to the isa string. Signed-off-by: Himanshu Chauhan <hchauhan@ventanamicro.com> Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231019065546.1431579-1-mchitale@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-19 09:55:46 +03:00
MULTI_EXT_CFG_BOOL("smepmp", ext_smepmp, false),
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("smstateen", ext_smstateen, false),
target/riscv: move ratified/frozen exts to non-experimental smaia and ssaia were ratified in August 25th 2023 [1]. zvfh and zvfhmin were ratified in August 2nd 2023 [2]. zfbfmin and zvfbf(min|wma) are frozen and moved to public review since Dec 16th 2023 [3]. zaamo and zalrsc are both marked as "Frozen" since January 24th 2024 [4]. [1] https://jira.riscv.org/browse/RVS-438 [2] https://jira.riscv.org/browse/RVS-871 [3] https://jira.riscv.org/browse/RVS-704 [4] https://jira.riscv.org/browse/RVS-1995 Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240301144053.265964-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-01 17:40:53 +03:00
MULTI_EXT_CFG_BOOL("ssaia", ext_ssaia, false),
target/riscv: Promote svade to a normal extension Named features are extensions which don't make sense for users to control and are therefore not exposed on the command line. However, svade is an extension which makes sense for users to control, so treat it like a "normal" extension. The default is false, even for the max cpu type, since QEMU has always implemented hardware A/D PTE bit updating, so users must opt into svade (or get it from a CPU type which enables it by default). Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240215223955.969568-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:55 +03:00
MULTI_EXT_CFG_BOOL("svade", ext_svade, false),
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("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),
target/riscv: add zicntr extension flag for TCG zicntr is the Base Counters and Timers extension described in chapter 12 of the unprivileged spec. It describes support for RDCYCLE, RDTIME and RDINSTRET. QEMU already implements it in TCG way before it was a discrete extension. zicntr is part of the RVA22 profile, so let's add it to QEMU to make the future profile implementation flag complete. Given than it represents an already existing feature, default it to 'true' for all CPUs. For TCG, we need a way to disable zicntr if the user wants to. This is done by restricting access to the CYCLE, TIME, and INSTRET counters via the 'ctr()' predicate when we're about to access them. Disabling zicntr happens via the command line or if its dependency, zicsr, happens to be disabled. We'll check for zicsr during realize() and, in case it's absent, disable zicntr. However, if the user was explicit about having zicntr support, error out instead of disabling it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-23 18:39:24 +03:00
MULTI_EXT_CFG_BOOL("zicntr", ext_zicntr, true),
target/riscv: add zihpm extension flag for TCG zihpm is the Hardware Performance Counters extension described in chapter 12 of the unprivileged spec. It describes support for 29 unprivileged performance counters, hpmcounter3-hpmcounter31. As with zicntr, QEMU already implements zihpm before it was even an extension. zihpm is also part of the RVA22 profile, so add it to QEMU to complement the future profile implementation. Default it to 'true' for all existing CPUs since it was always present in the code. As for disabling it, there is already code in place in target/riscv/csr.c in all predicates for these counters (ctr() and mctr()) that disables them if cpu->cfg.pmu_num is zero. Thus, setting cpu->cfg.pmu_num to zero if 'zihpm=false' is enough to disable the extension. Set cpu->pmu_avail_ctrs mask to zero as well since this is also checked to verify if the counters exist. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-23 18:39:26 +03:00
MULTI_EXT_CFG_BOOL("zihpm", ext_zihpm, true),
target/riscv: add zicntr extension flag for TCG zicntr is the Base Counters and Timers extension described in chapter 12 of the unprivileged spec. It describes support for RDCYCLE, RDTIME and RDINSTRET. QEMU already implements it in TCG way before it was a discrete extension. zicntr is part of the RVA22 profile, so let's add it to QEMU to make the future profile implementation flag complete. Given than it represents an already existing feature, default it to 'true' for all CPUs. For TCG, we need a way to disable zicntr if the user wants to. This is done by restricting access to the CYCLE, TIME, and INSTRET counters via the 'ctr()' predicate when we're about to access them. Disabling zicntr happens via the command line or if its dependency, zicsr, happens to be disabled. We'll check for zicsr during realize() and, in case it's absent, disable zicntr. However, if the user was explicit about having zicntr support, error out instead of disabling it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231023153927.435083-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-23 18:39:24 +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("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),
RISC-V: Add support for Ztso The Ztso extension is already ratified, this adds it as a CPU property and adds various fences throughout the port in order to allow TSO targets to function on weaker hosts. We need no fences for AMOs as they're already SC, the places we need barriers are described. These fences are placed in the RISC-V backend rather than TCG as is planned for x86-on-arm64 because RISC-V allows heterogeneous (and likely soon dynamic) hart memory models. Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-ID: <20240207122256.902627-2-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-07 15:22:54 +03:00
MULTI_EXT_CFG_BOOL("ztso", ext_ztso, false),
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("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),
target/riscv: rename ext_icbom to ext_zicbom Add a leading 'z' to improve grepping. When one wants to search for uses of zicbom they're more likely to do 'grep -i zicbom' than 'grep -i icbom'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:03 +03:00
MULTI_EXT_CFG_BOOL("zicbom", ext_zicbom, true),
target/riscv: add zicbop extension flag QEMU already implements zicbom (Cache Block Management Operations) and zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv: add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for what would be the instructions for zicbop (Cache Block Prefetch Operations), which are now no-ops. The RVA22U64 profile mandates zicbop, which means that applications that run with this profile might expect zicbop to be present in the riscv,isa DT and might behave badly if it's absent. Adding zicbop as an extension will make our future RVA22U64 implementation more in line with what userspace expects and, if/when cache block prefetch operations became relevant to QEMU, we already have the extension flag to turn then on/off as needed. 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: <20231218125334.37184-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:13 +03:00
MULTI_EXT_CFG_BOOL("zicbop", ext_zicbop, true),
target/riscv: rename ext_icboz to ext_zicboz Add a leading 'z' to improve grepping. When one wants to search for uses of zicboz they're more likely to do 'grep -i zicboz' than 'grep -i icboz'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:04 +03:00
MULTI_EXT_CFG_BOOL("zicboz", ext_zicboz, true),
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("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: Move vector crypto extensions to riscv_cpu_extensions Because the vector crypto specification is ratified, so move theses extensions from riscv_cpu_experimental_exts to riscv_cpu_extensions. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-11-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-26 18:18:17 +03:00
/* Vector cryptography extensions */
MULTI_EXT_CFG_BOOL("zvbb", ext_zvbb, false),
MULTI_EXT_CFG_BOOL("zvbc", ext_zvbc, false),
target/riscv/cpu.c: fix Zvkb extension config This code has a typo that writes zvkb to zvkg, causing users can't enable zvkb through the config. This patch gets this fixed. Signed-off-by: Yangyu Chen <cyy@cyyself.name> Fixes: ea61ef7097d0 ("target/riscv: Move vector crypto extensions to riscv_cpu_extensions") Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Max Chou <max.chou@sifive.com> Reviewed-by:  Weiwei Li <liwei1518@gmail.com> Message-ID: <tencent_7E34EEF0F90B9A68BF38BEE09EC6D4877C0A@qq.com> Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-05-11 14:26:48 +03:00
MULTI_EXT_CFG_BOOL("zvkb", ext_zvkb, false),
target/riscv: Move vector crypto extensions to riscv_cpu_extensions Because the vector crypto specification is ratified, so move theses extensions from riscv_cpu_experimental_exts to riscv_cpu_extensions. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231026151828.754279-11-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-26 18:18:17 +03:00
MULTI_EXT_CFG_BOOL("zvkg", ext_zvkg, false),
MULTI_EXT_CFG_BOOL("zvkned", ext_zvkned, false),
MULTI_EXT_CFG_BOOL("zvknha", ext_zvknha, false),
MULTI_EXT_CFG_BOOL("zvknhb", ext_zvknhb, false),
MULTI_EXT_CFG_BOOL("zvksed", ext_zvksed, false),
MULTI_EXT_CFG_BOOL("zvksh", ext_zvksh, false),
MULTI_EXT_CFG_BOOL("zvkt", ext_zvkt, false),
MULTI_EXT_CFG_BOOL("zvkn", ext_zvkn, false),
MULTI_EXT_CFG_BOOL("zvknc", ext_zvknc, false),
MULTI_EXT_CFG_BOOL("zvkng", ext_zvkng, false),
MULTI_EXT_CFG_BOOL("zvks", ext_zvks, false),
MULTI_EXT_CFG_BOOL("zvksc", ext_zvksc, false),
MULTI_EXT_CFG_BOOL("zvksg", ext_zvksg, false),
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: move riscv_cpu_add_kvm_properties() to kvm.c We'll introduce the KVM accelerator class with a 'cpu_instance_init' implementation that is going to be invoked during the common riscv_cpu_post_init() (via accel_cpu_instance_init()). This instance_init will execute KVM exclusive code that TCG doesn't care about, such as adding KVM specific properties, initing registers using a KVM scratch CPU and so on. The core of the forementioned cpu_instance_init impl is the current riscv_cpu_add_kvm_properties() that is being used by the common code via riscv_cpu_add_user_properties() in cpu.c. Move it to kvm.c, together will all the relevant artifacts, exporting and renaming it to kvm_riscv_cpu_add_kvm_properties() so cpu.c can keep using it for now. To make this work we'll need to export riscv_cpu_extensions, riscv_cpu_vendor_exts and riscv_cpu_experimental_exts from cpu.c as well. The TCG accelerator will also need to access those in the near future so this export will benefit us in the long run. 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-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:58 +03:00
const RISCVCPUMultiExtConfig riscv_cpu_vendor_exts[] = {
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("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: move riscv_cpu_add_kvm_properties() to kvm.c We'll introduce the KVM accelerator class with a 'cpu_instance_init' implementation that is going to be invoked during the common riscv_cpu_post_init() (via accel_cpu_instance_init()). This instance_init will execute KVM exclusive code that TCG doesn't care about, such as adding KVM specific properties, initing registers using a KVM scratch CPU and so on. The core of the forementioned cpu_instance_init impl is the current riscv_cpu_add_kvm_properties() that is being used by the common code via riscv_cpu_add_user_properties() in cpu.c. Move it to kvm.c, together will all the relevant artifacts, exporting and renaming it to kvm_riscv_cpu_add_kvm_properties() so cpu.c can keep using it for now. To make this work we'll need to export riscv_cpu_extensions, riscv_cpu_vendor_exts and riscv_cpu_experimental_exts from cpu.c as well. The TCG accelerator will also need to access those in the near future so this export will benefit us in the long run. 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-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:58 +03:00
const RISCVCPUMultiExtConfig riscv_cpu_experimental_exts[] = {
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: add riscv,isa to named features Further discussions after the introduction of rva22 support in QEMU revealed that what we've been calling 'named features' are actually regular extensions, with their respective riscv,isa DTs. This is clarified in [1]. [2] is a bug tracker asking for the profile spec to be less cryptic about it. As far as QEMU goes we understand extensions as something that the user can enable/disable in the command line. This isn't the case for named features, so we'll have to reach a middle ground. We'll keep our existing nomenclature 'named features' to refer to any extension that the user can't control in the command line. We'll also do the following: - 'svade' and 'zic64b' flags are renamed to 'ext_svade' and 'ext_zic64b'. 'ext_svade' and 'ext_zic64b' now have riscv,isa strings and priv_spec versions; - skip name feature check in cpu_bump_multi_ext_priv_ver(). Now that named features have a riscv,isa and an entry in isa_edata_arr[] we don't need to gate the call to cpu_cfg_ext_get_min_version() anymore. [1] https://github.com/riscv/riscv-profiles/issues/121 [2] https://github.com/riscv/riscv-profiles/issues/142 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: <20240215223955.969568-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:51 +03:00
/*
* 'Named features' is the name we give to extensions that we
* don't want to expose to users. They are either immutable
* (always enabled/disable) or they'll vary depending on
* the resulting CPU state. They have riscv,isa strings
* and priv_ver like regular extensions.
*/
target/riscv/tcg: add 'zic64b' support zic64b is defined in the RVA22U64 profile [1] as a named feature for "Cache blocks must be 64 bytes in size, naturally aligned in the address space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64 profile mandates this feature, meaning that applications using this profile expects 64 bytes cache blocks. To make the upcoming RVA22U64 implementation complete, we'll zic64b as a 'named feature', not a regular extension. This means that: - it won't be exposed to users; - it won't be written in riscv,isa. This will be extended to other named extensions in the future, so we're creating some common boilerplate for them as well. zic64b is default to 'true' since we're already using 64 bytes blocks. If any cache block size (cbo{m,p,z}_blocksize) is changed to something different than 64, zic64b is set to 'false'. Our profile implementation will then be able to check the current state of zic64b and take the appropriate action (e.g. throw a warning). [1] https://github.com/riscv/riscv-profiles/releases/download/v1.0/profiles.pdf 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: <20231218125334.37184-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:14 +03:00
const RISCVCPUMultiExtConfig riscv_cpu_named_features[] = {
target/riscv: add riscv,isa to named features Further discussions after the introduction of rva22 support in QEMU revealed that what we've been calling 'named features' are actually regular extensions, with their respective riscv,isa DTs. This is clarified in [1]. [2] is a bug tracker asking for the profile spec to be less cryptic about it. As far as QEMU goes we understand extensions as something that the user can enable/disable in the command line. This isn't the case for named features, so we'll have to reach a middle ground. We'll keep our existing nomenclature 'named features' to refer to any extension that the user can't control in the command line. We'll also do the following: - 'svade' and 'zic64b' flags are renamed to 'ext_svade' and 'ext_zic64b'. 'ext_svade' and 'ext_zic64b' now have riscv,isa strings and priv_spec versions; - skip name feature check in cpu_bump_multi_ext_priv_ver(). Now that named features have a riscv,isa and an entry in isa_edata_arr[] we don't need to gate the call to cpu_cfg_ext_get_min_version() anymore. [1] https://github.com/riscv/riscv-profiles/issues/121 [2] https://github.com/riscv/riscv-profiles/issues/142 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: <20240215223955.969568-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:51 +03:00
MULTI_EXT_CFG_BOOL("zic64b", ext_zic64b, true),
target/riscv/tcg: add 'zic64b' support zic64b is defined in the RVA22U64 profile [1] as a named feature for "Cache blocks must be 64 bytes in size, naturally aligned in the address space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64 profile mandates this feature, meaning that applications using this profile expects 64 bytes cache blocks. To make the upcoming RVA22U64 implementation complete, we'll zic64b as a 'named feature', not a regular extension. This means that: - it won't be exposed to users; - it won't be written in riscv,isa. This will be extended to other named extensions in the future, so we're creating some common boilerplate for them as well. zic64b is default to 'true' since we're already using 64 bytes blocks. If any cache block size (cbo{m,p,z}_blocksize) is changed to something different than 64, zic64b is set to 'false'. Our profile implementation will then be able to check the current state of zic64b and take the appropriate action (e.g. throw a warning). [1] https://github.com/riscv/riscv-profiles/releases/download/v1.0/profiles.pdf 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: <20231218125334.37184-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:14 +03:00
DEFINE_PROP_END_OF_LIST(),
};
target/riscv: deprecate capital 'Z' CPU properties At this moment there are eleven CPU extension properties that starts with capital 'Z': Zifencei, Zicsr, Zihintntl, Zihintpause, Zawrs, Zfa, Zfh, Zfhmin, Zve32f, Zve64f and Zve64d. All other extensions are named with lower-case letters. We want all properties to be named with lower-case letters since it's consistent with the riscv-isa string that we create in the FDT. Having these 11 properties to be exceptions can be confusing. Deprecate all of them. Create their lower-case counterpart to be used as maintained CPU properties. When trying to use any deprecated property a warning message will be displayed, recommending users to switch to the lower-case variant: ./build/qemu-system-riscv64 -M virt -cpu rv64,Zifencei=true --nographic qemu-system-riscv64: warning: CPU property 'Zifencei' is deprecated. Please use 'zifencei' instead This will give users some time to change their scripts before we remove the capital 'Z' properties entirely. 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: <20231009112817.8896-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-09 14:28:17 +03:00
/* Deprecated entries marked for future removal */
const RISCVCPUMultiExtConfig riscv_cpu_deprecated_exts[] = {
target/riscv: rename ext_ifencei to ext_zifencei Add a leading 'z' to improve grepping. When one wants to search for uses of zifencei they're more likely to do 'grep -i zifencei' than 'grep -i ifencei'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:01 +03:00
MULTI_EXT_CFG_BOOL("Zifencei", ext_zifencei, true),
target/riscv: rename ext_icsr to ext_zicsr Add a leading 'z' to improve grepping. When one wants to search for uses of zicsr they're more likely to do 'grep -i zicsr' than 'grep -i icsr'. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231012164604.398496-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12 19:46:02 +03:00
MULTI_EXT_CFG_BOOL("Zicsr", ext_zicsr, true),
target/riscv: deprecate capital 'Z' CPU properties At this moment there are eleven CPU extension properties that starts with capital 'Z': Zifencei, Zicsr, Zihintntl, Zihintpause, Zawrs, Zfa, Zfh, Zfhmin, Zve32f, Zve64f and Zve64d. All other extensions are named with lower-case letters. We want all properties to be named with lower-case letters since it's consistent with the riscv-isa string that we create in the FDT. Having these 11 properties to be exceptions can be confusing. Deprecate all of them. Create their lower-case counterpart to be used as maintained CPU properties. When trying to use any deprecated property a warning message will be displayed, recommending users to switch to the lower-case variant: ./build/qemu-system-riscv64 -M virt -cpu rv64,Zifencei=true --nographic qemu-system-riscv64: warning: CPU property 'Zifencei' is deprecated. Please use 'zifencei' instead This will give users some time to change their scripts before we remove the capital 'Z' properties entirely. 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: <20231009112817.8896-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-09 14:28:17 +03:00
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),
DEFINE_PROP_END_OF_LIST(),
};
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
static void cpu_set_prop_err(RISCVCPU *cpu, const char *propname,
Error **errp)
{
g_autofree char *cpuname = riscv_cpu_get_name(cpu);
error_setg(errp, "CPU '%s' does not allow changing the value of '%s'",
cpuname, propname);
}
target/riscv: Add "pmu-mask" property to replace "pmu-num" Using a mask instead of the number of PMU devices supports the accurate emulation of platforms that have a discontinuous set of PMU counters. The "pmu-num" property now generates a warning when used by the user on the command line. Rather than storing the value for "pmu-num" convert it directly to the mask if it is specified (overwriting the default "pmu-mask" value) likewise the value is calculated from the mask if the property value is obtained. In the unusual situation that both "pmu-mask" and "pmu-num" are provided then then the order on the command line determines which takes precedence (later overwriting earlier.) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031154000.18134-5-rbradford@rivosinc.com> [Changes by AF - Fixup ext_zihpm logic after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-31 18:37:16 +03:00
static void prop_pmu_num_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
uint8_t pmu_num, curr_pmu_num;
uint32_t pmu_mask;
target/riscv: Add "pmu-mask" property to replace "pmu-num" Using a mask instead of the number of PMU devices supports the accurate emulation of platforms that have a discontinuous set of PMU counters. The "pmu-num" property now generates a warning when used by the user on the command line. Rather than storing the value for "pmu-num" convert it directly to the mask if it is specified (overwriting the default "pmu-mask" value) likewise the value is calculated from the mask if the property value is obtained. In the unusual situation that both "pmu-mask" and "pmu-num" are provided then then the order on the command line determines which takes precedence (later overwriting earlier.) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031154000.18134-5-rbradford@rivosinc.com> [Changes by AF - Fixup ext_zihpm logic after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-31 18:37:16 +03:00
visit_type_uint8(v, name, &pmu_num, errp);
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
curr_pmu_num = ctpop32(cpu->cfg.pmu_mask);
if (pmu_num != curr_pmu_num && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, name, errp);
error_append_hint(errp, "Current '%s' val: %u\n",
name, curr_pmu_num);
return;
}
target/riscv: Add "pmu-mask" property to replace "pmu-num" Using a mask instead of the number of PMU devices supports the accurate emulation of platforms that have a discontinuous set of PMU counters. The "pmu-num" property now generates a warning when used by the user on the command line. Rather than storing the value for "pmu-num" convert it directly to the mask if it is specified (overwriting the default "pmu-mask" value) likewise the value is calculated from the mask if the property value is obtained. In the unusual situation that both "pmu-mask" and "pmu-num" are provided then then the order on the command line determines which takes precedence (later overwriting earlier.) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031154000.18134-5-rbradford@rivosinc.com> [Changes by AF - Fixup ext_zihpm logic after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-31 18:37:16 +03:00
if (pmu_num > (RV_MAX_MHPMCOUNTERS - 3)) {
error_setg(errp, "Number of counters exceeds maximum available");
return;
}
if (pmu_num == 0) {
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
pmu_mask = 0;
target/riscv: Add "pmu-mask" property to replace "pmu-num" Using a mask instead of the number of PMU devices supports the accurate emulation of platforms that have a discontinuous set of PMU counters. The "pmu-num" property now generates a warning when used by the user on the command line. Rather than storing the value for "pmu-num" convert it directly to the mask if it is specified (overwriting the default "pmu-mask" value) likewise the value is calculated from the mask if the property value is obtained. In the unusual situation that both "pmu-mask" and "pmu-num" are provided then then the order on the command line determines which takes precedence (later overwriting earlier.) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031154000.18134-5-rbradford@rivosinc.com> [Changes by AF - Fixup ext_zihpm logic after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-31 18:37:16 +03:00
} else {
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
pmu_mask = MAKE_64BIT_MASK(3, pmu_num);
target/riscv: Add "pmu-mask" property to replace "pmu-num" Using a mask instead of the number of PMU devices supports the accurate emulation of platforms that have a discontinuous set of PMU counters. The "pmu-num" property now generates a warning when used by the user on the command line. Rather than storing the value for "pmu-num" convert it directly to the mask if it is specified (overwriting the default "pmu-mask" value) likewise the value is calculated from the mask if the property value is obtained. In the unusual situation that both "pmu-mask" and "pmu-num" are provided then then the order on the command line determines which takes precedence (later overwriting earlier.) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031154000.18134-5-rbradford@rivosinc.com> [Changes by AF - Fixup ext_zihpm logic after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-31 18:37:16 +03:00
}
warn_report("\"pmu-num\" property is deprecated; use \"pmu-mask\"");
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
cpu->cfg.pmu_mask = pmu_mask;
cpu_option_add_user_setting("pmu-mask", pmu_mask);
target/riscv: Add "pmu-mask" property to replace "pmu-num" Using a mask instead of the number of PMU devices supports the accurate emulation of platforms that have a discontinuous set of PMU counters. The "pmu-num" property now generates a warning when used by the user on the command line. Rather than storing the value for "pmu-num" convert it directly to the mask if it is specified (overwriting the default "pmu-mask" value) likewise the value is calculated from the mask if the property value is obtained. In the unusual situation that both "pmu-mask" and "pmu-num" are provided then then the order on the command line determines which takes precedence (later overwriting earlier.) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031154000.18134-5-rbradford@rivosinc.com> [Changes by AF - Fixup ext_zihpm logic after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-31 18:37:16 +03:00
}
static void prop_pmu_num_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
uint8_t pmu_num = ctpop32(cpu->cfg.pmu_mask);
visit_type_uint8(v, name, &pmu_num, errp);
}
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
static const PropertyInfo prop_pmu_num = {
target/riscv: Add "pmu-mask" property to replace "pmu-num" Using a mask instead of the number of PMU devices supports the accurate emulation of platforms that have a discontinuous set of PMU counters. The "pmu-num" property now generates a warning when used by the user on the command line. Rather than storing the value for "pmu-num" convert it directly to the mask if it is specified (overwriting the default "pmu-mask" value) likewise the value is calculated from the mask if the property value is obtained. In the unusual situation that both "pmu-mask" and "pmu-num" are provided then then the order on the command line determines which takes precedence (later overwriting earlier.) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231031154000.18134-5-rbradford@rivosinc.com> [Changes by AF - Fixup ext_zihpm logic after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-31 18:37:16 +03:00
.name = "pmu-num",
.get = prop_pmu_num_get,
.set = prop_pmu_num_set,
};
target/riscv: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
static void prop_pmu_mask_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
uint32_t value;
uint8_t pmu_num;
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: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
visit_type_uint32(v, name, &value, errp);
if (value != cpu->cfg.pmu_mask && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, name, errp);
error_append_hint(errp, "Current '%s' val: %x\n",
name, cpu->cfg.pmu_mask);
return;
}
pmu_num = ctpop32(value);
if (pmu_num > (RV_MAX_MHPMCOUNTERS - 3)) {
error_setg(errp, "Number of counters exceeds maximum available");
return;
}
cpu_option_add_user_setting(name, value);
cpu->cfg.pmu_mask = value;
}
static void prop_pmu_mask_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
uint8_t pmu_mask = RISCV_CPU(obj)->cfg.pmu_mask;
visit_type_uint8(v, name, &pmu_mask, errp);
}
static const PropertyInfo prop_pmu_mask = {
.name = "pmu-mask",
.get = prop_pmu_mask_get,
.set = prop_pmu_mask_set,
};
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
static void prop_mmu_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
bool value;
visit_type_bool(v, name, &value, errp);
if (cpu->cfg.mmu != value && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, "mmu", errp);
return;
}
cpu_option_add_user_setting(name, value);
cpu->cfg.mmu = value;
}
static void prop_mmu_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
bool value = RISCV_CPU(obj)->cfg.mmu;
visit_type_bool(v, name, &value, errp);
}
static const PropertyInfo prop_mmu = {
.name = "mmu",
.get = prop_mmu_get,
.set = prop_mmu_set,
};
target/riscv: move 'pmp' to riscv_cpu_properties[] Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:34 +03:00
static void prop_pmp_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
bool value;
visit_type_bool(v, name, &value, errp);
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: move 'pmp' to riscv_cpu_properties[] Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:34 +03:00
if (cpu->cfg.pmp != value && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, name, errp);
return;
}
cpu_option_add_user_setting(name, value);
cpu->cfg.pmp = value;
}
static void prop_pmp_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
bool value = RISCV_CPU(obj)->cfg.pmp;
visit_type_bool(v, name, &value, errp);
}
static const PropertyInfo prop_pmp = {
.name = "pmp",
.get = prop_pmp_get,
.set = prop_pmp_set,
};
target/riscv: rework 'priv_spec' 'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We have a precedence for this kind of arrangement in target/ppc/compat.c, ppc_compat_prop_get|set, getters and setters used for the 'max-cpu-compat' class property of the pseries ppc64 machine. We'll do the same with both 'priv_spec' and 'vext_spec'. For 'priv_spec', the validation from riscv_cpu_validate_priv_spec() will be done by the prop_priv_spec_set() setter, while also preventing it to be changed for vendor CPUs. Add two helpers that converts env->priv_ver back and forth to its string representation. These helpers allow us to get a string and set 'env->priv_ver' and return a string giving the current env->priv_ver value. In other words, make the cpu->cfg.priv_spec string obsolete. Last but not the least, move the reworked 'priv_spec' option to riscv_cpu_properties[]. After all said and done, we don't need to store the 'priv_spec' string in the CPU state, and we're now protecting vendor CPUs from priv_ver changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,priv_spec="v1.12.0" qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.priv_spec=v1.12.0: CPU 'sifive-e51' does not allow changing the value of 'priv_spec' Current 'priv_spec' val: v1.10.0 $ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:35 +03:00
static int priv_spec_from_str(const char *priv_spec_str)
{
int priv_version = -1;
target/riscv: Support the version for ss1p13 Add RISC-V privilege 1.13 support. Signed-off-by: Fea.Wang <fea.wang@sifive.com> Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Weiwei Li <liwei1518@gmail.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20240606135454.119186-7-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-06 16:54:54 +03:00
if (!g_strcmp0(priv_spec_str, PRIV_VER_1_13_0_STR)) {
priv_version = PRIV_VERSION_1_13_0;
} else if (!g_strcmp0(priv_spec_str, PRIV_VER_1_12_0_STR)) {
target/riscv: rework 'priv_spec' 'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We have a precedence for this kind of arrangement in target/ppc/compat.c, ppc_compat_prop_get|set, getters and setters used for the 'max-cpu-compat' class property of the pseries ppc64 machine. We'll do the same with both 'priv_spec' and 'vext_spec'. For 'priv_spec', the validation from riscv_cpu_validate_priv_spec() will be done by the prop_priv_spec_set() setter, while also preventing it to be changed for vendor CPUs. Add two helpers that converts env->priv_ver back and forth to its string representation. These helpers allow us to get a string and set 'env->priv_ver' and return a string giving the current env->priv_ver value. In other words, make the cpu->cfg.priv_spec string obsolete. Last but not the least, move the reworked 'priv_spec' option to riscv_cpu_properties[]. After all said and done, we don't need to store the 'priv_spec' string in the CPU state, and we're now protecting vendor CPUs from priv_ver changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,priv_spec="v1.12.0" qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.priv_spec=v1.12.0: CPU 'sifive-e51' does not allow changing the value of 'priv_spec' Current 'priv_spec' val: v1.10.0 $ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:35 +03:00
priv_version = PRIV_VERSION_1_12_0;
} else if (!g_strcmp0(priv_spec_str, PRIV_VER_1_11_0_STR)) {
priv_version = PRIV_VERSION_1_11_0;
} else if (!g_strcmp0(priv_spec_str, PRIV_VER_1_10_0_STR)) {
priv_version = PRIV_VERSION_1_10_0;
}
return priv_version;
}
target/riscv: Reuse the conversion function of priv_spec Public the conversion function of priv_spec in cpu.h, so that tcg-cpu.c could also use it. Signed-off-by: Jim Shu <jim.shu@sifive.com> Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240606135454.119186-2-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-06 16:54:49 +03:00
const char *priv_spec_to_str(int priv_version)
target/riscv: rework 'priv_spec' 'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We have a precedence for this kind of arrangement in target/ppc/compat.c, ppc_compat_prop_get|set, getters and setters used for the 'max-cpu-compat' class property of the pseries ppc64 machine. We'll do the same with both 'priv_spec' and 'vext_spec'. For 'priv_spec', the validation from riscv_cpu_validate_priv_spec() will be done by the prop_priv_spec_set() setter, while also preventing it to be changed for vendor CPUs. Add two helpers that converts env->priv_ver back and forth to its string representation. These helpers allow us to get a string and set 'env->priv_ver' and return a string giving the current env->priv_ver value. In other words, make the cpu->cfg.priv_spec string obsolete. Last but not the least, move the reworked 'priv_spec' option to riscv_cpu_properties[]. After all said and done, we don't need to store the 'priv_spec' string in the CPU state, and we're now protecting vendor CPUs from priv_ver changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,priv_spec="v1.12.0" qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.priv_spec=v1.12.0: CPU 'sifive-e51' does not allow changing the value of 'priv_spec' Current 'priv_spec' val: v1.10.0 $ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:35 +03:00
{
switch (priv_version) {
case PRIV_VERSION_1_10_0:
return PRIV_VER_1_10_0_STR;
case PRIV_VERSION_1_11_0:
return PRIV_VER_1_11_0_STR;
case PRIV_VERSION_1_12_0:
return PRIV_VER_1_12_0_STR;
target/riscv: Support the version for ss1p13 Add RISC-V privilege 1.13 support. Signed-off-by: Fea.Wang <fea.wang@sifive.com> Signed-off-by: Fea.Wang <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Weiwei Li <liwei1518@gmail.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20240606135454.119186-7-fea.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-06 16:54:54 +03:00
case PRIV_VERSION_1_13_0:
return PRIV_VER_1_13_0_STR;
target/riscv: rework 'priv_spec' 'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We have a precedence for this kind of arrangement in target/ppc/compat.c, ppc_compat_prop_get|set, getters and setters used for the 'max-cpu-compat' class property of the pseries ppc64 machine. We'll do the same with both 'priv_spec' and 'vext_spec'. For 'priv_spec', the validation from riscv_cpu_validate_priv_spec() will be done by the prop_priv_spec_set() setter, while also preventing it to be changed for vendor CPUs. Add two helpers that converts env->priv_ver back and forth to its string representation. These helpers allow us to get a string and set 'env->priv_ver' and return a string giving the current env->priv_ver value. In other words, make the cpu->cfg.priv_spec string obsolete. Last but not the least, move the reworked 'priv_spec' option to riscv_cpu_properties[]. After all said and done, we don't need to store the 'priv_spec' string in the CPU state, and we're now protecting vendor CPUs from priv_ver changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,priv_spec="v1.12.0" qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.priv_spec=v1.12.0: CPU 'sifive-e51' does not allow changing the value of 'priv_spec' Current 'priv_spec' val: v1.10.0 $ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:35 +03:00
default:
return NULL;
}
}
static void prop_priv_spec_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
g_autofree char *value = NULL;
int priv_version = -1;
visit_type_str(v, name, &value, errp);
priv_version = priv_spec_from_str(value);
if (priv_version < 0) {
error_setg(errp, "Unsupported privilege spec version '%s'", value);
return;
}
if (priv_version != cpu->env.priv_ver && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, name, errp);
error_append_hint(errp, "Current '%s' val: %s\n", name,
object_property_get_str(obj, name, NULL));
return;
}
cpu_option_add_user_setting(name, priv_version);
cpu->env.priv_ver = priv_version;
}
static void prop_priv_spec_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
const char *value = priv_spec_to_str(cpu->env.priv_ver);
visit_type_str(v, name, (char **)&value, errp);
}
static const PropertyInfo prop_priv_spec = {
.name = "priv_spec",
.get = prop_priv_spec_get,
.set = prop_priv_spec_set,
};
target/riscv: rework 'vext_spec' The same rework did in 'priv_spec' is done for 'vext_spec'. This time is simpler, since we only accept one value ("v1.0") and we'll always have env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to convert string to 'vext_ver' back and forth like we needed for 'priv_spec'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:36 +03:00
static void prop_vext_spec_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
g_autofree char *value = NULL;
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: rework 'vext_spec' The same rework did in 'priv_spec' is done for 'vext_spec'. This time is simpler, since we only accept one value ("v1.0") and we'll always have env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to convert string to 'vext_ver' back and forth like we needed for 'priv_spec'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:36 +03:00
visit_type_str(v, name, &value, errp);
if (g_strcmp0(value, VEXT_VER_1_00_0_STR) != 0) {
error_setg(errp, "Unsupported vector spec version '%s'", value);
return;
}
cpu_option_add_user_setting(name, VEXT_VERSION_1_00_0);
cpu->env.vext_ver = VEXT_VERSION_1_00_0;
}
static void prop_vext_spec_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
const char *value = VEXT_VER_1_00_0_STR;
visit_type_str(v, name, (char **)&value, errp);
}
static const PropertyInfo prop_vext_spec = {
.name = "vext_spec",
.get = prop_vext_spec_get,
.set = prop_vext_spec_set,
};
target/riscv: move 'vlen' to riscv_cpu_properties[] Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared with KVM. And, as done with every option we migrated to riscv_cpu_properties[], vendor CPUs can't have their 'vlen' value changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:37 +03:00
static void prop_vlen_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
uint16_t value;
if (!visit_type_uint16(v, name, &value, errp)) {
return;
}
if (!is_power_of_2(value)) {
error_setg(errp, "Vector extension VLEN must be power of 2");
return;
}
target/riscv/cpu.c: remove cpu->cfg.vlen There is no need to keep both 'vlen' and 'vlenb'. All existing code that requires 'vlen' is retrieving it via 'vlenb << 3'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 19:11:07 +03:00
if (value != cpu->cfg.vlenb && riscv_cpu_is_vendor(obj)) {
target/riscv: move 'vlen' to riscv_cpu_properties[] Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared with KVM. And, as done with every option we migrated to riscv_cpu_properties[], vendor CPUs can't have their 'vlen' value changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:37 +03:00
cpu_set_prop_err(cpu, name, errp);
error_append_hint(errp, "Current '%s' val: %u\n",
target/riscv/cpu.c: remove cpu->cfg.vlen There is no need to keep both 'vlen' and 'vlenb'. All existing code that requires 'vlen' is retrieving it via 'vlenb << 3'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 19:11:07 +03:00
name, cpu->cfg.vlenb << 3);
target/riscv: move 'vlen' to riscv_cpu_properties[] Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared with KVM. And, as done with every option we migrated to riscv_cpu_properties[], vendor CPUs can't have their 'vlen' value changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:37 +03:00
return;
}
cpu_option_add_user_setting(name, value);
target/riscv: add 'vlenb' field in cpu->cfg Our usage of 'vlenb' is overwhelming superior than the use of 'vlen'. We're using 'vlenb' most of the time, having to do 'vlen >> 3' or 'vlen / 8' in every instance. In hindsight we would be better if the 'vlenb' property was introduced instead of 'vlen'. That's not what happened, and now we can't easily get rid of it due to user scripts all around. What we can do, however, is to change our internal representation to use 'vlenb'. Add a 'vlenb' field in cpu->cfg. It'll be set via the existing 'vlen' property, i.e. setting 'vlen' will also set 'vlenb'. We'll replace all 'vlen >> 3' code to use 'vlenb' directly. Start with the single instance we have in target/riscv/cpu.c. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 19:10:55 +03:00
cpu->cfg.vlenb = value >> 3;
target/riscv: move 'vlen' to riscv_cpu_properties[] Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared with KVM. And, as done with every option we migrated to riscv_cpu_properties[], vendor CPUs can't have their 'vlen' value changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:37 +03:00
}
static void prop_vlen_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
target/riscv/cpu.c: remove cpu->cfg.vlen There is no need to keep both 'vlen' and 'vlenb'. All existing code that requires 'vlen' is retrieving it via 'vlenb << 3'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 19:11:07 +03:00
uint16_t value = RISCV_CPU(obj)->cfg.vlenb << 3;
target/riscv: move 'vlen' to riscv_cpu_properties[] Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared with KVM. And, as done with every option we migrated to riscv_cpu_properties[], vendor CPUs can't have their 'vlen' value changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:37 +03:00
visit_type_uint16(v, name, &value, errp);
}
static const PropertyInfo prop_vlen = {
.name = "vlen",
.get = prop_vlen_get,
.set = prop_vlen_set,
};
target/riscv: move 'elen' to riscv_cpu_properties[] Do the same thing we did with 'vlen' in the previous patch with 'elen'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:38 +03:00
static void prop_elen_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
uint16_t value;
if (!visit_type_uint16(v, name, &value, errp)) {
return;
}
if (!is_power_of_2(value)) {
error_setg(errp, "Vector extension ELEN must be power of 2");
return;
}
if (value != cpu->cfg.elen && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, name, errp);
error_append_hint(errp, "Current '%s' val: %u\n",
name, cpu->cfg.elen);
return;
}
cpu_option_add_user_setting(name, value);
cpu->cfg.elen = value;
}
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: move 'elen' to riscv_cpu_properties[] Do the same thing we did with 'vlen' in the previous patch with 'elen'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:38 +03:00
static void prop_elen_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
uint16_t value = RISCV_CPU(obj)->cfg.elen;
visit_type_uint16(v, name, &value, errp);
}
static const PropertyInfo prop_elen = {
.name = "elen",
.get = prop_elen_get,
.set = prop_elen_set,
};
target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[] After adding a KVM finalize() implementation, turn cbom_blocksize into a class property. Follow the same design we used with 'vlen' and 'elen'. The duplicated 'cbom_blocksize' KVM property can be removed from kvm_riscv_add_cpu_user_properties(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:55 +03:00
static void prop_cbom_blksize_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
uint16_t value;
if (!visit_type_uint16(v, name, &value, errp)) {
return;
}
if (value != cpu->cfg.cbom_blocksize && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, name, errp);
error_append_hint(errp, "Current '%s' val: %u\n",
name, cpu->cfg.cbom_blocksize);
return;
}
cpu_option_add_user_setting(name, value);
cpu->cfg.cbom_blocksize = value;
}
static void prop_cbom_blksize_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
uint16_t value = RISCV_CPU(obj)->cfg.cbom_blocksize;
visit_type_uint16(v, name, &value, errp);
}
static const PropertyInfo prop_cbom_blksize = {
.name = "cbom_blocksize",
.get = prop_cbom_blksize_get,
.set = prop_cbom_blksize_set,
};
target/riscv: move 'cbop_blocksize' to riscv_cpu_properties[] Do the same we did with 'cbom_blocksize' in the previous patch. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:56 +03:00
static void prop_cbop_blksize_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
uint16_t value;
if (!visit_type_uint16(v, name, &value, errp)) {
return;
}
if (value != cpu->cfg.cbop_blocksize && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, name, errp);
error_append_hint(errp, "Current '%s' val: %u\n",
name, cpu->cfg.cbop_blocksize);
return;
}
cpu_option_add_user_setting(name, value);
cpu->cfg.cbop_blocksize = value;
}
static void prop_cbop_blksize_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
uint16_t value = RISCV_CPU(obj)->cfg.cbop_blocksize;
visit_type_uint16(v, name, &value, errp);
}
static const PropertyInfo prop_cbop_blksize = {
.name = "cbop_blocksize",
.get = prop_cbop_blksize_get,
.set = prop_cbop_blksize_set,
};
target/riscv: move 'cboz_blocksize' to riscv_cpu_properties[] And remove the now unused kvm_cpu_set_cbomz_blksize() setter. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:57 +03:00
static void prop_cboz_blksize_set(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
RISCVCPU *cpu = RISCV_CPU(obj);
uint16_t value;
if (!visit_type_uint16(v, name, &value, errp)) {
return;
}
if (value != cpu->cfg.cboz_blocksize && riscv_cpu_is_vendor(obj)) {
cpu_set_prop_err(cpu, name, errp);
error_append_hint(errp, "Current '%s' val: %u\n",
name, cpu->cfg.cboz_blocksize);
return;
}
cpu_option_add_user_setting(name, value);
cpu->cfg.cboz_blocksize = value;
}
static void prop_cboz_blksize_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
uint16_t value = RISCV_CPU(obj)->cfg.cboz_blocksize;
visit_type_uint16(v, name, &value, errp);
}
static const PropertyInfo prop_cboz_blksize = {
.name = "cboz_blocksize",
.get = prop_cboz_blksize_get,
.set = prop_cboz_blksize_set,
};
target/riscv/cpu.c: move 'mvendorid' to riscv_cpu_properties[] Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:59 +03:00
static void prop_mvendorid_set(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 prop_mvendorid_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
uint32_t value = RISCV_CPU(obj)->cfg.mvendorid;
visit_type_uint32(v, name, &value, errp);
}
static const PropertyInfo prop_mvendorid = {
.name = "mvendorid",
.get = prop_mvendorid_get,
.set = prop_mvendorid_set,
};
target/riscv/cpu.c: move 'mimpid' to riscv_cpu_properties[] Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:02:00 +03:00
static void prop_mimpid_set(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 prop_mimpid_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
uint64_t value = RISCV_CPU(obj)->cfg.mimpid;
visit_type_uint64(v, name, &value, errp);
}
static const PropertyInfo prop_mimpid = {
.name = "mimpid",
.get = prop_mimpid_get,
.set = prop_mimpid_set,
};
target/riscv/cpu.c: move 'marchid' to riscv_cpu_properties[] Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:02:01 +03:00
static void prop_marchid_set(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 prop_marchid_get(Object *obj, Visitor *v, const char *name,
void *opaque, Error **errp)
{
uint64_t value = RISCV_CPU(obj)->cfg.marchid;
visit_type_uint64(v, name, &value, errp);
}
static const PropertyInfo prop_marchid = {
.name = "marchid",
.get = prop_marchid_get,
.set = prop_marchid_set,
};
target/riscv: add rva22u64 profile definition The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:16 +03:00
/*
target/riscv: add remaining named features The RVA22U64 and RVA22S64 profiles mandates certain extensions that, until now, we were implying that they were available. We can't do this anymore since named features also has a riscv,isa entry. Let's add them to riscv_cpu_named_features[]. Instead of adding one bool for each named feature that we'll always implement, i.e. can't be turned off, add a 'ext_always_enabled' bool in cpu->cfg. This bool will be set to 'true' in TCG accel init, and all named features will point to it. This also means that KVM won't see these features as always enable, which is our intention. If any accelerator adds support to disable one of these features, we'll have to promote them to regular extensions and allow users to disable it via command line. After this patch, here's the riscv,isa from a buildroot using the 'rva22s64' CPU: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zic64b_zicbom_zicbop_zicboz_ziccamoa_ziccif_zicclsm_ziccrse_ zicntr_zicsr_zifencei_zihintpause_zihpm_za64rs_zfhmin_zca_zcd_zba_zbb_ zbs_zkt_ssccptr_sscounterenw_sstvala_sstvecd_svade_svinval_svpbmt# 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: <20240215223955.969568-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:52 +03:00
* RVA22U64 defines some 'named features' that are cache
* related: Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa
* and Zicclsm. They are always implemented in TCG and
* doesn't need to be manually enabled by the profile.
target/riscv: add rva22u64 profile definition The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:16 +03:00
*/
static RISCVCPUProfile RVA22U64 = {
target/riscv: add 'parent' in profile description Certain S-mode profiles, like RVA22S64 and RVA23S64, mandate all the mandatory extensions of their respective U-mode profiles. RVA22S64 includes all mandatory extensions of RVA22U64, and the same happens with RVA23 profiles. Add a 'parent' field to allow profiles to enable other profiles. This will allow us to describe S-mode profiles by specifying their parent U-mode profile, then adding just the S-mode specific extensions. We're naming the field 'parent' to consider the possibility of other uses (e.g. a s-mode profile including a previous s-mode profile) in the future. Suggested-by: Andrew Jones <ajones@ventanamicro.com> 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: <20231218125334.37184-25-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:32 +03:00
.parent = NULL,
target/riscv: add rva22u64 profile definition The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:16 +03:00
.name = "rva22u64",
.misa_ext = RVI | RVM | RVA | RVF | RVD | RVC | RVU,
target/riscv: add priv ver restriction to profiles Some profiles, like RVA22S64, has a priv_spec requirement. Make this requirement explicit for all profiles. We'll validate this requirement finalize() time and, in case the user chooses an incompatible priv_spec while activating a profile, a warning will be shown. 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: <20231218125334.37184-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:28 +03:00
.priv_spec = RISCV_PROFILE_ATTR_UNUSED,
target/riscv: add satp_mode profile support 'satp_mode' is a requirement for supervisor profiles like RVA22S64. User-mode/application profiles like RVA22U64 doesn't care. Add 'satp_mode' to the profile description. If a profile requires it, set it during cpu_set_profile(). We'll also check it during finalize() to validate if the running config implements the profile. 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: <20231218125334.37184-24-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:31 +03:00
.satp_mode = RISCV_PROFILE_ATTR_UNUSED,
target/riscv: add rva22u64 profile definition The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:16 +03:00
.ext_offsets = {
CPU_CFG_OFFSET(ext_zicsr), CPU_CFG_OFFSET(ext_zihintpause),
CPU_CFG_OFFSET(ext_zba), CPU_CFG_OFFSET(ext_zbb),
CPU_CFG_OFFSET(ext_zbs), CPU_CFG_OFFSET(ext_zfhmin),
CPU_CFG_OFFSET(ext_zkt), CPU_CFG_OFFSET(ext_zicntr),
CPU_CFG_OFFSET(ext_zihpm), CPU_CFG_OFFSET(ext_zicbom),
CPU_CFG_OFFSET(ext_zicbop), CPU_CFG_OFFSET(ext_zicboz),
/* mandatory named features for this profile */
target/riscv: add riscv,isa to named features Further discussions after the introduction of rva22 support in QEMU revealed that what we've been calling 'named features' are actually regular extensions, with their respective riscv,isa DTs. This is clarified in [1]. [2] is a bug tracker asking for the profile spec to be less cryptic about it. As far as QEMU goes we understand extensions as something that the user can enable/disable in the command line. This isn't the case for named features, so we'll have to reach a middle ground. We'll keep our existing nomenclature 'named features' to refer to any extension that the user can't control in the command line. We'll also do the following: - 'svade' and 'zic64b' flags are renamed to 'ext_svade' and 'ext_zic64b'. 'ext_svade' and 'ext_zic64b' now have riscv,isa strings and priv_spec versions; - skip name feature check in cpu_bump_multi_ext_priv_ver(). Now that named features have a riscv,isa and an entry in isa_edata_arr[] we don't need to gate the call to cpu_cfg_ext_get_min_version() anymore. [1] https://github.com/riscv/riscv-profiles/issues/121 [2] https://github.com/riscv/riscv-profiles/issues/142 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: <20240215223955.969568-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:51 +03:00
CPU_CFG_OFFSET(ext_zic64b),
target/riscv: add rva22u64 profile definition The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:16 +03:00
RISCV_PROFILE_EXT_LIST_END
}
};
target/riscv: add RVA22S64 profile The RVA22S64 profile consists of the following: - all mandatory extensions of RVA22U64; - priv spec v1.12.0; - satp mode sv39; - Ssccptr, a cache related named feature that we're assuming always enable since we don't implement a cache; - Other named features already implemented: Sstvecd, Sstvala, Sscounterenw; - the new Svade named feature that was recently added. Most of the work is already done, so this patch is enough to implement the profile. After this patch, the 'rva22s64' user flag alone can be used with the rva64i CPU to boot Linux: -cpu rv64i,rva22s64=true This is the /proc/cpuinfo with this profile enabled: # cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc_zicbom_zicbop_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zfhmin_zca_zcd_zba_zbb_zbs_zkt_svinval_svpbmt mmu : sv39 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: <20231218125334.37184-26-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:33 +03:00
/*
* As with RVA22U64, RVA22S64 also defines 'named features'.
*
* Cache related features that we consider enabled since we don't
* implement cache: Ssccptr
*
* Other named features that we already implement: Sstvecd, Sstvala,
* Sscounterenw
*
* The remaining features/extensions comes from RVA22U64.
*/
static RISCVCPUProfile RVA22S64 = {
.parent = &RVA22U64,
.name = "rva22s64",
.misa_ext = RVS,
.priv_spec = PRIV_VERSION_1_12_0,
.satp_mode = VM_1_10_SV39,
.ext_offsets = {
/* rva22s64 exts */
CPU_CFG_OFFSET(ext_zifencei), CPU_CFG_OFFSET(ext_svpbmt),
target/riscv: Promote svade to a normal extension Named features are extensions which don't make sense for users to control and are therefore not exposed on the command line. However, svade is an extension which makes sense for users to control, so treat it like a "normal" extension. The default is false, even for the max cpu type, since QEMU has always implemented hardware A/D PTE bit updating, so users must opt into svade (or get it from a CPU type which enables it by default). Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240215223955.969568-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-16 01:39:55 +03:00
CPU_CFG_OFFSET(ext_svinval), CPU_CFG_OFFSET(ext_svade),
target/riscv: add RVA22S64 profile The RVA22S64 profile consists of the following: - all mandatory extensions of RVA22U64; - priv spec v1.12.0; - satp mode sv39; - Ssccptr, a cache related named feature that we're assuming always enable since we don't implement a cache; - Other named features already implemented: Sstvecd, Sstvala, Sscounterenw; - the new Svade named feature that was recently added. Most of the work is already done, so this patch is enough to implement the profile. After this patch, the 'rva22s64' user flag alone can be used with the rva64i CPU to boot Linux: -cpu rv64i,rva22s64=true This is the /proc/cpuinfo with this profile enabled: # cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc_zicbom_zicbop_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zfhmin_zca_zcd_zba_zbb_zbs_zkt_svinval_svpbmt mmu : sv39 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: <20231218125334.37184-26-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:33 +03:00
RISCV_PROFILE_EXT_LIST_END
}
};
target/riscv: add rva22u64 profile definition The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:16 +03:00
RISCVCPUProfile *riscv_profiles[] = {
&RVA22U64,
target/riscv: add RVA22S64 profile The RVA22S64 profile consists of the following: - all mandatory extensions of RVA22U64; - priv spec v1.12.0; - satp mode sv39; - Ssccptr, a cache related named feature that we're assuming always enable since we don't implement a cache; - Other named features already implemented: Sstvecd, Sstvala, Sscounterenw; - the new Svade named feature that was recently added. Most of the work is already done, so this patch is enough to implement the profile. After this patch, the 'rva22s64' user flag alone can be used with the rva64i CPU to boot Linux: -cpu rv64i,rva22s64=true This is the /proc/cpuinfo with this profile enabled: # cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc_zicbom_zicbop_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zfhmin_zca_zcd_zba_zbb_zbs_zkt_svinval_svpbmt mmu : sv39 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: <20231218125334.37184-26-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:33 +03:00
&RVA22S64,
target/riscv: add rva22u64 profile definition The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:16 +03:00
NULL,
};
target/riscv: Add MISA extension implied rules Add MISA extension implied rules to enable the implied extensions of MISA recursively. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com> Tested-by: Max Chou <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240625114629.27793-4-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-25 14:46:26 +03:00
static RISCVCPUImpliedExtsRule RVA_IMPLIED = {
.is_misa = true,
.ext = RVA,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zalrsc), CPU_CFG_OFFSET(ext_zaamo),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule RVD_IMPLIED = {
.is_misa = true,
.ext = RVD,
.implied_misa_exts = RVF,
.implied_multi_exts = { RISCV_IMPLIED_EXTS_RULE_END },
};
static RISCVCPUImpliedExtsRule RVF_IMPLIED = {
.is_misa = true,
.ext = RVF,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zicsr),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule RVM_IMPLIED = {
.is_misa = true,
.ext = RVM,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zmmul),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule RVV_IMPLIED = {
.is_misa = true,
.ext = RVV,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zve64d),
RISCV_IMPLIED_EXTS_RULE_END
},
};
target/riscv: Add multi extension implied rules Add multi extension implied rules to enable the implied extensions of the multi extension recursively. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com> Tested-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240625114629.27793-5-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-25 14:46:27 +03:00
static RISCVCPUImpliedExtsRule ZCB_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zcb),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zca),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZCD_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zcd),
.implied_misa_exts = RVD,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zca),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZCE_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zce),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zcb), CPU_CFG_OFFSET(ext_zcmp),
CPU_CFG_OFFSET(ext_zcmt),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZCF_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zcf),
.implied_misa_exts = RVF,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zca),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZCMP_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zcmp),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zca),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZCMT_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zcmt),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zca), CPU_CFG_OFFSET(ext_zicsr),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZDINX_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zdinx),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zfinx),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZFA_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zfa),
.implied_misa_exts = RVF,
.implied_multi_exts = { RISCV_IMPLIED_EXTS_RULE_END },
};
static RISCVCPUImpliedExtsRule ZFBFMIN_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zfbfmin),
.implied_misa_exts = RVF,
.implied_multi_exts = { RISCV_IMPLIED_EXTS_RULE_END },
};
static RISCVCPUImpliedExtsRule ZFH_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zfh),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zfhmin),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZFHMIN_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zfhmin),
.implied_misa_exts = RVF,
.implied_multi_exts = { RISCV_IMPLIED_EXTS_RULE_END },
};
static RISCVCPUImpliedExtsRule ZFINX_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zfinx),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zicsr),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZHINX_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zhinx),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zhinxmin),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZHINXMIN_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zhinxmin),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zfinx),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZICNTR_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zicntr),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zicsr),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZIHPM_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zihpm),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zicsr),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZK_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zk),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zkn), CPU_CFG_OFFSET(ext_zkr),
CPU_CFG_OFFSET(ext_zkt),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZKN_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zkn),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zbkb), CPU_CFG_OFFSET(ext_zbkc),
CPU_CFG_OFFSET(ext_zbkx), CPU_CFG_OFFSET(ext_zkne),
CPU_CFG_OFFSET(ext_zknd), CPU_CFG_OFFSET(ext_zknh),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZKS_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zks),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zbkb), CPU_CFG_OFFSET(ext_zbkc),
CPU_CFG_OFFSET(ext_zbkx), CPU_CFG_OFFSET(ext_zksed),
CPU_CFG_OFFSET(ext_zksh),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVBB_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvbb),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvkb),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVE32F_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zve32f),
.implied_misa_exts = RVF,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zve32x),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVE32X_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zve32x),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zicsr),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVE64D_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zve64d),
.implied_misa_exts = RVD,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zve64f),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVE64F_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zve64f),
.implied_misa_exts = RVF,
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zve32f), CPU_CFG_OFFSET(ext_zve64x),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVE64X_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zve64x),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zve32x),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVFBFMIN_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvfbfmin),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zve32f),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVFBFWMA_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvfbfwma),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvfbfmin), CPU_CFG_OFFSET(ext_zfbfmin),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVFH_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvfh),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvfhmin), CPU_CFG_OFFSET(ext_zfhmin),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVFHMIN_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvfhmin),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zve32f),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVKN_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvkn),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvkned), CPU_CFG_OFFSET(ext_zvknhb),
CPU_CFG_OFFSET(ext_zvkb), CPU_CFG_OFFSET(ext_zvkt),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVKNC_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvknc),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvkn), CPU_CFG_OFFSET(ext_zvbc),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVKNG_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvkng),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvkn), CPU_CFG_OFFSET(ext_zvkg),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVKNHB_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvknhb),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zve64x),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVKS_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvks),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvksed), CPU_CFG_OFFSET(ext_zvksh),
CPU_CFG_OFFSET(ext_zvkb), CPU_CFG_OFFSET(ext_zvkt),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVKSC_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvksc),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvks), CPU_CFG_OFFSET(ext_zvbc),
RISCV_IMPLIED_EXTS_RULE_END
},
};
static RISCVCPUImpliedExtsRule ZVKSG_IMPLIED = {
.ext = CPU_CFG_OFFSET(ext_zvksg),
.implied_multi_exts = {
CPU_CFG_OFFSET(ext_zvks), CPU_CFG_OFFSET(ext_zvkg),
RISCV_IMPLIED_EXTS_RULE_END
},
};
target/riscv: Introduce extension implied rules definition RISCVCPUImpliedExtsRule is created to store the implied rules. 'is_misa' flag is used to distinguish whether the rule is derived from the MISA or other extensions. 'ext' stores the MISA bit if 'is_misa' is true. Otherwise, it stores the offset of the extension defined in RISCVCPUConfig. 'ext' will also serve as the key of the hash tables to look up the rule in the following commit. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com> Tested-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240625114629.27793-2-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-25 14:46:24 +03:00
RISCVCPUImpliedExtsRule *riscv_misa_ext_implied_rules[] = {
target/riscv: Add MISA extension implied rules Add MISA extension implied rules to enable the implied extensions of MISA recursively. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com> Tested-by: Max Chou <max.chou@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240625114629.27793-4-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-25 14:46:26 +03:00
&RVA_IMPLIED, &RVD_IMPLIED, &RVF_IMPLIED,
&RVM_IMPLIED, &RVV_IMPLIED, NULL
target/riscv: Introduce extension implied rules definition RISCVCPUImpliedExtsRule is created to store the implied rules. 'is_misa' flag is used to distinguish whether the rule is derived from the MISA or other extensions. 'ext' stores the MISA bit if 'is_misa' is true. Otherwise, it stores the offset of the extension defined in RISCVCPUConfig. 'ext' will also serve as the key of the hash tables to look up the rule in the following commit. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com> Tested-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240625114629.27793-2-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-25 14:46:24 +03:00
};
RISCVCPUImpliedExtsRule *riscv_multi_ext_implied_rules[] = {
target/riscv: Add multi extension implied rules Add multi extension implied rules to enable the implied extensions of the multi extension recursively. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com> Tested-by: Max Chou <max.chou@sifive.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240625114629.27793-5-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-25 14:46:27 +03:00
&ZCB_IMPLIED, &ZCD_IMPLIED, &ZCE_IMPLIED,
&ZCF_IMPLIED, &ZCMP_IMPLIED, &ZCMT_IMPLIED,
&ZDINX_IMPLIED, &ZFA_IMPLIED, &ZFBFMIN_IMPLIED,
&ZFH_IMPLIED, &ZFHMIN_IMPLIED, &ZFINX_IMPLIED,
&ZHINX_IMPLIED, &ZHINXMIN_IMPLIED, &ZICNTR_IMPLIED,
&ZIHPM_IMPLIED, &ZK_IMPLIED, &ZKN_IMPLIED,
&ZKS_IMPLIED, &ZVBB_IMPLIED, &ZVE32F_IMPLIED,
&ZVE32X_IMPLIED, &ZVE64D_IMPLIED, &ZVE64F_IMPLIED,
&ZVE64X_IMPLIED, &ZVFBFMIN_IMPLIED, &ZVFBFWMA_IMPLIED,
&ZVFH_IMPLIED, &ZVFHMIN_IMPLIED, &ZVKN_IMPLIED,
&ZVKNC_IMPLIED, &ZVKNG_IMPLIED, &ZVKNHB_IMPLIED,
&ZVKS_IMPLIED, &ZVKSC_IMPLIED, &ZVKSG_IMPLIED,
target/riscv: Introduce extension implied rules definition RISCVCPUImpliedExtsRule is created to store the implied rules. 'is_misa' flag is used to distinguish whether the rule is derived from the MISA or other extensions. 'ext' stores the MISA bit if 'is_misa' is true. Otherwise, it stores the offset of the extension defined in RISCVCPUConfig. 'ext' will also serve as the key of the hash tables to look up the rule in the following commit. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com> Tested-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240625114629.27793-2-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-06-25 14:46:24 +03:00
NULL
};
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: move 'pmu-mask' and 'pmu-num' to riscv_cpu_properties[] Every property in riscv_cpu_options[] will be migrated to riscv_cpu_properties[]. This will make their default values init earlier, allowing cpu_init() functions to overwrite them. We'll also implement common getters and setters that both accelerators will use, allowing them to share validations that TCG is doing. At the same time, some options (namely 'vlen', 'elen' and the cache blocksizes) need a way of tracking if the user set a value for them. This is benign for TCG since the cost of always validating these values are small, but for KVM we need syscalls to read the host values to make the validations, thus knowing whether the user didn't touch the values makes a difference. We'll track user setting for these properties using a hash, like we do in the TCG driver. All riscv cpu options will update this hash in case the user sets it. The KVM driver will use this hash to minimize the amount of syscalls done. For now, both 'pmu-mask' and 'pmu-num' shouldn't be changed for vendor CPUs. The existing setter for 'pmu-num' is changed to add this restriction. New getters and setters are required for 'pmu-mask' While we're at it, add a 'static' modifier to 'prop_pmu_num' since we're not exporting it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:32 +03:00
{.name = "pmu-mask", .info = &prop_pmu_mask},
{.name = "pmu-num", .info = &prop_pmu_num}, /* Deprecated */
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
{.name = "mmu", .info = &prop_mmu},
target/riscv: move 'pmp' to riscv_cpu_properties[] Move 'pmp' to riscv_cpu_properties[], creating a new setter() for it that forbids 'pmp' to be changed in vendor CPUs, like we did with the 'mmu' option. We'll also have to manually set 'pmp = true' to generic CPUs that were still relying on the previous default to set it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:34 +03:00
{.name = "pmp", .info = &prop_pmp},
target/riscv: move 'mmu' to riscv_cpu_properties[] Commit 7f0bdfb5bfc ("target/riscv/cpu.c: remove cfg setup from riscv_cpu_init()") already did some of the work by making some cpu_init() functions to explictly enable their own 'mmu' default. The generic CPUs didn't get update by that commit, so they are still relying on the defaults set by the 'mmu' option. But having 'mmu' and 'pmp' being default=true will force CPUs that doesn't implement these options to set them to 'false' in their cpu_init(), which isn't ideal. We'll move 'mmu' to riscv_cpu_properties[] without any defaults, i.e. the default will be 'false'. Compensate it by manually setting 'mmu = true' to the generic CPUs that requires it. Implement a setter for it to forbid the 'mmu' setting to be changed for vendor CPUs. This will allow the option to exist for all CPUs and, at the same time, protect vendor CPUs from undesired changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,mmu=true qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.mmu=true: CPU 'sifive-e51' does not allow changing the value of 'mmu' Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:33 +03:00
target/riscv: rework 'priv_spec' 'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We have a precedence for this kind of arrangement in target/ppc/compat.c, ppc_compat_prop_get|set, getters and setters used for the 'max-cpu-compat' class property of the pseries ppc64 machine. We'll do the same with both 'priv_spec' and 'vext_spec'. For 'priv_spec', the validation from riscv_cpu_validate_priv_spec() will be done by the prop_priv_spec_set() setter, while also preventing it to be changed for vendor CPUs. Add two helpers that converts env->priv_ver back and forth to its string representation. These helpers allow us to get a string and set 'env->priv_ver' and return a string giving the current env->priv_ver value. In other words, make the cpu->cfg.priv_spec string obsolete. Last but not the least, move the reworked 'priv_spec' option to riscv_cpu_properties[]. After all said and done, we don't need to store the 'priv_spec' string in the CPU state, and we're now protecting vendor CPUs from priv_ver changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,priv_spec="v1.12.0" qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.priv_spec=v1.12.0: CPU 'sifive-e51' does not allow changing the value of 'priv_spec' Current 'priv_spec' val: v1.10.0 $ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:35 +03:00
{.name = "priv_spec", .info = &prop_priv_spec},
target/riscv: rework 'vext_spec' The same rework did in 'priv_spec' is done for 'vext_spec'. This time is simpler, since we only accept one value ("v1.0") and we'll always have env->vext_ver set to VEXT_VERSION_1_00_0, thus we don't need helpers to convert string to 'vext_ver' back and forth like we needed for 'priv_spec'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:36 +03:00
{.name = "vext_spec", .info = &prop_vext_spec},
target/riscv: rework 'priv_spec' 'priv_spec' and 'vext_spec' are two string options used as a fancy way of setting integers in the CPU state (cpu->env.priv_ver and cpu->env.vext_ver). It requires us to deal with string parsing and to store them in cpu_cfg. We must support these string options, but we don't need to store them. We have a precedence for this kind of arrangement in target/ppc/compat.c, ppc_compat_prop_get|set, getters and setters used for the 'max-cpu-compat' class property of the pseries ppc64 machine. We'll do the same with both 'priv_spec' and 'vext_spec'. For 'priv_spec', the validation from riscv_cpu_validate_priv_spec() will be done by the prop_priv_spec_set() setter, while also preventing it to be changed for vendor CPUs. Add two helpers that converts env->priv_ver back and forth to its string representation. These helpers allow us to get a string and set 'env->priv_ver' and return a string giving the current env->priv_ver value. In other words, make the cpu->cfg.priv_spec string obsolete. Last but not the least, move the reworked 'priv_spec' option to riscv_cpu_properties[]. After all said and done, we don't need to store the 'priv_spec' string in the CPU state, and we're now protecting vendor CPUs from priv_ver changes: $ ./build/qemu-system-riscv64 -M virt -cpu sifive-e51,priv_spec="v1.12.0" qemu-system-riscv64: can't apply global sifive-e51-riscv-cpu.priv_spec=v1.12.0: CPU 'sifive-e51' does not allow changing the value of 'priv_spec' Current 'priv_spec' val: v1.10.0 $ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:35 +03:00
target/riscv: move 'vlen' to riscv_cpu_properties[] Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared with KVM. And, as done with every option we migrated to riscv_cpu_properties[], vendor CPUs can't have their 'vlen' value changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:37 +03:00
{.name = "vlen", .info = &prop_vlen},
target/riscv: move 'elen' to riscv_cpu_properties[] Do the same thing we did with 'vlen' in the previous patch with 'elen'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:38 +03:00
{.name = "elen", .info = &prop_elen},
target/riscv: move 'vlen' to riscv_cpu_properties[] Turning 'vlen' into a class property will allow its default value to be overwritten by cpu_init() later on, solving the issue we have now where CPU specific settings are getting overwritten by the default. Common validation bits are moved from riscv_cpu_validate_v() to prop_vlen_set() to be shared with KVM. And, as done with every option we migrated to riscv_cpu_properties[], vendor CPUs can't have their 'vlen' value changed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Message-ID: <20240105230546.265053-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-06 02:05:37 +03:00
target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[] After adding a KVM finalize() implementation, turn cbom_blocksize into a class property. Follow the same design we used with 'vlen' and 'elen'. The duplicated 'cbom_blocksize' KVM property can be removed from kvm_riscv_add_cpu_user_properties(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:55 +03:00
{.name = "cbom_blocksize", .info = &prop_cbom_blksize},
target/riscv: move 'cbop_blocksize' to riscv_cpu_properties[] Do the same we did with 'cbom_blocksize' in the previous patch. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:56 +03:00
{.name = "cbop_blocksize", .info = &prop_cbop_blksize},
target/riscv: move 'cboz_blocksize' to riscv_cpu_properties[] And remove the now unused kvm_cpu_set_cbomz_blksize() setter. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:57 +03:00
{.name = "cboz_blocksize", .info = &prop_cboz_blksize},
target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[] After adding a KVM finalize() implementation, turn cbom_blocksize into a class property. Follow the same design we used with 'vlen' and 'elen'. The duplicated 'cbom_blocksize' KVM property can be removed from kvm_riscv_add_cpu_user_properties(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:55 +03:00
target/riscv/cpu.c: move 'mvendorid' to riscv_cpu_properties[] Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:59 +03:00
{.name = "mvendorid", .info = &prop_mvendorid},
target/riscv/cpu.c: move 'mimpid' to riscv_cpu_properties[] Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:02:00 +03:00
{.name = "mimpid", .info = &prop_mimpid},
target/riscv/cpu.c: move 'marchid' to riscv_cpu_properties[] Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:02:01 +03:00
{.name = "marchid", .info = &prop_marchid},
target/riscv/cpu.c: move 'mvendorid' to riscv_cpu_properties[] Keep all class properties in riscv_cpu_properties[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> tested-by tags added, rebased with Alistair's riscv-to-apply.next. Message-ID: <20240112140201.127083-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-12 17:01:59 +03:00
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(),
};
target/riscv: add 'rva22u64' CPU This CPU was suggested by Alistair [1] and others during the profile design discussions. It consists of the bare 'rv64i' CPU with rva22u64 enabled by default, like an alias of '-cpu rv64i,rva22u64=true'. Users now have an even easier way of consuming this user-mode profile by doing '-cpu rva22u64'. Extensions can be enabled/disabled at will on top of it. We can boot Linux with this "user-mode" CPU by doing: -cpu rva22u64,sv39=true,s=true,zifencei=true [1] https://lore.kernel.org/qemu-riscv/CAKmqyKP7xzZ9Sx=-Lbx2Ob0qCfB7Z+JO944FQ2TQ+49mqo0q_Q@mail.gmail.com/ 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: <20231218125334.37184-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:26 +03:00
#if defined(TARGET_RISCV64)
static void rva22u64_profile_cpu_init(Object *obj)
{
rv64i_bare_cpu_init(obj);
RVA22U64.enabled = true;
}
target/riscv: add rva22s64 cpu Add a new profile CPU 'rva22s64' to work as an alias of -cpu rv64i,rva22s64 Like the existing rva22u64 CPU already does with the RVA22U64 profile. 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: <20231218125334.37184-27-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:34 +03:00
static void rva22s64_profile_cpu_init(Object *obj)
{
rv64i_bare_cpu_init(obj);
RVA22S64.enabled = true;
}
target/riscv: add 'rva22u64' CPU This CPU was suggested by Alistair [1] and others during the profile design discussions. It consists of the bare 'rv64i' CPU with rva22u64 enabled by default, like an alias of '-cpu rv64i,rva22u64=true'. Users now have an even easier way of consuming this user-mode profile by doing '-cpu rva22u64'. Extensions can be enabled/disabled at will on top of it. We can boot Linux with this "user-mode" CPU by doing: -cpu rva22u64,sv39=true,s=true,zifencei=true [1] https://lore.kernel.org/qemu-riscv/CAKmqyKP7xzZ9Sx=-Lbx2Ob0qCfB7Z+JO944FQ2TQ+49mqo0q_Q@mail.gmail.com/ 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: <20231218125334.37184-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:26 +03:00
#endif
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
}
}
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
static void riscv_cpu_common_class_init(ObjectClass *c, void *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
{
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;
target/riscv: Populate CPUClass.mmu_index Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-01-29 03:34:43 +03:00
cc->mmu_index = riscv_cpu_mmu_index;
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->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;
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: 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
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
static void riscv_cpu_class_init(ObjectClass *c, void *data)
{
RISCVCPUClass *mcc = RISCV_CPU_CLASS(c);
mcc->misa_mxl_max = (uint32_t)(uintptr_t)data;
target/riscv: Validate misa_mxl_max only once misa_mxl_max is now a class member and initialized only once for each class. This also moves the initialization of gdb_core_xml_file which will be referenced before realization in the future. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-3-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:10 +03:00
riscv_cpu_validate_misa_mxl(mcc);
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +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
{
target/riscv/cpu.c: export isa_edata_arr[] This array will be read by the TCG accel class, allowing it to handle priv spec verifications on its own. The array will remain here in cpu.c because it's also used by the riscv,isa string function. To export it we'll finish it with an empty element since ARRAY_SIZE() won't work outside of cpu.c. Get rid of its ARRAY_SIZE() usage now to alleviate the changes for the next patch. 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: <20230925175709.35696-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:57:08 +03:00
const RISCVIsaExtData *edata;
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;
target/riscv/cpu.c: export isa_edata_arr[] This array will be read by the TCG accel class, allowing it to handle priv spec verifications on its own. The array will remain here in cpu.c because it's also used by the riscv,isa string function. To export it we'll finish it with an empty element since ARRAY_SIZE() won't work outside of cpu.c. Get rid of its ARRAY_SIZE() usage now to alleviate the changes for the next patch. 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: <20230925175709.35696-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:57:08 +03:00
for (edata = isa_edata_arr; edata && edata->name; edata++) {
if (isa_ext_is_enabled(cpu, edata->ext_enable_offset)) {
new = g_strconcat(old, "_", edata->name, NULL);
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
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)
{
target/riscv: use misa_mxl_max to populate isa string rather than TARGET_LONG_BITS A cpu may not have the same xlen as the compile time target, and misa_mxl_max is the source of truth for what the hart supports. The conversion from misa_mxl_max to xlen already has one user, so introduce a helper and use that to populate the isa string. Link: https://lore.kernel.org/qemu-riscv/20240108-efa3f83dcd3997dc0af458d7@orel/ Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240124-swear-monthly-56c281f809a6@spud> [ Changes by AF: - Convert to use RISCVCPUClass *mcc ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-24 15:55:49 +03:00
RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
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
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);
target/riscv: use misa_mxl_max to populate isa string rather than TARGET_LONG_BITS A cpu may not have the same xlen as the compile time target, and misa_mxl_max is the source of truth for what the hart supports. The conversion from misa_mxl_max to xlen already has one user, so introduce a helper and use that to populate the isa string. Link: https://lore.kernel.org/qemu-riscv/20240108-efa3f83dcd3997dc0af458d7@orel/ Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240124-swear-monthly-56c281f809a6@spud> [ Changes by AF: - Convert to use RISCVCPUClass *mcc ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-24 15:55:49 +03:00
int xlen = riscv_cpu_max_xlen(mcc);
char *p = isa_str + snprintf(isa_str, maxlen, "rv%d", xlen);
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
}
target/riscv: support new isa extension detection devicetree properties A few months ago I submitted a patch to various lists, deprecating "riscv,isa" with a lengthy commit message [0] that is now commit aeb71e42caae ("dt-bindings: riscv: deprecate riscv,isa") in the Linux kernel tree. Primarily, the goal was to replace "riscv,isa" with a new set of properties that allowed for strictly defining the meaning of various extensions, where "riscv,isa" was tied to whatever definitions inflicted upon us by the ISA manual, which have seen some variance over time. Two new properties were introduced: "riscv,isa-base" and "riscv,isa-extensions". The former is a simple string to communicate the base ISA implemented by a hart and the latter an array of strings used to communicate the set of ISA extensions supported, per the definitions of each substring in extensions.yaml [1]. A beneficial side effect was also the ability to define vendor extensions in a more "official" way, as the ISA manual and other RVI specifications only covered the format for vendor extensions in the ISA string, but not the meaning of vendor extensions, for obvious reasons. Add support for setting these two new properties in the devicetrees for the various devicetree platforms supported by QEMU for RISC-V. The Linux kernel already supports parsing ISA extensions from these new properties, and documenting them in the dt-binding is a requirement for new extension detection being added to the kernel. A side effect of the implementation is that the meaning for elements in "riscv,isa" and in "riscv,isa-extensions" are now tied together as they are constructed from the same source. The same applies to the ISA string provided in ACPI tables, but there does not appear to be any strict definitions of meanings in ACPI land either. Link: https://lore.kernel.org/qemu-riscv/20230702-eats-scorebook-c951f170d29f@spud/ [0] Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/riscv/extensions.yaml [1] Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240124-unvarying-foothold-9dde2aaf95d4@spud> [ Changes by AF: - Rebase on recent changes ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-24 15:55:50 +03:00
#ifndef CONFIG_USER_ONLY
static char **riscv_isa_extensions_list(RISCVCPU *cpu, int *count)
{
int maxlen = ARRAY_SIZE(riscv_single_letter_exts) + ARRAY_SIZE(isa_edata_arr);
char **extensions = g_new(char *, maxlen);
for (int i = 0; i < sizeof(riscv_single_letter_exts) - 1; i++) {
if (cpu->env.misa_ext & RV(riscv_single_letter_exts[i])) {
extensions[*count] = g_new(char, 2);
snprintf(extensions[*count], 2, "%c",
qemu_tolower(riscv_single_letter_exts[i]));
(*count)++;
}
}
for (const RISCVIsaExtData *edata = isa_edata_arr; edata->name; edata++) {
if (isa_ext_is_enabled(cpu, edata->ext_enable_offset)) {
extensions[*count] = g_strdup(edata->name);
(*count)++;
}
}
return extensions;
}
void riscv_isa_write_fdt(RISCVCPU *cpu, void *fdt, char *nodename)
{
RISCVCPUClass *mcc = RISCV_CPU_GET_CLASS(cpu);
const size_t maxlen = sizeof("rv128i");
g_autofree char *isa_base = g_new(char, maxlen);
g_autofree char *riscv_isa;
char **isa_extensions;
int count = 0;
int xlen = riscv_cpu_max_xlen(mcc);
riscv_isa = riscv_isa_string(cpu);
qemu_fdt_setprop_string(fdt, nodename, "riscv,isa", riscv_isa);
snprintf(isa_base, maxlen, "rv%di", xlen);
qemu_fdt_setprop_string(fdt, nodename, "riscv,isa-base", isa_base);
isa_extensions = riscv_isa_extensions_list(cpu, &count);
qemu_fdt_setprop_string_array(fdt, nodename, "riscv,isa-extensions",
isa_extensions, count);
for (int i = 0; i < count; i++) {
g_free(isa_extensions[i]);
}
g_free(isa_extensions);
}
#endif
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
#define DEFINE_CPU(type_name, misa_mxl_max, initfn) \
{ \
.name = (type_name), \
.parent = TYPE_RISCV_CPU, \
.instance_init = (initfn), \
.class_init = riscv_cpu_class_init, \
.class_data = (void *)(misa_mxl_max) \
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
}
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
#define DEFINE_DYNAMIC_CPU(type_name, misa_mxl_max, initfn) \
{ \
.name = (type_name), \
.parent = TYPE_RISCV_DYNAMIC_CPU, \
.instance_init = (initfn), \
.class_init = riscv_cpu_class_init, \
.class_data = (void *)(misa_mxl_max) \
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
}
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
#define DEFINE_VENDOR_CPU(type_name, misa_mxl_max, initfn) \
{ \
.name = (type_name), \
.parent = TYPE_RISCV_VENDOR_CPU, \
.instance_init = (initfn), \
.class_init = riscv_cpu_class_init, \
.class_data = (void *)(misa_mxl_max) \
target/riscv: create TYPE_RISCV_VENDOR_CPU We want to add a new CPU type for bare CPUs that will inherit specific traits of the 2 existing types: - it will allow for extensions to be enabled/disabled, like generic CPUs; - it will NOT inherit defaults, like vendor CPUs. We can make this conditions met by adding an explicit type for the existing vendor CPUs and change the existing logic to not imply that "not generic" means vendor CPUs. Let's add the "vendor" CPU type first. 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: <20231218125334.37184-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:09 +03:00
}
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
#define DEFINE_BARE_CPU(type_name, misa_mxl_max, initfn) \
{ \
.name = (type_name), \
.parent = TYPE_RISCV_BARE_CPU, \
.instance_init = (initfn), \
.class_init = riscv_cpu_class_init, \
.class_data = (void *)(misa_mxl_max) \
target/riscv: add rv64i CPU We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile support, a way to load a multitude of extensions with a single flag. Profile support is going to be implemented shortly, so let's add a CPU for it. The new 'rv64i' CPU will have only RVI loaded. It is inspired in the profile specification that dictates, for RVA22U64 [1]: "RVA22U64 Mandatory Base RV64I is the mandatory base ISA for RVA22U64" And so it seems that RV64I is the mandatory base ISA for all profiles listed in [1], making it an ideal CPU to use with profile support. rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features from pre-existent CPUs: - it allows extensions to be enabled, like generic CPUs; - it will not inherit extension defaults, like vendor CPUs. This is the minimum extension set to boot OpenSBI and buildroot using rv64i: ./build/qemu-system-riscv64 -nographic -M virt \ -cpu rv64i,sv39=true,g=true,c=true,s=true,u=true Our minimal riscv,isa in this case will be: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd# [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc 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: <20231218125334.37184-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:12 +03:00
}
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
#define DEFINE_PROFILE_CPU(type_name, misa_mxl_max, initfn) \
{ \
.name = (type_name), \
.parent = TYPE_RISCV_BARE_CPU, \
.instance_init = (initfn), \
.class_init = riscv_cpu_class_init, \
.class_data = (void *)(misa_mxl_max) \
target/riscv: add 'rva22u64' CPU This CPU was suggested by Alistair [1] and others during the profile design discussions. It consists of the bare 'rv64i' CPU with rva22u64 enabled by default, like an alias of '-cpu rv64i,rva22u64=true'. Users now have an even easier way of consuming this user-mode profile by doing '-cpu rva22u64'. Extensions can be enabled/disabled at will on top of it. We can boot Linux with this "user-mode" CPU by doing: -cpu rva22u64,sv39=true,s=true,zifencei=true [1] https://lore.kernel.org/qemu-riscv/CAKmqyKP7xzZ9Sx=-Lbx2Ob0qCfB7Z+JO944FQ2TQ+49mqo0q_Q@mail.gmail.com/ 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: <20231218125334.37184-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:26 +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 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,
target/riscv/cpu.c: add .instance_post_init() All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU calls riscv_init_max_cpu_extensions(). Both can be moved to a common instance_post_init() callback, implemented in riscv_cpu_post_init(), called by all CPUs. The call order then becomes: riscv_cpu_init() -> cpu_init() of each CPU -> .instance_post_init() In the near future riscv_cpu_post_init() will call the init() function of the current accelerator, providing a hook for KVM and TCG accel classes to change the init() process of the CPU. 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: <20230925175709.35696-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-25 20:56:55 +03:00
.instance_post_init = riscv_cpu_post_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
.abstract = true,
.class_size = sizeof(RISCVCPUClass),
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
.class_init = riscv_cpu_common_class_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
},
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,
},
target/riscv: create TYPE_RISCV_VENDOR_CPU We want to add a new CPU type for bare CPUs that will inherit specific traits of the 2 existing types: - it will allow for extensions to be enabled/disabled, like generic CPUs; - it will NOT inherit defaults, like vendor CPUs. We can make this conditions met by adding an explicit type for the existing vendor CPUs and change the existing logic to not imply that "not generic" means vendor CPUs. Let's add the "vendor" CPU type first. 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: <20231218125334.37184-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:09 +03:00
{
.name = TYPE_RISCV_VENDOR_CPU,
.parent = TYPE_RISCV_CPU,
.abstract = true,
},
target/riscv: add rv64i CPU We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile support, a way to load a multitude of extensions with a single flag. Profile support is going to be implemented shortly, so let's add a CPU for it. The new 'rv64i' CPU will have only RVI loaded. It is inspired in the profile specification that dictates, for RVA22U64 [1]: "RVA22U64 Mandatory Base RV64I is the mandatory base ISA for RVA22U64" And so it seems that RV64I is the mandatory base ISA for all profiles listed in [1], making it an ideal CPU to use with profile support. rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features from pre-existent CPUs: - it allows extensions to be enabled, like generic CPUs; - it will not inherit extension defaults, like vendor CPUs. This is the minimum extension set to boot OpenSBI and buildroot using rv64i: ./build/qemu-system-riscv64 -nographic -M virt \ -cpu rv64i,sv39=true,g=true,c=true,s=true,u=true Our minimal riscv,isa in this case will be: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd# [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc 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: <20231218125334.37184-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:12 +03:00
{
.name = TYPE_RISCV_BARE_CPU,
.parent = TYPE_RISCV_CPU,
target/riscv/cpu.c: add riscv_bare_cpu_init() Next patch will add more bare CPUs. Their cpu_init() functions would be glorified copy/pastes of rv64i_bare_cpu_init(), differing only by a riscv_cpu_set_misa() call. Add a new .instance_init for the TYPE_RISCV_BARE_CPU typ to avoid this code repetition. While we're at it, add a better explanation on why we're disabling the timing extensions for bare CPUs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122123348.973288-2-dbarboza@ventanamicro.com> [ Changes by AF: - Rebase on latest changes ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 15:33:47 +03:00
.instance_init = riscv_bare_cpu_init,
target/riscv: add rv64i CPU We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile support, a way to load a multitude of extensions with a single flag. Profile support is going to be implemented shortly, so let's add a CPU for it. The new 'rv64i' CPU will have only RVI loaded. It is inspired in the profile specification that dictates, for RVA22U64 [1]: "RVA22U64 Mandatory Base RV64I is the mandatory base ISA for RVA22U64" And so it seems that RV64I is the mandatory base ISA for all profiles listed in [1], making it an ideal CPU to use with profile support. rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features from pre-existent CPUs: - it allows extensions to be enabled, like generic CPUs; - it will not inherit extension defaults, like vendor CPUs. This is the minimum extension set to boot OpenSBI and buildroot using rv64i: ./build/qemu-system-riscv64 -nographic -M virt \ -cpu rv64i,sv39=true,g=true,c=true,s=true,u=true Our minimal riscv,isa in this case will be: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd# [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc 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: <20231218125334.37184-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-12-18 15:53:12 +03:00
.abstract = true,
},
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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_MAX, MXL_RV32, riscv_max_cpu_init),
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE32, MXL_RV32, rv32_base_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_IBEX, MXL_RV32, rv32_ibex_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_SIFIVE_E31, MXL_RV32, rv32_sifive_e_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_SIFIVE_E34, MXL_RV32, rv32_imafcu_nommu_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_SIFIVE_U34, MXL_RV32, rv32_sifive_u_cpu_init),
target/riscv: add rv32i, rv32e and rv64e CPUs A bare bones 32 bit RVI CPU, rv32i, will make users lives easier when a full customized 32 bit CPU is desired, and users won't need to disable defaults by hand as they would with the rv32 CPU. [1] has an example of a situation that would be avoided with rv32i. In fact, add bare bones CPUs for RVE as well. Trying to use RVE in QEMU requires one to disable every single default extension, including RVI, and then add the desirable extension set. Adding rv32e/rv64e makes it more pleasant to use embedded CPUs in QEMU. [1] https://lore.kernel.org/qemu-riscv/258be47f-97be-4308-bed5-dc34ef7ff954@Spark/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122123348.973288-3-dbarboza@ventanamicro.com> [ Changes by AF: - Rebase on latest changes ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 15:33:48 +03:00
DEFINE_BARE_CPU(TYPE_RISCV_CPU_RV32I, MXL_RV32, rv32i_bare_cpu_init),
DEFINE_BARE_CPU(TYPE_RISCV_CPU_RV32E, MXL_RV32, rv32e_bare_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: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_MAX, MXL_RV64, riscv_max_cpu_init),
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE64, MXL_RV64, rv64_base_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_SIFIVE_E51, MXL_RV64, rv64_sifive_e_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_SIFIVE_U54, MXL_RV64, rv64_sifive_u_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_SHAKTI_C, MXL_RV64, rv64_sifive_u_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_THEAD_C906, MXL_RV64, rv64_thead_c906_cpu_init),
DEFINE_VENDOR_CPU(TYPE_RISCV_CPU_VEYRON_V1, MXL_RV64, rv64_veyron_v1_cpu_init),
target/riscv: Restrict 'rv128' machine to TCG accelerator We only build for 32/64-bit hosts, so TCG is required for 128-bit targets. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230626232007.8933-5-philmd@linaro.org>
2023-06-26 23:36:10 +03:00
#ifdef CONFIG_TCG
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
DEFINE_DYNAMIC_CPU(TYPE_RISCV_CPU_BASE128, MXL_RV128, rv128_base_cpu_init),
target/riscv: Restrict 'rv128' machine to TCG accelerator We only build for 32/64-bit hosts, so TCG is required for 128-bit targets. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230626232007.8933-5-philmd@linaro.org>
2023-06-26 23:36:10 +03:00
#endif /* CONFIG_TCG */
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
DEFINE_BARE_CPU(TYPE_RISCV_CPU_RV64I, MXL_RV64, rv64i_bare_cpu_init),
target/riscv: add rv32i, rv32e and rv64e CPUs A bare bones 32 bit RVI CPU, rv32i, will make users lives easier when a full customized 32 bit CPU is desired, and users won't need to disable defaults by hand as they would with the rv32 CPU. [1] has an example of a situation that would be avoided with rv32i. In fact, add bare bones CPUs for RVE as well. Trying to use RVE in QEMU requires one to disable every single default extension, including RVI, and then add the desirable extension set. Adding rv32e/rv64e makes it more pleasant to use embedded CPUs in QEMU. [1] https://lore.kernel.org/qemu-riscv/258be47f-97be-4308-bed5-dc34ef7ff954@Spark/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122123348.973288-3-dbarboza@ventanamicro.com> [ Changes by AF: - Rebase on latest changes ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-22 15:33:48 +03:00
DEFINE_BARE_CPU(TYPE_RISCV_CPU_RV64E, MXL_RV64, rv64e_bare_cpu_init),
target/riscv: Move misa_mxl_max to class misa_mxl_max is common for all instances of a RISC-V CPU class so they are better put into class. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-2-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-03 13:11:09 +03:00
DEFINE_PROFILE_CPU(TYPE_RISCV_CPU_RVA22U64, MXL_RV64, rva22u64_profile_cpu_init),
DEFINE_PROFILE_CPU(TYPE_RISCV_CPU_RVA22S64, MXL_RV64, rva22s64_profile_cpu_init),
target/riscv: Restrict 'rv128' machine to TCG accelerator We only build for 32/64-bit hosts, so TCG is required for 128-bit targets. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230626232007.8933-5-philmd@linaro.org>
2023-06-26 23:36:10 +03:00
#endif /* TARGET_RISCV64 */
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_TYPES(riscv_cpu_type_infos)
Reference in New Issue Copy Permalink