aboutsummaryrefslogtreecommitdiff
path: root/target/riscv
AgeCommit message (Collapse)Author
2024-03-22target/riscv/vector_helper.c: optimize loops in ldst helpersDaniel Henrique Barboza
Change the for loops in ldst helpers to do a single increment in the counter, and assign it env->vstart, to avoid re-reading from vstart every time. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22target/riscv: enable 'vstart_eq_zero' in the end of insnsIvan Klokov
The vstart_eq_zero flag is updated at the beginning of the translation phase from the env->vstart variable. During the execution phase all functions will set env->vstart = 0 after a successful execution, but the vstart_eq_zero flag remains the same as at the start of the block. This will wrongly cause SIGILLs in translations that requires env->vstart = 0 and might be reading vstart_eq_zero = false. This patch adds a new finalize_rvv_inst() helper that is called at the end of each vector instruction that will both update vstart_eq_zero and do a mark_vs_dirty(). Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1976 Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> 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: <20240314175704.478276-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22trans_rvv.c.inc: remove redundant mark_vs_dirty() callsDaniel Henrique Barboza
trans_vmv_v_i , trans_vfmv_v_f and the trans_##NAME macro from GEN_VMV_WHOLE_TRANS() are calling mark_vs_dirty() in both branches of their 'ifs'. conditionals. Call it just once in the end like other functions are doing. 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> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20240314175704.478276-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22target/riscv: remove 'over' brconds from vector transDaniel Henrique Barboza
All helpers that rely on vstart >= vl are now doing early exits using the VSTART_CHECK_EARLY_EXIT() macro. This macro will not only exit the helper but also clear vstart. We're still left with brconds that are skipping the helper, which is the only place where we're clearing vstart. The pattern goes like this: tcg_gen_brcond_tl(TCG_COND_GEU, cpu_vstart, cpu_vl, over); (... calls helper that clears vstart ...) gen_set_label(over); return true; This means that every time we jump to 'over' we're not clearing vstart, which is an oversight that we're doing across the board. Instead of setting vstart = 0 manually after each 'over' jump, remove those brconds that are skipping helpers. The exception will be trans_vmv_s_x() and trans_vfmv_s_f(): they don't use a helper and are already clearing vstart manually in the 'over' label. While we're at it, remove the (vl == 0) brconds from trans_rvbf16.c.inc too since they're unneeded. Suggested-by: Richard Henderson <richard.henderson@linaro.org> 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: <20240314175704.478276-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22target/riscv/vector_helpers: do early exit when vstart >= vlDaniel Henrique Barboza
We're going to make changes that will required each helper to be responsible for the 'vstart' management, i.e. we will relieve the 'vstart < vl' assumption that helpers have today. Helpers are usually able to deal with vstart >= vl, i.e. doing nothing aside from setting vstart = 0 at the end, but the tail update functions will update the tail regardless of vstart being valid or not. Unifying the tail update process in a single function that would handle the vstart >= vl case isn't trivial (see [1] for more info). This patch takes a blunt approach: do an early exit in every single vector helper if vstart >= vl, unless the helper is guarded with vstart_eq_zero in the translation. For those cases the helper is ready to deal with cases where vl might be zero, i.e. throwing exceptions based on it like vcpop_m() and first_m(). Helpers that weren't changed: - vcpop_m(), vfirst_m(), vmsetm(), GEN_VEXT_VIOTA_M(): these are guarded directly with vstart_eq_zero; - GEN_VEXT_VCOMPRESS_VM(): guarded with vcompress_vm_check() that checks vstart_eq_zero; - GEN_VEXT_RED(): guarded with either reduction_check() or reduction_widen_check(), both check vstart_eq_zero; - GEN_VEXT_FRED(): guarded with either freduction_check() or freduction_widen_check(), both check vstart_eq_zero. Another exception is vext_ldst_whole(), who operates on effective vector length regardless of the current settings in vtype and vl. [1] https://lore.kernel.org/qemu-riscv/1590234b-0291-432a-a0fa-c5a6876097bc@linux.alibaba.com/ Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240314175704.478276-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22target/riscv: always clear vstart for ldst_whole insnsDaniel Henrique Barboza
Commit 8ff8ac6329 added a conditional to guard the vext_ldst_whole() helper if vstart >= evl. But by skipping the helper we're also not setting vstart = 0 at the end of the insns, which is incorrect. We'll move the conditional to vext_ldst_whole(), following in line with the removal of all brconds vstart >= vl that the next patch will do. The idea is to make the helpers responsible for their own vstart management. Fix ldst_whole isns by: - remove the brcond that skips the helper if vstart is >= evl; - vext_ldst_whole() now does an early exit with the same check, where evl = (vlenb * nf) >> log2_esz, but the early exit will also clear vstart. The 'width' param is now unneeded in ldst_whole_trans() and is also removed. It was used for the evl calculation for the brcond and has no other use now. The 'width' is reflected in vext_ldst_whole() via log2_esz, which is encoded by GEN_VEXT_LD_WHOLE() as "ctzl(sizeof(ETYPE))". Suggested-by: Max Chou <max.chou@sifive.com> Fixes: 8ff8ac6329 ("target/riscv: rvv: Add missing early exit condition for whole register load/store") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Max Chou <max.chou@sifive.com> Message-ID: <20240314175704.478276-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22target/riscv: always clear vstart in whole vec move insnsDaniel Henrique Barboza
These insns have 2 paths: we'll either have vstart already cleared if vstart_eq_zero or we'll do a brcond to check if vstart >= maxsz to call the 'vmvr_v' helper. The helper will clear vstart if it executes until the end, or if vstart >= vl. For starters, the check itself is wrong: we're checking vstart >= maxsz, when in fact we should use vstart in bytes, or 'startb' like 'vmvr_v' is calling, to do the comparison. But even after fixing the comparison we'll still need to clear vstart in the end, which isn't happening too. We want to make the helpers responsible to manage vstart, including these corner cases, precisely to avoid these situations: - remove the wrong vstart >= maxsz cond from the translation; - add a 'startb >= maxsz' cond in 'vmvr_v', and clear vstart if that happens. This way we're now sure that vstart is being cleared in the end of the execution, regardless of the path taken. Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR") 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> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22target/riscv/vector_helper.c: fix 'vmvr_v' memcpy endianessDaniel Henrique Barboza
vmvr_v isn't handling the case where the host might be big endian and the bytes to be copied aren't sequential. Suggested-by: Richard Henderson <richard.henderson@linaro.org> Fixes: f714361ed7 ("target/riscv: rvv-1.0: implement vstart CSR") 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> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240314175704.478276-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22trans_rvv.c.inc: set vstart = 0 in int scalar move insnsDaniel Henrique Barboza
trans_vmv_x_s, trans_vmv_s_x, trans_vfmv_f_s and trans_vfmv_s_f aren't setting vstart = 0 after execution. This is usually done by a helper in vector_helper.c but these functions don't use helpers. We'll set vstart after any potential 'over' brconds, and that will also mandate a mark_vs_dirty() too. Fixes: dedc53cbc9 ("target/riscv: rvv-1.0: integer scalar move instructions") 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: <20240314175704.478276-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22target/riscv/vector_helper.c: set vstart = 0 in GEN_VEXT_VSLIDEUP_VX()Daniel Henrique Barboza
The helper isn't setting env->vstart = 0 after its execution, as it is expected from every vector instruction that completes successfully. 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> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20240314175704.478276-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-22target/riscv: do not enable all named features by defaultDaniel Henrique Barboza
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-12Merge tag 'pull-error-2024-03-12' of https://repo.or.cz/qemu/armbru into stagingPeter Maydell
Error reporting patches for 2024-03-12 # -----BEGIN PGP SIGNATURE----- # # iQJGBAABCAAwFiEENUvIs9frKmtoZ05fOHC0AOuRhlMFAmXwWOYSHGFybWJydUBy # ZWRoYXQuY29tAAoJEDhwtADrkYZT+voP/jAEyPfbtwggKLHjSCkHchn/uUziLJ2o # //i7+ZV9soCizAEkW+AkIR17PsMCaRsa8W4AULLn+ZaDJNy1Vlj2WYIkgeFm/rba # AWfNXywIg7dLnj0Hd98nz13hPuP52hO9vpakPhcua9L6mmk1htdqbbGIFIIfbQhp # e6FM+sBEW44uGcZx+N0wMEpKF0F7RId/jzH4mfP35WE7CLaAr2EfTXFaadAM636e # QsrM8wuiNAPQeyXz14gxYTWAnnMGglM5WQ4hoxSGN0y8c007gvff5vMKc7vapn4/ # DdiYJqpq/DIWaiGL0Fl8Cpry3WrQ8UY0st745kCLF/f9nlL0GvnBGdLdUaap7lQZ # A/C1sDKNubAGwzcw643AhV73QHc9f5kDBdWIj5wj3k5DQmBmgKACzGs1edDVVB+2 # OaStqZZ/V9Q5gljjh6PiHEptTjPhsaftX7GGjbhXTJUDFB9GONSCEVwAdZZxJ0Pm # 6cQLtcIMtcjL4xXNz6niVZkxGT/zu4kqbZ01LudIqEQAnULwRiVpyjkCmReSAOPP # eBtkCQtn7WPlz4N3ZiV2+a1p4/e88KH9wvxF+XvPEJjgsdeUmxX44f82ouLPJzvE # fOXE11tRr41u9m+UmoinVo581CKYGlkRJlNQWQwFOmnXoKP2nPZzADxraihkCR5p # wT0Hz9uwJs94 # =6FSf # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 13:30:14 GMT # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * tag 'pull-error-2024-03-12' of https://repo.or.cz/qemu/armbru: target/loongarch: Fix query-cpu-model-expansion to reject props target: Improve error reporting for CpuModelInfo member @props target/i386: Fix query-cpu-model-expansion to reject props target: Simplify type checks for CpuModelInfo member @props Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-12Merge tag 'pull-request-2024-03-12' of https://gitlab.com/thuth/qemu into ↵Peter Maydell
staging * Add missing ERRP_GUARD() statements in functions that need it * Prefer fast cpu_env() over slower CPU QOM cast macro # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmXwPhYRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbWHvBAAgKx5LHFjz3xREVA+LkDTQ49mz0lK3s32 # SGvNlIHjiaDGVttVYhVC4sinBWUruG4Lyv/2QN72OJBzn6WUsEUQE3KPH1d7Y3/s # wS9X7mj70n4kugWJqeIJP5AXSRasHmWoQ4QJLVQRJd6+Eb9jqwep0x7bYkI1de6D # bL1Q7bIfkFeNQBXaiPWAm2i+hqmT4C1r8HEAGZIjAsMFrjy/hzBEjNV+pnh6ZSq9 # Vp8BsPWRfLU2XHm4WX0o8d89WUMAfUGbVkddEl/XjIHDrUD+Zbd1HAhLyfhsmrnE # jXIwSzm+ML1KX4MoF5ilGtg8Oo0gQDEBy9/xck6G0HCm9lIoLKlgTxK9glr2vdT8 # yxZmrM9Hder7F9hKKxmb127xgU6AmL7rYmVqsoQMNAq22D6Xr4UDpgFRXNk2/wO6 # zZZBkfZ4H4MpZXbd/KJpXvYH5mQA4IpkOy8LJdE+dbcHX7Szy9ksZdPA+Z10hqqf # zqS13qTs3abxymy2Q/tO3hPKSJCk1+vCGUkN60Wm+9VoLWGoU43qMc7gnY/pCS7m # 0rFKtvfwFHhokX1orK0lP/ppVzPv/5oFIeK8YDY9if+N+dU2LCwVZHIuf2/VJPRq # wmgH2vAn3JDoRKPxTGX9ly6AMxuZaeP92qBTOPap0gDhihYzIpaCq9ecEBoTakI7 # tdFhV0iRr08= # =NiP4 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 12 Mar 2024 11:35:50 GMT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2024-03-12' of https://gitlab.com/thuth/qemu: (55 commits) user: Prefer fast cpu_env() over slower CPU QOM cast macro target/xtensa: Prefer fast cpu_env() over slower CPU QOM cast macro target/tricore: Prefer fast cpu_env() over slower CPU QOM cast macro target/sparc: Prefer fast cpu_env() over slower CPU QOM cast macro target/sh4: Prefer fast cpu_env() over slower CPU QOM cast macro target/rx: Prefer fast cpu_env() over slower CPU QOM cast macro target/ppc: Prefer fast cpu_env() over slower CPU QOM cast macro target/openrisc: Prefer fast cpu_env() over slower CPU QOM cast macro target/nios2: Prefer fast cpu_env() over slower CPU QOM cast macro target/mips: Prefer fast cpu_env() over slower CPU QOM cast macro target/microblaze: Prefer fast cpu_env() over slower CPU QOM cast macro target/m68k: Prefer fast cpu_env() over slower CPU QOM cast macro target/loongarch: Prefer fast cpu_env() over slower CPU QOM cast macro target/i386/hvf: Use CPUState typedef target/hexagon: Prefer fast cpu_env() over slower CPU QOM cast macro target/cris: Prefer fast cpu_env() over slower CPU QOM cast macro target/avr: Prefer fast cpu_env() over slower CPU QOM cast macro target/alpha: Prefer fast cpu_env() over slower CPU QOM cast macro target: Replace CPU_GET_CLASS(cpu -> obj) in cpu_reset_hold() handler bulk: Call in place single use cpu_env() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-03-12target: Improve error reporting for CpuModelInfo member @propsMarkus Armbruster
query-cpu-model-comparison, query-cpu-model-baseline, and query-cpu-model-expansion take CpuModelInfo arguments. Errors in @props members of these arguments are reported for 'props', without further context. For instance, s390x rejects {"execute": "query-cpu-model-comparison", "arguments": {"modela": {"name": "z13", "props": {}}, "modelb": {"name": "z14", "props": []}}} with {"error": {"class": "GenericError", "desc": "Invalid parameter type for 'props', expected: object"}} This is unusual; the common QAPI unmarshaling machinery would complain about 'modelb.props'. Our hand-written code to visit the @props member neglects to provide the context. Tweak it so it provides it. The command above now fails with {"error": {"class": "GenericError", "desc": "Invalid parameter type for 'modelb.props', expected: dict"}} Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20240305145919.2186971-4-armbru@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
2024-03-12target: Simplify type checks for CpuModelInfo member @propsMarkus Armbruster
CpuModelInfo member @props is semantically a mapping from name to value, and syntactically a JSON object on the wire. This translates to QDict in C. Since the QAPI schema language lacks the means to express 'object', we use 'any' instead. This is QObject in C. Commands taking a CpuModelInfo argument need to check the QObject is a QDict. For arm, riscv, and s390x, the code checks right before passing the QObject to visit_start_struct(). visit_start_struct() then checks again. Delete the first check. The error message for @props that are not an object changes slightly to the the message we get for this kind of type error in other contexts. Minor improvement. Additionally, error messages about members of @props now refer to 'props.prop-name' instead of just 'prop-name'. Another minor improvement. Both changes are visible in tests/qtest/arm-cpu-features.c. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-ID: <20240305145919.2186971-2-armbru@redhat.com> Acked-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> [Drop #include now superfluous]
2024-03-12target: Replace CPU_GET_CLASS(cpu -> obj) in cpu_reset_hold() handlerPhilippe Mathieu-Daudé
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-03-11migration: export migration_is_runningSteve Sistare
Delete the MigrationState parameter from migration_is_running and move it to the public API in misc.h. Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Link: https://lore.kernel.org/r/1710179338-294359-5-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu <peterx@redhat.com>
2024-03-08target/riscv: Fix privilege mode of G-stage translation for debuggingHiroaki Yamamoto
G-stage translation should be considered to be user-level access in riscv_cpu_get_phys_page_debug(), as already done in riscv_cpu_tlb_fill(). This fixes a bug that prevents gdb from reading memory while the VM is running in VS-mode. Signed-off-by: Hiroaki Yamamoto <hrak1529@gmail.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240228081028.35081-1-hrak1529@gmail.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: Fix shift count overflowdemin.han
The result of (8 - 3 - vlmul) is negative when vlmul >= 6, and results in wrong vill. Signed-off-by: demin.han <demin.han@starfivetech.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20240225174114.5298-1-demin.han@starfivetech.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08trans_rvv.c.inc: remove 'is_store' bool from load/store fnsDaniel Henrique Barboza
After the 'mark_vs_dirty' changes from the previous patch the 'is_store' bool is unused in some load/store functions that were changed. Remove it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240306171932.549549-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08trans_rvv.c.inc: mark_vs_dirty() before loads and storesDaniel Henrique Barboza
While discussing a problem with how we're (not) setting vstart_eq_zero Richard had the following to say w.r.t the conditional mark_vs_dirty() calls on load/store functions [1]: "I think it's required to have stores set dirty unconditionally, before the operation. Consider a store that traps on the 2nd element, leaving vstart = 2, and exiting to the main loop via exception. The exception enters the kernel page fault handler. The kernel may need to fault in the page for the process, and in the meantime task switch. If vs dirty is not already set, the kernel won't know to save vector state on task switch." Do a mark_vs_dirty() before both loads and stores. [1] https://lore.kernel.org/qemu-riscv/72c7503b-0f43-44b8-aa82-fbafed2aac0c@linaro.org/ Suggested-by: Richard Henderson <richard.henderson@linaro.org> 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: <20240306171932.549549-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: mcountinhibit, mcounteren, scounteren, hcounteren is 32-bitVadim Shakirov
mcountinhibit, mcounteren, scounteren and hcounteren must always be 32-bit by privileged spec Signed-off-by: Vadim Shakirov <vadim.shakirov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20240202113919.18236-1-vadim.shakirov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: move ratified/frozen exts to non-experimentalDaniel Henrique Barboza
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-08target/riscv/kvm: update KVM exts to Linux 6.8Daniel Henrique Barboza
The last KVM extensions added were back in 6.6. Sync them to Linux 6.8. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240304134732.386590-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08RISC-V: Add support for ZtsoPalmer Dabbelt
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-03-08target/riscv: Add missing include guard in pmu.hFrank Chang
Add missing include guard in pmu.h to avoid the problem of double inclusion. Signed-off-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240220110907.10479-1-frank.chang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: UPDATE xATP write CSRIrina Ryapolova
Added xATP_MODE validation for vsatp/hgatp CSRs. The xATP register is an SXLEN-bit read/write WARL register, so the legal value must be returned (See riscv-privileged-20211203, SATP/VSATP/HGATP CSRs). Signed-off-by: Irina Ryapolova <irina.ryapolova@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240109145923.37893-2-irina.ryapolova@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: FIX xATP_MODE validationIrina Ryapolova
The SATP register is an SXLEN-bit read/write WARL register. It means that CSR fields are only defined for a subset of bit encodings, but allow any value to be written while guaranteeing to return a legal value whenever read (See riscv-privileged-20211203, SATP CSR). For example on rv64 we are trying to write to SATP CSR val = 0x1000000000000000 (SATP_MODE = 1 - Reserved for standard use) and after that we are trying to read SATP_CSR. We read from the SATP CSR value = 0x1000000000000000, which is not a correct operation (return illegal value). Signed-off-by: Irina Ryapolova <irina.ryapolova@syntacore.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240109145923.37893-1-irina.ryapolova@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: Promote svade to a normal extensionAndrew Jones
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-03-08target/riscv: Gate hardware A/D PTE bit updatingAndrew Jones
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-03-08target/riscv: Reset henvcfg to zeroAndrew Jones
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-03-08target/riscv: add remaining named featuresDaniel Henrique Barboza
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-03-08target/riscv: add riscv,isa to named featuresDaniel Henrique Barboza
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-03-08target/riscv/tcg: set 'mmu' with 'satp' in cpu_set_profile()Daniel Henrique Barboza
Recent changes in options handling removed the 'mmu' default the bare CPUs had, meaning that we must enable 'mmu' by hand when using the rva22s64 profile CPU. Given that this profile is setting a satp mode, it already implies that we need a 'mmu'. Enable the 'mmu' in this case. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20240215223955.969568-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-03-08target/riscv: Update $ra with current $pc in trans_cm_jalt()Jason Chien
The original implementation sets $pc to the address read from the jump vector table first and links $ra with the address of the next instruction after the updated $pc. After jumping to the updated $pc and executing the next ret instruction, the program jumps to $ra, which is in the same function currently executing, which results in an infinite loop. This commit stores the jump address in a temporary, updates $ra with the current $pc, and copies the temporary to $pc. Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20240207081820.28559-1-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-02-28gdbstub: Add members to identify registers to GDBFeatureAkihiko Odaki
These members will be used to help plugins to identify registers. The added members in instances of GDBFeature dynamically generated by CPUs will be filled in later changes. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20231213-gdb-v17-10-777047380591@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-15-alex.bennee@linaro.org>
2024-02-28hw/core/cpu: Remove gdb_get_dynamic_xml memberAkihiko Odaki
This function is no longer used. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231213-gdb-v17-9-777047380591@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-14-alex.bennee@linaro.org>
2024-02-28gdbstub: Infer number of core registers from XMLAkihiko Odaki
GDBFeature has the num_regs member so use it where applicable to remove magic numbers. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20231213-gdb-v17-8-777047380591@daynix.com> [AJB: remove core reg check from microblaze read reg] Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-13-alex.bennee@linaro.org>
2024-02-28gdbstub: Change gdb_get_reg_cb and gdb_set_reg_cbAkihiko Odaki
Align the parameters of gdb_get_reg_cb and gdb_set_reg_cb with the gdb_read_register and gdb_write_register members of CPUClass to allow to unify the logic to access registers of the core and coprocessors in the future. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231213-gdb-v17-6-777047380591@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-11-alex.bennee@linaro.org>
2024-02-28gdbstub: Use GDBFeature for gdb_register_coprocessorAkihiko Odaki
This is a tree-wide change to introduce GDBFeature parameter to gdb_register_coprocessor(). The new parameter just replaces num_regs and xml parameters for now. GDBFeature will be utilized to simplify XML lookup in a following change. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Acked-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231213-gdb-v17-4-777047380591@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-9-alex.bennee@linaro.org>
2024-02-28target/riscv: Use GDBFeature for dynamic XMLAkihiko Odaki
In preparation for a change to use GDBFeature as a parameter of gdb_register_coprocessor(), convert the internal representation of dynamic feature from plain XML to GDBFeature. Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20231213-gdb-v17-3-777047380591@daynix.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240227144335.1196131-8-alex.bennee@linaro.org>
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-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>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-18 15:46:03 +0000