aboutsummaryrefslogtreecommitdiff
path: root/target
AgeCommit message (Collapse)Author
2024-02-12Merge tag 'pull-maintainer-updates-090224-1' of ↵Peter Maydell
https://gitlab.com/stsquad/qemu into staging testing, doc and gdbstub updates: - add sqlite3 to openSUSE image - mark CRIS as deprecated - re-enable the TCG plugin tests - use select for semihosting - implement syscall catching in gdbstub # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmXGZtQACgkQ+9DbCVqe # KkTegAgAg7Kkd0Pa2cgkPfNPYR5yT4hYurjVSfi/69cOpj/Vadsav4WWFsuUiQMI # FfKWCNDo5lmNcWIPKgC0oeWVwxal4IhqhO8f9lRIYqg9z4bRkZbdsrvh8J52Q6Xh # Bu9UAEk5KBGrMfEdsAwHnVDg435c7IGdJZnE/iKBK1aKljS5LOiX1J6ZxrqUoMsJ # keTAcdXyvs/BIz68c87AHrW/HKO9KKLgHA2n7T/l2N5KJdoa3p8La9py+v1SGUh8 # 6JlDRYR1H16mITS8tm6ZffPqcOpfHXp7DRquu7obVS5+CVTJ2H9w8TICw56rqMg7 # cVnysNLhdS18cMNKD2Jx3zgd5Nq/cg== # =deHm # -----END PGP SIGNATURE----- # gpg: Signature made Fri 09 Feb 2024 17:54:28 GMT # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * tag 'pull-maintainer-updates-090224-1' of https://gitlab.com/stsquad/qemu: tests/tcg: Add the syscall catchpoint gdbstub test gdbstub: Implement catching syscalls gdbstub: Add syscall entry/return hooks gdbstub: Allow specifying a reason in stop packets gdbstub: Expose TARGET_SIGTRAP in a target-agnostic way kconfig: use "select" to enable semihosting Revert "hw/elf_ops: Ignore loadable segments with zero size" configure: run plugin TCG tests again docs: mark CRIS support as deprecated tests/docker: Add sqlite3 module to openSUSE Leap container Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-02-11target/hppa: PDC_BTLB_INFO uses 32-bit intsHelge Deller
The BTLB helper function stores the BTLB info (four 32-bit ints) into the memory of the guest. They are only available when emulating a 32-bit CPU in the guest, so use "uint32_t" instead of "target_ulong" here. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2024-02-11target/hppa: Allow read-access to PSW with rsm 0,reg instructionHelge Deller
HP-UX 11 and HP ODE tools use the "rsm 0,%reg" instruction in not priviledged code paths to get the current PSW flags. The constant 0 means that no bits of the PSW shall be reset, so this is effectively a read-only access to the PSW. Allow this read-only access even for not privileged code. Signed-off-by: Helge Deller <deller@gmx.de> Acked-by: Richard Henderson <richard.henderson@linaro.org>
2024-02-11target/hppa: Implement do_transaction_failed handler for I/O errorsHelge Deller
Add the do_transaction_failed() handler to tigger a HPMC to the CPU in case of I/O transaction errors. This is a preparation commit. We still lack implementation for some registers, so do not yet enable sending HPMCs. Having this hunk here now nevertheless helps for the further development, so that it can easily be enabled later on. Signed-off-by: Helge Deller <deller@gmx.de>
2024-02-11target/hppa: Add "diag 0x101" for console output supportHelge Deller
For debugging purposes at the early stage of the bootup process, the SeaBIOS-hppa firmware sometimes needs to output characters to the serial console. Note that the serial console is the default output method for parisc machines. At this stage PCI busses and other devices haven't been initialized yet. So, SeaBIOS-hppa will not be able to find the correct I/O ports for the serial ports yet. Instead, add an emulation for the "diag 0x101" opcode to assist here. Without any other dependencies, SeaBIOS-hppa can then load the character to be printed in register %r26 and issue the diag assembly instruction. The qemu diag_console_output() helper function will then print that character to the first serial port. Signed-off-by: Helge Deller <deller@gmx.de> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2024-02-09kconfig: use "select" to enable semihostingPaolo Bonzini
Just like all other dependencies, these can be expressed in Kconfig files rather than in the default configurations. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20240129115809.1039924-1-pbonzini@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240207163812.3231697-10-alex.bennee@linaro.org>
2024-02-09target/riscv: add rv32i, rv32e and rv64e CPUsDaniel Henrique Barboza
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-02-09target/riscv/cpu.c: add riscv_bare_cpu_init()Daniel Henrique Barboza
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-02-09target/riscv: Enable xtheadsync under user modeLIU Zhiwei
According to xtheadsync[1][2] documentation, it can be used in user mode and the behavior is same with other priviledges. [1]:https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadsync/sync.adoc [2]:https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadsync/sync_i.adoc Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240204055228.900-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: support new isa extension detection devicetree propertiesConor Dooley
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-02-09target/riscv: use misa_mxl_max to populate isa string rather than ↵Conor Dooley
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-02-09target/riscv: Expose Zaamo and Zalrsc extensionsRob Bradford
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-02-09target/riscv: Check 'A' and split extensions for atomic instructionsRob Bradford
Following the pattern for 'M' and Zmmul check if either the 'A' extension is enabled or the appropriate split extension for the instruction. Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240123111030.15074-3-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: Add Zaamo and Zalrsc extension infrastructureRob Bradford
These extensions represent the atomic operations from A (Zaamo) and the Load-Reserved/Store-Conditional operations from A (Zalrsc) Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240123111030.15074-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: Use RISCVException as return type for all csr opsLIU Zhiwei
The real return value type has been converted to RISCVException, but some function declarations still not. This patch makes all csr operation declarations use RISCVExcetion. Signed-off-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: <20240130110844.437-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: FCSR doesn't contain vxrm and vxsatLIU Zhiwei
vxrm and vxsat have been moved into a special register vcsr since RVV v1.0. So remove them from FCSR for vector 1.0. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240130110945.486-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: Validate misa_mxl_max only onceAkihiko Odaki
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-09target/riscv: Move misa_mxl_max to classAkihiko Odaki
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-09target/riscv: Remove misa_mxl validationAkihiko Odaki
It is initialized with a simple assignment and there is little room for error. In fact, the validation is even more complex. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240203-riscv-v11-1-a23f4848a628@daynix.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/kvm: get/set vector vregs[]Daniel Henrique Barboza
vregs[] have variable size that depends on the current vlenb set by the host, meaning we can't use our regular kvm_riscv_reg_id() to retrieve it. Create a generic kvm_encode_reg_size_id() helper to encode any given size in bytes into a given kvm reg id. kvm_riscv_vector_reg_id() will use it to encode vlenb into a given vreg ID. kvm_riscv_(get|set)_vector() can then get/set all 32 vregs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240123161714.160149-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/kvm: initialize 'vlenb' via get-reg-listDaniel Henrique Barboza
KVM will check for the correct 'reg_size' when accessing the vector registers, erroring with EINVAL if we encode the wrong size in reg ID. Vector registers varies in size with the vector length in bytes, or 'vlenb'. This means that we need the current 'vlenb' being used by the host, otherwise we won't be able to fetch all vector regs. We'll deal with 'vlenb' first. Its support was added in Linux 6.8 as a get-reg-list register. We'll read 'vlenb' via get-reg-list and mark the register as 'supported'. All 'vlenb' ops via kvm_arch_get_registers() and kvm_arch_put_registers() will only be done if the reg is supported, i.e. we fetched it in get-reg-list during init. If the user sets a new vlenb value using the 'vlen' property, throw an error if the user value differs from the host. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240123161714.160149-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/kvm: change kvm_reg_id to uint64_tDaniel Henrique Barboza
The field isn't big enough to hold an uint64_t kvm register and Vector registers will end up overflowing it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240123161714.160149-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/cpu.c: remove cpu->cfg.vlenDaniel Henrique Barboza
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-02-09trans_rvv.c.inc: use vext_get_vlmax() in trans_vrgather_v*()Daniel Henrique Barboza
Use the helper instead of calculating vlmax by hand. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: change vext_get_vlmax() argumentsDaniel Henrique Barboza
We'll re-use the logic froim vext_get_vlmax() in 2 other occurrences in the next patch, but first we need to make it independent of both 'cpu' and 'vtype'. To do that, add 'vlenb', 'vsew' and 'lmul' as parameters instead. Adapt the two existing callers. In cpu_get_tb_cpu_state(), rename 'sew' to 'vsew' to be less ambiguous about what we're encoding into *pflags. In HELPER(vsetvl) the following changes were made: - add a 'vsew' var to store vsew. Use it in the shift to get 'sew'; - the existing 'lmul' var was renamed to 'vlmul'; - add a new 'lmul' var to store 'lmul' encoded like DisasContext:lmul. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/cpu.h: use 'vlenb' in vext_get_vlmax()Daniel Henrique Barboza
Rename the existing 'sew' variable to 'vsew' for extra clarity. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240122161107.26737-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/insn_trans/trans_rvv.c.inc: use 'vlenb' in MAXSZ()Daniel Henrique Barboza
Calculate the maximum vector size possible, 'max_sz', which is the size in bytes 'vlenb' multiplied by the max value of LMUL (LMUL = 8, when s->lmul = 3). 'max_sz' is then shifted right by 'scale', expressed as '3 - s->lmul', which is clearer than doing 'scale = lmul - 3' and then using '-scale' in the shift right. 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-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/vector_helper.c: use vlenb in HELPER(vsetvl)Daniel Henrique Barboza
Use the new 'vlenb' CPU config to validate fractional LMUL. The original comparison is done with 'vlen' and 'sew', both in bits. Adjust the shift to use vlenb. 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-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/vector_helper.c: use 'vlenb'Daniel Henrique Barboza
Use 'cpu->cfg.vlenb' instead of 'cpu->cfg.vlen >> 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-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/insn_trans/trans_rvvk.c.inc: use 'vlenb'Daniel Henrique Barboza
Use s->cfg_ptr->vlenb instead of s->cfg_ptr->vlen / 8. 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-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/insn_trans/trans_rvv.c.inc: use 'vlenb'Daniel Henrique Barboza
Use s->cfg_ptr->vlenb instead of "s->cfg_ptr->vlen / 8" and "s->cfg_ptr->vlen >> 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-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/insn_trans/trans_rvbf16.c.inc: use cpu->cfg.vlenbDaniel Henrique Barboza
Use ctx->cfg_ptr->vlenb instead of ctx->cfg_ptr->vlen / 8. 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-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/gdbstub.c: use 'vlenb' instead of shifting 'vlen'Daniel Henrique Barboza
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-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/csr.c: use 'vlenb' instead of 'vlen'Daniel Henrique Barboza
As a bonus, we're being more idiomatic using cpu->cfg.vlenb when reading CSR_VLENB. 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-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: add 'vlenb' field in cpu->cfgDaniel Henrique Barboza
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-02-09target/riscv: Implement optional CSR mcontext of debug Sdtrig extensionAlvin Chang
The debug Sdtrig extension defines an CSR "mcontext". This commit implements its predicate and read/write operations into CSR table. Its value is reset as 0 when the trigger module is reset. Signed-off-by: Alvin Chang <alvinga@andestech.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231219123244.290935-1-alvinga@andestech.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv/cpu.c: move 'marchid' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv/cpu.c: move 'mimpid' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv/cpu.c: move 'mvendorid' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv: remove riscv_cpu_options[]Daniel Henrique Barboza
The array is empty and can be removed. 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-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-09target/riscv: move 'cboz_blocksize' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv: move 'cbop_blocksize' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv: move 'cbom_blocksize' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv: create finalize_features() for KVMDaniel Henrique Barboza
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-02-09target/riscv: move 'elen' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv: move 'vlen' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv: rework 'vext_spec'Daniel Henrique Barboza
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-02-09target/riscv: rework 'priv_spec'Daniel Henrique Barboza
'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-02-09target/riscv: move 'pmp' to riscv_cpu_properties[]Daniel Henrique Barboza
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-02-09target/riscv: move 'mmu' to riscv_cpu_properties[]Daniel Henrique Barboza
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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-15 10:44:49 +0000