aboutsummaryrefslogtreecommitdiff
path: root/target/riscv
AgeCommit message (Collapse)Author
2023-09-11target/riscv: Use existing lookup tables for MixColumnsArd Biesheuvel
The AES MixColumns and InvMixColumns operations are relatively expensive 4x4 matrix multiplications in GF(2^8), which is why C implementations usually rely on precomputed lookup tables rather than performing the calculations on demand. Given that we already carry those tables in QEMU, we can just grab the right value in the implementation of the RISC-V AES32 instructions. Note that the tables in question are permuted according to the respective Sbox, so we can omit the Sbox lookup as well in this case. Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Cc: Zewen Ye <lustrew@foxmail.com> Cc: Weiwei Li <liweiwei@iscas.ac.cn> Cc: Junqiang Wang <wangjunqiang@iscas.ac.cn> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20230731084043.1791984-1-ardb@kernel.org> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv: Fix page_check_range use in fault-only-firstLIU Zhiwei
Commit bef6f008b98(accel/tcg: Return bool from page_check_range) converts integer return value to bool type. However, it wrongly converted the use of the API in riscv fault-only-first, where page_check_range < = 0, should be converted to !page_check_range. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20230729031618.821-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv/cpu.c: add smepmp isa stringDaniel Henrique Barboza
The cpu->cfg.epmp extension is still experimental, but it already has a 'smepmp' riscv,isa string. Add it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230720132424.371132-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-11target/riscv/cpu.c: add zmmul isa stringDaniel Henrique Barboza
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-09-11target/riscv/cpu.c: do not run 'host' CPU with TCGDaniel Henrique Barboza
The 'host' CPU is available in a CONFIG_KVM build and it's currently available for all accels, but is a KVM only CPU. This means that in a RISC-V KVM capable host we can do things like this: $ ./build/qemu-system-riscv64 -M virt,accel=tcg -cpu host --nographic qemu-system-riscv64: H extension requires priv spec 1.12.0 This CPU does not have a priv spec because we don't filter its extensions via priv spec. We shouldn't be reaching riscv_cpu_realize_tcg() at all with the 'host' CPU. We don't have a way to filter the 'host' CPU out of the available CPU options (-cpu help) if the build includes both KVM and TCG. What we can do is to error out during riscv_cpu_realize_tcg() if the user chooses the 'host' CPU with accel=tcg: $ ./build/qemu-system-riscv64 -M virt,accel=tcg -cpu host --nographic qemu-system-riscv64: 'host' CPU is not compatible with TCG acceleration Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230721133411.474105-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-09-08riscv: spelling fixesMichael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Acked-by: Alistair Francis <alistair.francis@wdc.com>
2023-08-31target/helpers: Remove unnecessary 'qemu/main-loop.h' headerPhilippe Mathieu-Daudé
"qemu/main-loop.h" declares functions related to QEMU's main loop mutex, which these files don't access. Remove the unused "qemu/main-loop.h" header. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230828221314.18435-8-philmd@linaro.org>
2023-08-31target/helpers: Remove unnecessary 'exec/cpu_ldst.h' headerPhilippe Mathieu-Daudé
These files don't use the CPU ld/st API, remove the unnecessary "exec/cpu_ldst.h" header. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230828221314.18435-7-philmd@linaro.org>
2023-08-31target/translate: Include missing 'exec/cpu_ldst.h' headerPhilippe Mathieu-Daudé
All these files access the CPU LD/ST API declared in "exec/cpu_ldst.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230828221314.18435-4-philmd@linaro.org>
2023-08-31target/riscv/pmu: Restrict 'qemu/log.h' include to sourcePhilippe Mathieu-Daudé
Declarations from "riscv/pmu.h" don't need anything from "qemu/log.h", reduce it's inclusion to the source. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230828221314.18435-3-philmd@linaro.org>
2023-08-24include/exec: Replace target_ulong with abi_ptr in cpu_[st|ld]*()Anton Johansson
Changes the address type of the guest memory read/write functions from target_ulong to abi_ptr. (abi_ptr is currently typedef'd to target_ulong but that will change in a following commit.) This will reduce the coupling between accel/ and target/. Note: Function pointers that point to cpu_[st|ld]*() in target/riscv and target/rx are also updated in this commit. Signed-off-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230807155706.9580-6-anjo@rev.ng> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2023-08-22kvm: Introduce kvm_arch_get_default_type hookAkihiko Odaki
kvm_arch_get_default_type() returns the default KVM type. This hook is particularly useful to derive a KVM type that is valid for "none" machine model, which is used by libvirt to probe the availability of KVM. For MIPS, the existing mips_kvm_type() is reused. This function ensures the availability of VZ which is mandatory to use KVM on the current QEMU. Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20230727073134.134102-2-akihiko.odaki@daynix.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added doc comment for new function] Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-08-11target/riscv/kvm.c: fix mvendorid size in vcpu_set_machine_ids()Daniel Henrique Barboza
cpu->cfg.mvendorid is a 32 bit field and kvm_set_one_reg() always write a target_ulong val, i.e. a 64 bit field in a 64 bit host. Given that we're passing a pointer to the mvendorid field, the reg is reading 64 bits starting from mvendorid and going 32 bits in the next field, marchid. Here's an example: $ ./qemu-system-riscv64 -machine virt,accel=kvm -m 2G -smp 1 \ -cpu rv64,marchid=0xab,mvendorid=0xcd,mimpid=0xef(...) (inside the guest) # cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc_zicbom_zicboz_zihintpause_zbb_sstc mmu : sv57 mvendorid : 0xab000000cd marchid : 0xab mimpid : 0xef 'mvendorid' was written as a combination of 0xab (the value from the adjacent field, marchid) and its intended value 0xcd. Fix it by assigning cpu->cfg.mvendorid to a target_ulong var 'reg' and use it as input for kvm_set_one_reg(). Here's the result with this patch applied and using the same QEMU command line: # cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdc_zicbom_zicboz_zihintpause_zbb_sstc mmu : sv57 mvendorid : 0xcd marchid : 0xab mimpid : 0xef This bug affects only the generic (rv64) CPUs when running with KVM in a 64 bit env since the 'host' CPU does not allow the machine IDs to be changed via command line. Fixes: 1fb5a622f7 ("target/riscv: handle mvendorid/marchid/mimpid for KVM CPUs") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230802180058.281385-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-19target/riscv: Fix LMUL check to use VLENRob Bradford
The previous check was failing with: VLEN=128 ELEN = 64 SEW = 16 and LMUL = 1/8 which is a valid combination. Fix the check to allow valid combinations when VLEN is a multiple of ELEN. From the specification: "In general, the requirement is to support LMUL ≥ SEWMIN/ELEN, where SEWMIN is the narrowest supported SEW value and ELEN is the widest supported SEW value. In the standard extensions, SEWMIN=8. For standard vector extensions with ELEN=32, fractional LMULs of 1/2 and 1/4 must be supported. For standard vector extensions with ELEN=64, fractional LMULs of 1/2, 1/4, and 1/8 must be supported." Elsewhere in the specification it makes clear that VLEN>=ELEN. From inspection this new check allows: VLEN=ELEN=64 1/2, 1/4, 1/8 for SEW >=8 VLEN=ELEN=32 1/2, 1/4 for SEW >=8 Fixes: d9b7609a1fb2 ("target/riscv: rvv-1.0: configure instructions") Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Message-Id: <20230718131316.12283-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-19target/riscv/cpu.c: check priv_ver before auto-enable zca/zcd/zcfDaniel Henrique Barboza
Commit bd30559568 made changes in how we're checking and disabling extensions based on env->priv_ver. One of the changes was to move the extension disablement code to the end of realize(), being able to disable extensions after we've auto-enabled some of them. An unfortunate side effect of this change started to happen with CPUs that has an older priv version, like sifive-u54. Starting on commit 2288a5ce43e5 we're auto-enabling zca, zcd and zcf if RVC is enabled, but these extensions are priv version 1.12.0. When running a cpu that has an older priv ver (like sifive-u54) the user is spammed with warnings like these: qemu-system-riscv64: warning: disabling zca extension for hart 0x0000000000000000 because privilege spec version does not match qemu-system-riscv64: warning: disabling zcd extension for hart 0x0000000000000000 because privilege spec version does not match The warnings are part of the code that disables the extension, but in this case we're throwing user warnings for stuff that we enabled on our own, without user intervention. Users are left wondering what they did wrong. A quick 8.1 fix for this nuisance is to check the CPU priv spec before auto-enabling zca/zcd/zcf. A more appropriate fix will include a more robust framework that will account for both priv_ver and user choice when auto-enabling/disabling extensions, but for 8.1 we'll make it do with this simple check. It's also worth noticing that this is the only case where we're auto-enabling extensions based on a criteria (in this case RVC) that doesn't match the priv spec of the extensions we're enabling. There's no need for more 8.1 band-aids. Cc: Conor Dooley <conor@kernel.org> Fixes: 2288a5ce43e5 ("target/riscv: add cfg properties for Zc* extension") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn> Tested-by: Conor Dooley <conor.dooley@microchip.com> Message-Id: <20230717154141.60898-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-15accel/tcg: Return bool from page_check_rangeRichard Henderson
Replace the 0/-1 result with true/false. Invert the sense of the test of all callers. Document the function. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230707204054.8792-25-richard.henderson@linaro.org>
2023-07-10riscv: Add support for the Zfa extensionChristoph Müllner
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-10target/riscv/kvm.c: read/write (cbom|cboz)_blocksize in KVMDaniel Henrique Barboza
If we don't set a proper cbom_blocksize|cboz_blocksize in the FDT the Linux Kernel will fail to detect the availability of the CBOM/CBOZ extensions, regardless of the contents of the 'riscv,isa' DT prop. The FDT is being written using the cpu->cfg.cbom|z_blocksize attributes, so let's expose them as user properties like it is already done with TCG. This will also require us to determine proper blocksize values during init() time since the FDT is already created during realize(). We'll take a ride in kvm_riscv_init_multiext_cfg() to do it. Note that we don't need to fetch both cbom and cboz blocksizes every time: check for their parent extensions (icbom and icboz) and only read the blocksizes if needed. In contrast with cbom|z_blocksize properties from TCG, the user is not able to set any value that is different from the 'host' value when running KVM. KVM can be particularly harsh dealing with it: a ENOTSUPP can be thrown for the mere attempt of executing kvm_set_one_reg() for these 2 regs. Hopefully we don't need to call kvm_set_one_reg() for these regs. We'll check if the user input matches the host value in kvm_cpu_set_cbomz_blksize(), the set() accessor for both blocksize properties. We'll fail fast since it's already known to not be supported. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/kvm.c: add kvmconfig_get_cfg_addr() helperDaniel Henrique Barboza
There are 2 places in which we need to get a pointer to a certain property of the cpu->cfg struct based on property offset. Next patch will add a couple more. Create a helper to avoid repeating this code over and over. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: update multi-letter extension KVM propertiesDaniel Henrique Barboza
We're now ready to update the multi-letter extensions status for KVM. kvm_riscv_update_cpu_cfg_isa_ext() is called called during vcpu creation time to verify which user options changes host defaults (via the 'user_set' flag) and tries to write them back to KVM. Failure to commit a change to KVM is only ignored in case KVM doesn't know about the extension (-EINVAL error code) and the user wanted to disable the given extension. Otherwise we're going to abort the boot process. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/cpu.c: create KVM mock propertiesDaniel Henrique Barboza
KVM-specific properties are being created inside target/riscv/kvm.c. But at this moment we're gathering all the remaining properties from TCG and adding them as is when running KVM. This creates a situation where non-KVM properties are setting flags to 'true' due to its default settings (e.g. Zawrs). Users can also freely enable them via command line. This doesn't impact runtime per se because KVM doesn't care about these flags, but code such as riscv_isa_string_ext() take those flags into account. The result is that, for a KVM guest, setting non-KVM properties will make them appear in the riscv,isa DT. We want to keep the same API for both TCG and KVM and at the same time, when running KVM, forbid non-KVM extensions to be enabled internally. We accomplish both by changing riscv_cpu_add_user_properties() to add a mock boolean property for every non-KVM extension in riscv_cpu_extensions[]. Then, when running KVM, users are still free to set extensions at will, but we'll error out if a non-KVM extension is enabled. Setting such extension to 'false' will be ignored. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/cpu.c: remove priv_ver check from riscv_isa_string_ext()Daniel Henrique Barboza
riscv_isa_string_ext() is being used by riscv_isa_string(), which is then used by boards to retrieve the 'riscv,isa' string to be written in the FDT. All this happens after riscv_cpu_realize(), meaning that we're already past riscv_cpu_validate_set_extensions() and, more important, riscv_cpu_disable_priv_spec_isa_exts(). This means that all extensions that needed to be disabled due to priv_spec mismatch are already disabled. Checking this again during riscv_isa_string_ext() is unneeded. Remove it. As a bonus, riscv_isa_string_ext() can now be used with the 'host' KVM-only CPU type since it doesn't have a env->priv_ver assigned and it would fail this check for no good reason. 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-17-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/cpu.c: add satp_mode properties earlierDaniel Henrique Barboza
riscv_cpu_add_user_properties() ended up with an excess of "#ifndef CONFIG_USER_ONLY" blocks after changes that added KVM properties handling. KVM specific properties are required to be created earlier than their TCG counterparts, but the remaining props can be created at any order. Move riscv_add_satp_mode_properties() to the start of the function, inside the !CONFIG_USER_ONLY block already present there, to remove the last ifndef block. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-16-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/kvm.c: add multi-letter extension KVM propertiesDaniel Henrique Barboza
Let's add KVM user properties for the multi-letter extensions that KVM currently supports: zicbom, zicboz, zihintpause, zbb, ssaia, sstc, svinval and svpbmt. As with MISA extensions, we're using the KVMCPUConfig type to hold information about the state of each extension. However, multi-letter extensions have more cases to cover than MISA extensions, so we're adding an extra 'supported' flag as well. This flag will reflect if a given extension is supported by KVM, i.e. KVM knows how to handle it. This is determined during KVM extension discovery in kvm_riscv_init_multiext_cfg(), where we test for EINVAL errors. Any other error will cause an abort. The use of the 'user_set' is similar to what we already do with MISA extensions: the flag set only if the user is changing the extension state. The 'supported' flag will be used later on to make an exception for users that are disabling multi-letter extensions that are unknown to KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-Id: <20230706101738.460804-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/kvm.c: update KVM MISA bitsDaniel Henrique Barboza
Our design philosophy with KVM properties can be resumed in two main decisions based on KVM interface availability and what the user wants to do: - if the user disables an extension that the host KVM module doesn't know about (i.e. it doesn't implement the kvm_get_one_reg() interface), keep booting the CPU. This will avoid users having to deal with issues with older KVM versions while disabling features they don't care; - for any other case we're going to error out immediately. If the user wants to enable a feature that KVM doesn't know about this a problem that is worth aborting - the user must know that the feature wasn't enabled in the hart. Likewise, if KVM knows about the extension, the user wants to enable/disable it, and we fail to do it so, that's also a problem we can't shrug it off. In the case of MISA bits we won't even try enabling bits that aren't already available in the host. The ioctl() is so likely to fail that it's not worth trying. This check is already done in the previous patch, in kvm_cpu_set_misa_ext_cfg(), thus we don't need to worry about it now. In kvm_riscv_update_cpu_misa_ext() we'll go through every potential user option and do as follows: - if the user didn't set the property or set to the same value of the host, do nothing; - Disable the given extension in KVM. Error out if anything goes wrong. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: add KVM specific MISA propertiesDaniel Henrique Barboza
Using all TCG user properties in KVM is tricky. First because KVM supports only a small subset of what TCG provides, so most of the cpu->cfg flags do nothing for KVM. Second, and more important, we don't have a way of telling if any given value is an user input or not. For TCG this has a small impact since we just validating everything and error out if needed. But for KVM it would be good to know if a given value was set by the user or if it's a value already provided by KVM. Otherwise we don't know how to handle failed kvm_set_one_regs() when writing the configurations back. These characteristics make it overly complicated to use the same user facing flags for both KVM and TCG. A simpler approach is to create KVM specific properties that have specialized logic, forking KVM and TCG use cases for those cases only. Fully separating KVM/TCG properties is unneeded at this point - in fact we want the user experience to be as equal as possible, regardless of the acceleration chosen. We'll start this fork with the MISA properties, adding the MISA bits that the KVM driver currently supports. A new KVMCPUConfig type is introduced. It'll hold general information about an extension. For MISA extensions we're going to use the newly created getters of misa_ext_infos[] to populate their name and description. 'offset' holds the MISA bit (RVA, RVC, ...). We're calling it 'offset' instead of 'misa_bit' because this same KVMCPUConfig struct will be used to multi-letter extensions later on. This new type also holds a 'user_set' flag. This flag will be set when the user set an option that's different than what is already configured in the host, requiring KVM intervention to write the regs back during kvm_arch_init_vcpu(). Similar mechanics will be implemented for multi-letter extensions as well. There is no need to duplicate more code than necessary, so we're going to use the existing kvm_riscv_init_user_properties() to add the KVM specific properties. Any code that is adding a TCG user prop is then changed slightly to verify first if there's a KVM prop with the same name already added. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/cpu: add misa_ext_info_arr[]Daniel Henrique Barboza
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-10target/riscv/kvm.c: init 'misa_ext_mask' with scratch CPUDaniel Henrique Barboza
At this moment we're retrieving env->misa_ext during kvm_arch_init_cpu(), leaving env->misa_ext_mask behind. We want to set env->misa_ext_mask, and we want to set it as early as possible. The reason is that we're going to use it in the validation process of the KVM MISA properties we're going to add next. Setting it during arch_init_cpu() is too late for user validation. Move the code to a new helper that is going to be called during init() time, via kvm_riscv_init_user_properties(), like we're already doing for the machine ID properties. Set both misa_ext and misa_ext_mask to the same value retrieved by the 'isa' config reg. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: handle mvendorid/marchid/mimpid for KVM CPUsDaniel Henrique Barboza
After changing user validation for mvendorid/marchid/mimpid to guarantee that the value is validated on user input time, coupled with the work in fetching KVM default values for them by using a scratch CPU, we're certain that the values in cpu->cfg.(mvendorid|marchid|mimpid) are already good to be written back to KVM. There's no need to write the values back for 'host' type CPUs since the values can't be changed, so let's do that just for generic CPUs. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: read marchid/mimpid in kvm_riscv_init_machine_ids()Daniel Henrique Barboza
Allow 'marchid' and 'mimpid' to also be initialized in kvm_riscv_init_machine_ids(). After this change, the handling of mvendorid/marchid/mimpid for the 'host' CPU type will be equal to what we already have for TCG named CPUs, i.e. the user is not able to set these values to a different val than the one that is already preset. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: use KVM scratch CPUs to init KVM propertiesDaniel Henrique Barboza
Certain validations, such as the validations done for the machine IDs (mvendorid/marchid/mimpid), are done before starting the CPU. Non-dynamic (named) CPUs tries to match user input with a preset default. As it is today we can't prefetch a KVM default for these cases because we're only able to read/write KVM regs after the vcpu is spinning. Our target/arm friends use a concept called "scratch CPU", which consists of creating a vcpu for doing queries and validations and so on, which is discarded shortly after use [1]. This is a suitable solution for what we need so let's implement it in target/riscv as well. kvm_riscv_init_machine_ids() will be used to do any pre-launch setup for KVM CPUs, via riscv_cpu_add_user_properties(). The function will create a KVM scratch CPU, fetch KVM regs that work as default values for user properties, and then discard the scratch CPU afterwards. We're starting by initializing 'mvendorid'. This concept will be used to init other KVM specific properties in the next patches as well. [1] target/arm/kvm.c, kvm_arm_create_scratch_host_vcpu() Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/cpu.c: restrict 'marchid' valueDaniel Henrique Barboza
'marchid' shouldn't be set to a different value as previously set for named CPUs. For all other CPUs it shouldn't be freely set either - the spec requires that 'marchid' can't have the MSB (most significant bit) set and every other bit set to zero, i.e. 0x80000000 is an invalid 'marchid' value for 32 bit CPUs. As with 'mimpid', setting a default value based on the current QEMU version is not a good idea because it implies that the CPU implementation changes from one QEMU version to the other. Named CPUs should set 'marchid' to a meaningful value instead, and generic CPUs can set to any valid value. For the 'veyron-v1' CPU this is the error thrown if 'marchid' is set to a different val: $ ./build/qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,marchid=0x80000000 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.marchid=0x80000000: Unable to change veyron-v1-riscv-cpu marchid (0x8000000000010000) And, for generics CPUs, this is the error when trying to set to an invalid val: $ ./build/qemu-system-riscv64 -M virt -nographic -cpu rv64,marchid=0x8000000000000000 qemu-system-riscv64: can't apply global rv64-riscv-cpu.marchid=0x8000000000000000: Unable to set marchid with MSB (64) bit set and the remaining bits zero Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/cpu.c: restrict 'mimpid' valueDaniel Henrique Barboza
Following the same logic used with 'mvendorid' let's also restrict 'mimpid' for named CPUs. Generic CPUs keep setting the value freely. Note that we're getting rid of the default RISCV_CPU_MARCHID value. The reason is that this is not a good default since it's dynamic, changing with with every QEMU version, regardless of whether the actual implementation of the CPU changed from one QEMU version to the other. Named CPU should set it to a meaningful value instead and generic CPUs can set whatever they want. This is the error thrown for an invalid 'mimpid' value for the veyron-v1 CPU: $ ./qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mimpid=2 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mimpid=2: Unable to change veyron-v1-riscv-cpu mimpid (0x111) Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/cpu.c: restrict 'mvendorid' valueDaniel Henrique Barboza
We're going to change the handling of mvendorid/marchid/mimpid by the KVM driver. Since these are always present in all CPUs let's put the same validation for everyone. It doesn't make sense to allow 'mvendorid' to be different than it is already set in named (vendor) CPUs. Generic (dynamic) CPUs can have any 'mvendorid' they want. Change 'mvendorid' to be a class property created via 'object_class_property_add', instead of using the DEFINE_PROP_UINT32() macro. This allow us to define a custom setter for it that will verify, for named CPUs, if mvendorid is different than it is already set by the CPU. This is the error thrown for the 'veyron-v1' CPU if 'mvendorid' is set to an invalid value: $ qemu-system-riscv64 -M virt -nographic -cpu veyron-v1,mvendorid=2 qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.mvendorid=2: Unable to change veyron-v1-riscv-cpu mvendorid (0x61f) Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230706101738.460804-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: skip features setup for KVM CPUsDaniel Henrique Barboza
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-10target/riscv KVM_RISCV_SET_TIMER macro is not configured correctlyyang.zhang
Should set/get riscv all reg timer,i.e, time/compare/frequency/state. Signed-off-by: Yang Zhang <yang.zhang@hexintek.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1688 Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-Id: <20230707032306.4606-1-gaoshanliukou@163.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Set the correct exception for implict G-stage translation failJason Chien
The privileged spec states: For a memory access made to support VS-stage address translation (such as to read/write a VS-level page table), permissions are checked as though for a load or store, not for the original access type. However, any exception is always reported for the original access type (instruction, load, or store/AMO). The current implementation converts the access type to LOAD if implicit G-stage translation fails which results in only reporting "Load guest-page fault". This commit removes the convertion of access type, so the reported exception conforms to the spec. Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20230627074915.7686-1-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Expose properties for BF16 extensionsWeiwei Li
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-07-10target/riscv: Add support for Zvfbfwma extensionWeiwei Li
Add trans_* and helper function for Zvfbfwma instructions. 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> Message-Id: <20230615063302.102409-5-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Add support for Zvfbfmin extensionWeiwei Li
Add trans_* and helper function for Zvfbfmin instructions. 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> Message-Id: <20230615063302.102409-4-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Add support for Zfbfmin extensionWeiwei Li
Add trans_* and helper function for Zfbfmin instructions. 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> Message-Id: <20230615063302.102409-3-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Add properties for BF16 extensionsWeiwei Li
Add ext_zfbfmin/zvfbfmin/zvfbfwma properties. Add require check 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-2-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Add RVV registers to logIvan Klokov
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-07-10target/riscv: update cur_pmbase/pmmask based on mode affected by MPRVWeiwei Li
Pointer mask is also affected by MPRV which means cur_pmbase/pmmask should also take MPRV into consideration. As pointer mask for instruction is not supported currently, so we can directly update cur_pmbase/pmmask based on address related mode and xlen affected by MPRV now. 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: <20230614032547.35895-3-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Add additional xlen for address when MPRV=1Weiwei Li
As specified in privilege spec:"When MPRV=1, load and store memory addresses are treated as though the current XLEN were set to MPP’s XLEN". So the xlen for address may be different from current xlen. 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: <20230614032547.35895-2-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv/cpu.c: fix veyron-v1 CPU propertiesDaniel Henrique Barboza
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-07-10target/riscv: Remove redundant assignment to SXLWeiwei Li
SXL is initialized as env->misa_mxl which is also the mxl value. So we can just remain it unchanged to keep it read-only. 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: <20230603134236.15719-4-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Support MSTATUS.MPV/GVA only when RVH is enabledWeiwei Li
MPV and GVA bits are added by hypervisor extension to mstatus and mstatush (if MXLEN=32). 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: <20230603134236.15719-3-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10target/riscv: Make MPV only work when MPP != PRV_MWeiwei Li
Upon MRET or explicit memory access with MPRV=1, MPV should be ignored when MPP=PRV_M. 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: <20230603134236.15719-2-liweiwei@iscas.ac.cn> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-07-10disas/riscv: Add support for XThead* instructionsChristoph Müllner
Support for emulating XThead* instruction has been added recently. This patch adds support for these instructions to the RISC-V disassembler. Co-developed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Message-Id: <20230612111034.3955227-9-christoph.muellner@vrull.eu> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>