aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-01-10target/riscv/tcg: add user flag for profile supportDaniel Henrique Barboza
The TCG emulation implements all the extensions described in the RVA22U64 profile, both mandatory and optional. The mandatory extensions will be enabled via the profile flag. We'll leave the optional extensions to be enabled by hand. Given that this is the first profile we're implementing in TCG we'll need some ground work first: - all profiles declared in riscv_profiles[] will be exposed to users. TCG is the main accelerator we're considering when adding profile support in QEMU, so for now it's safe to assume that all profiles in riscv_profiles[] will be relevant to TCG; - we'll not support user profile settings for vendor CPUs. The flags will still be exposed but users won't be able to change them; - profile support, albeit available for all non-vendor CPUs, will be based on top of the new 'rv64i' CPU. Setting a profile to 'true' means enable all mandatory extensions of this profile, setting it to 'false' will disable all mandatory profile extensions of the CPU, which will obliterate preset defaults. This is not a problem for a bare CPU like rv64i but it can allow for silly scenarios when using other CPUs. E.g. an user can do "-cpu rv64,rva22u64=false" and have a bunch of default rv64 extensions disabled. The recommended way of using profiles is the rv64i CPU, but users are free to experiment. For now we'll handle multi-letter extensions only. MISA extensions need additional steps that we'll take care later. At this point we can boot a Linux buildroot using rva22u64 using the following options: -cpu rv64i,rva22u64=true,sv39=true,g=true,c=true,s=true Note that being an usermode/application profile we still need to explicitly set 's=true' to enable Supervisor mode to boot Linux. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: add 'rva22u64' flag as unavailableDaniel Henrique Barboza
KVM does not have the means to support enabling the rva22u64 profile. The main reasons are: - we're missing support for some mandatory rva22u64 extensions in the KVM module; - we can't make promises about enabling a profile since it all depends on host support in the end. We'll revisit this decision in the future if needed. For now mark the 'rva22u64' profile as unavailable when running a KVM CPU: $ qemu-system-riscv64 -machine virt,accel=kvm -cpu rv64,rva22u64=true qemu-system-riscv64: can't apply global rv64-riscv-cpu.rva22u64=true: 'rva22u64' is not available with KVM 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: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add rva22u64 profile definitionDaniel Henrique Barboza
The rva22U64 profile, described in: https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#rva22-profiles Contains a set of CPU extensions aimed for 64-bit userspace applications. Enabling this set to be enabled via a single user flag makes it convenient to enable a predictable set of features for the CPU, giving users more predicability when running/testing their workloads. QEMU implements all possible extensions of this profile. All the so called 'synthetic extensions' described in the profile that are cache related are ignored/assumed enabled (Za64rs, Zic64b, Ziccif, Ziccrse, Ziccamoa, Zicclsm) since we do not implement a cache model. An abstraction called RISCVCPUProfile is created to store the profile. 'ext_offsets' contains mandatory extensions that QEMU supports. Same thing with the 'misa_ext' mask. Optional extensions must be enabled manually in the command line if desired. The design here is to use the common target/riscv/cpu.c file to store the profile declaration and export it to the accelerator files. Each accelerator is then responsible to expose it (or not) to users and how to enable the extensions. Next patches will implement the profile for TCG and KVM. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231218125334.37184-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10riscv-qmp-cmds.c: expose named features in cpu_model_expansionDaniel Henrique Barboza
Named features (zic64b the sole example at this moment) aren't expose to users, thus we need another way to expose them. Go through each named feature, get its boolean value, do the needed conversions (bool to qbool, qbool to QObject) and add it to output dict. Another adjustment is needed: named features are evaluated during finalize(), so riscv_cpu_finalize_features() needs to be mandatory regardless of whether we have an input dict or not. Otherwise zic64b will always return 'false', which is incorrect: the default values of cache blocksizes ([cbom/cbop/cboz]_blocksize) are set to 64, satisfying the conditions for zic64b. Here's an API usage example after this patch: $ ./build/qemu-system-riscv64 -S -M virt -display none -qmp tcp:localhost:1234,server,wait=off $ ./scripts/qmp/qmp-shell localhost:1234 Welcome to the QMP low-level shell! Connected to QEMU 8.1.50 (QEMU) query-cpu-model-expansion type=full model={"name":"rv64"} {"return": {"model": {"name": "rv64", "props": {... "zic64b": true, ...}}}} zic64b is set to 'true', as expected, since all cache sizes are 64 bytes by default. If we change one of the cache blocksizes, zic64b is returned as 'false': (QEMU) query-cpu-model-expansion type=full model={"name":"rv64","props":{"cbom_blocksize":128}} {"return": {"model": {"name": "rv64", "props": {... "zic64b": false, ...}}}} Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: add 'zic64b' supportDaniel Henrique Barboza
zic64b is defined in the RVA22U64 profile [1] as a named feature for "Cache blocks must be 64 bytes in size, naturally aligned in the address space". It's a fantasy name for 64 bytes cache blocks. The RVA22U64 profile mandates this feature, meaning that applications using this profile expects 64 bytes cache blocks. To make the upcoming RVA22U64 implementation complete, we'll zic64b as a 'named feature', not a regular extension. This means that: - it won't be exposed to users; - it won't be written in riscv,isa. This will be extended to other named extensions in the future, so we're creating some common boilerplate for them as well. zic64b is default to 'true' since we're already using 64 bytes blocks. If any cache block size (cbo{m,p,z}_blocksize) is changed to something different than 64, zic64b is set to 'false'. Our profile implementation will then be able to check the current state of zic64b and take the appropriate action (e.g. throw a warning). [1] https://github.com/riscv/riscv-profiles/releases/download/v1.0/profiles.pdf Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add zicbop extension flagDaniel Henrique Barboza
QEMU already implements zicbom (Cache Block Management Operations) and zicboz (Cache Block Zero Operations). Commit 59cb29d6a5 ("target/riscv: add Zicbop cbo.prefetch{i, r, m} placeholder") added placeholders for what would be the instructions for zicbop (Cache Block Prefetch Operations), which are now no-ops. The RVA22U64 profile mandates zicbop, which means that applications that run with this profile might expect zicbop to be present in the riscv,isa DT and might behave badly if it's absent. Adding zicbop as an extension will make our future RVA22U64 implementation more in line with what userspace expects and, if/when cache block prefetch operations became relevant to QEMU, we already have the extension flag to turn then on/off as needed. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: add rv64i CPUDaniel Henrique Barboza
We don't have any form of a 'bare bones' CPU. rv64, our default CPUs, comes with a lot of defaults. This is fine for most regular uses but it's not suitable when more control of what is actually loaded in the CPU is required. A bare-bones CPU would be annoying to deal with if not by profile support, a way to load a multitude of extensions with a single flag. Profile support is going to be implemented shortly, so let's add a CPU for it. The new 'rv64i' CPU will have only RVI loaded. It is inspired in the profile specification that dictates, for RVA22U64 [1]: "RVA22U64 Mandatory Base RV64I is the mandatory base ISA for RVA22U64" And so it seems that RV64I is the mandatory base ISA for all profiles listed in [1], making it an ideal CPU to use with profile support. rv64i is a CPU of type TYPE_RISCV_BARE_CPU. It has a mix of features from pre-existent CPUs: - it allows extensions to be enabled, like generic CPUs; - it will not inherit extension defaults, like vendor CPUs. This is the minimum extension set to boot OpenSBI and buildroot using rv64i: ./build/qemu-system-riscv64 -nographic -M virt \ -cpu rv64i,sv39=true,g=true,c=true,s=true,u=true Our minimal riscv,isa in this case will be: # cat /proc/device-tree/cpus/cpu@0/riscv,isa rv64imafdc_zicntr_zicsr_zifencei_zihpm_zca_zcd# [1] https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: update priv_ver on user_set extensionsDaniel Henrique Barboza
We'll add a new bare CPU type that won't have any default priv_ver. This means that the CPU will default to priv_ver = 0, i.e. 1.10.0. At the same we'll allow these CPUs to enable extensions at will, but then, if the extension has a priv_ver newer than 1.10, we'll end up disabling it. Users will then need to manually set priv_ver to something other than 1.10 to enable the extensions they want, which is not ideal. Change the setter() of extensions to allow user enabled extensions to bump the priv_ver of the CPU. This will make it convenient for users to enable extensions for CPUs that doesn't set a default priv_ver. This change does not affect any existing CPU: vendor CPUs does not allow extensions to be enabled, and generic CPUs are already set to priv_ver LATEST. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/tcg: do not use "!generic" CPU checksDaniel Henrique Barboza
Our current logic in get/setters of MISA and multi-letter extensions works because we have only 2 CPU types, generic and vendor, and by using "!generic" we're implying that we're talking about vendor CPUs. When adding a third CPU type this logic will break so let's handle it beforehand. In set_misa_ext_cfg() and set_multi_ext_cfg(), check for "vendor" cpu instead of "not generic". The "generic CPU" checks remaining are from riscv_cpu_add_misa_properties() and cpu_add_multi_ext_prop() before applying default values for the extensions. This leaves us with: - vendor CPUs will not allow extension enablement, all other CPUs will; - generic CPUs will inherit default values for extensions, all others won't. And now we can add a new, third CPU type, that will allow extensions to be enabled and will not inherit defaults, without changing the existing logic. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: create TYPE_RISCV_VENDOR_CPUDaniel Henrique Barboza
We want to add a new CPU type for bare CPUs that will inherit specific traits of the 2 existing types: - it will allow for extensions to be enabled/disabled, like generic CPUs; - it will NOT inherit defaults, like vendor CPUs. We can make this conditions met by adding an explicit type for the existing vendor CPUs and change the existing logic to not imply that "not generic" means vendor CPUs. Let's add the "vendor" CPU type first. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231218125334.37184-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10docs/system/riscv: document acpi parameter of virt machineHeinrich Schuchardt
Since QEMU v8.0.0 the RISC-V virt machine has a switch to disable ACPI table generation. Add it to the documentation. Fixes: 168b8c29cedb ("hw/riscv/virt: Add a switch to disable ACPI") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231220193436.25909-1-heinrich.schuchardt@canonical.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10disas/riscv: Add amocas.[w,d,q] instructionsRob Bradford
Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231207153842.32401-3-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Add support for Zacas extensionWeiwei Li
Add support for amocas.w/d/q instructions which are part of the ratified Zacas extension: https://github.com/riscv/riscv-zacas Signed-off-by: Weiwei Li <liweiwei@iscas.ac.cn> Signed-off-by: Junqiang Wang <wangjunqiang@iscas.ac.cn> Signed-off-by: Rob Bradford <rbradford@rivosinc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231207153842.32401-2-rbradford@rivosinc.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt.c: fix the interrupts-extended property format of PLICYong-Xuan Wang
The interrupts-extended property of PLIC only has 2 * hart number fields when KVM enabled, copy 4 * hart number fields to fdt will expose some uninitialized value. In this patch, I also refactor the code about the setting of interrupts-extended property of PLIC for improved readability. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231218090543.22353-1-yongxuan.wang@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add PLIC in MADTSunil V L
Add PLIC structures for each socket in the MADT when system is configured with PLIC as the external interrupt controller. Signed-off-by: Haibo Xu <haibo1.xu@intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-14-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add IO controllers and devicesSunil V L
Add basic IO controllers and devices like PCI, VirtIO and UART in the ACPI namespace. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-13-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt: Update GPEX MMIO related propertiesSunil V L
Update the GPEX host bridge properties related to MMIO ranges with values set for the virt machine. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-12-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/pci-host/gpex: Define properties for MMIO rangesSunil V L
ACPI DSDT generator needs information like ECAM range, PIO range, 32-bit and 64-bit PCI MMIO range etc related to the PCI host bridge. Instead of making these values machine specific, create properties for the GPEX host bridge with default value 0. During initialization, the firmware can initialize these properties with correct values for the platform. This basically allows DSDT generator code independent of the machine specific memory map accesses. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231218150247.466427-11-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add MMU node in RHCTSunil V L
MMU type information is available via MMU node in RHCT. Add this node in RHCT. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-10-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add CMO information in RHCTSunil V L
When CMO related extensions like Zicboz, Zicbom and Zicbop are enabled, the block size for those extensions need to be communicated via CMO node in RHCT. Add CMO node in RHCT if any of those CMO extensions are detected. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-9-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add APLIC in the MADTSunil V L
Add APLIC structures for each socket in the MADT when system is configured with APLIC as the external wired interrupt controller. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-8-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add IMSIC in the MADTSunil V L
Add IMSIC structure in MADT when IMSIC is configured. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-7-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv/virt-acpi-build.c: Add AIA support in RINTCSunil V L
Update the RINTC structure in MADT with AIA related fields. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-6-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv: virt: Make few IMSIC macros and functions publicSunil V L
Some macros and static function related to IMSIC are defined in virt.c. They are required in virt-acpi-build.c. So, make them public. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-5-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/i386/acpi-microvm.c: Use common function to add virtio in DSDTSunil V L
With common function to add virtio in DSDT created now, update microvm code also to use it instead of duplicate code. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-4-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/arm/virt-acpi-build.c: Migrate virtio creation to common locationSunil V L
RISC-V also needs to create the virtio in DSDT in the same way as ARM. So, instead of duplicating the code, move this function to the device specific file which is common across architectures. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-3-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/arm/virt-acpi-build.c: Migrate fw_cfg creation to common locationSunil V L
RISC-V also needs to use the same code to create fw_cfg in DSDT. So, avoid code duplication by moving the code in arm and riscv to a device specific file. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-2-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: rename riscv_reg_id() to riscv_reg_id_ulong()Daniel Henrique Barboza
kvm_riscv_reg_id() returns an id encoded with an ulong size, i.e. an u32 size when running TARGET_RISCV32 and u64 when running TARGET_RISCV64. Rename it to kvm_riscv_reg_id_ulong() to enhance code readability. It'll be in line with the existing kvm_riscv_reg_id_<size>() helpers. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: add RISCV_CONFIG_REG()Daniel Henrique Barboza
Create a RISCV_CONFIG_REG() macro, similar to what other regs use, to hide away some of the boilerplate. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: change timer regs size to u64Daniel Henrique Barboza
KVM_REG_RISCV_TIMER regs are always u64 according to the KVM API, but at this moment we'll return u32 regs if we're running a RISCV32 target. Use the kvm_riscv_reg_id_u64() helper in RISCV_TIMER_REG() to fix it. Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: change KVM_REG_RISCV_FP_D to u64Daniel Henrique Barboza
KVM_REG_RISCV_FP_D regs are always u64 size. Using kvm_riscv_reg_id() in RISCV_FP_D_REG() ends up encoding the wrong size if we're running with TARGET_RISCV32. Create a new helper that returns a KVM ID with u64 size and use it with RISCV_FP_D_REG(). Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/kvm: change KVM_REG_RISCV_FP_F to u32Daniel Henrique Barboza
KVM_REG_RISCV_FP_F regs have u32 size according to the API, but by using kvm_riscv_reg_id() in RISCV_FP_F_REG() we're returning u64 sizes when running with TARGET_RISCV64. The most likely reason why no one noticed this is because we're not implementing kvm_cpu_synchronize_state() in RISC-V yet. Create a new helper that returns a KVM ID with u32 size and use it in RISCV_FP_F_REG(). Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20231208183835.2411523-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/cpu.c: fix machine IDs gettersDaniel Henrique Barboza
mvendorid is an uint32 property, mimpid/marchid are uint64 properties. But their getters are returning bools. The reason this went under the radar for this long is because we have no code using the getters. The problem can be seem via the 'qom-get' API though. Launching QEMU with the 'veyron-v1' CPU, a model with: VEYRON_V1_MVENDORID: 0x61f (1567) VEYRON_V1_MIMPID: 0x111 (273) VEYRON_V1_MARCHID: 0x8000000000010000 (9223372036854841344) This is what the API returns when retrieving these properties: (qemu) qom-get /machine/soc0/harts[0] mvendorid true (qemu) qom-get /machine/soc0/harts[0] mimpid true (qemu) qom-get /machine/soc0/harts[0] marchid true After this patch: (qemu) qom-get /machine/soc0/harts[0] mvendorid 1567 (qemu) qom-get /machine/soc0/harts[0] mimpid 273 (qemu) qom-get /machine/soc0/harts[0] marchid 9223372036854841344 Fixes: 1e34150045 ("target/riscv/cpu.c: restrict 'mvendorid' value") Fixes: a1863ad368 ("target/riscv/cpu.c: restrict 'mimpid' value") Fixes: d6a427e2c0 ("target/riscv/cpu.c: restrict 'marchid' value") 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: <20231211170732.2541368-1-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv/pmp: Use hwaddr instead of target_ulong for RV32Ivan Klokov
The Sv32 page-based virtual-memory scheme described in RISCV privileged spec Section 5.3 supports 34-bit physical addresses for RV32, so the PMP scheme must support addresses wider than XLEN for RV32. However, PMP address register format is still 32 bit wide. Signed-off-by: Ivan Klokov <ivan.klokov@syntacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231123091214.20312-1-ivan.klokov@syntacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Not allow write mstatus_vs without RVVLIU Zhiwei
If CPU does not implement the Vector extension, it usually means mstatus vs hardwire to zero. So we should not allow write a non-zero value to this field. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231215023313.1708-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Fix th.dcache.cval1 priviledge checkLIU Zhiwei
According to the specification, the th.dcache.cvall1 can be executed under all priviledges. The specification about xtheadcmo located in, https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadcmo/dcache_cval1.adoc Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Christoph Muellner <christoph.muellner@vrull.eu> Message-ID: <20231208094315.177-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: The whole vector register move instructions depend on vsewMax Chou
The RISC-V v spec 16.6 section says that the whole vector register move instructions operate as if EEW=SEW. So it should depends on the vsew field of vtype register. Signed-off-by: Max Chou <max.chou@sifive.com> Acked-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231129170400.21251-3-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10target/riscv: Add vill check for whole vector register move instructionsMax Chou
The ratified version of RISC-V V spec section 16.6 says that `The instructions operate as if EEW=SEW`. So the whole vector register move instructions depend on the vtype register that means the whole vector register move instructions should raise an illegal-instruction exception when vtype.vill=1. Signed-off-by: Max Chou <max.chou@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231129170400.21251-2-max.chou@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-09Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into stagingPeter Maydell
Pull request # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmWcJMUACgkQnKSrs4Gr # c8hh/Qf/Wt177UlhBR49OWmmegs8c8yS1mhyawo7YIJM4pqoXCYLaACpcKECXcGU # rlgyR4ow68EXnnU8+/s2cp2UqHxrla+E2eNqBoTDmkNt3Cko5sJn5G5PM5EYK+mO # JjFRzn7awRyxD6mGOuaMVoj6OuHbAA/U4JF7FhW0YuRl8v0/mvAxRSfQ4U6Crq/y # 19Aa1CXHD1GH2CUJsMCY8zT47Dr4DJcvZx5IpcDFaHaYDCkktFwNzdo5IDnCx2M2 # xnP37Qp/Q93cu12lWkVOu8HCT6yhoszahyOqlBxDmo7QeGkskrxGbMyE+vHM3fFI # aGSxiw193U7/QWu+Cq2/727C3YIq1g== # =pKUb # -----END PGP SIGNATURE----- # gpg: Signature made Mon 08 Jan 2024 16:37:25 GMT # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" [full] # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" [full] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * tag 'block-pull-request' of https://gitlab.com/stefanha/qemu: Rename "QEMU global mutex" to "BQL" in comments and docs Replace "iothread lock" with "BQL" in comments qemu/main-loop: rename qemu_cond_wait_iothread() to qemu_cond_wait_bql() qemu/main-loop: rename QEMU_IOTHREAD_LOCK_GUARD to BQL_LOCK_GUARD system/cpus: rename qemu_mutex_lock_iothread() to bql_lock() iothread: Remove unused Error** argument in aio_context_set_aio_params Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-09Merge tag 'pull-replay-fixes-080124-1' of https://gitlab.com/stsquad/qemu ↵Peter Maydell
into staging Record/replay fixes for replay_kernel tests - add a 32 bit x86 replay test case - fix some typos - use modern snapshot setting for tests - update replay_dump for current ABI - remove stale replay variables - improve kdoc for ReplayState - introduce common error path for replay - always fully drain chardevs when in replay - catch unexpected waitio on playback - remove flaky tags from replay_kernel tests # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmWcAJgACgkQ+9DbCVqe # KkS/TQf+PuIPtuX71ENajfRBjz6450IbGqLUJ1HEaPGYGRj+fR6rg5g5u8qaBrT7 # TUv9ef9L22NtyL+Gbs1OGpGDWKoqV6RQc+A/MHa8IKFpcS24nUo3k4psIC6NSGRH # 6w3++fPC1Q5cDk9Lei3Qt8fXzcnUZz+NTiIK05aC0xh7D6uGfdADvKqHeLav7qi+ # X2ztNdBsy/WJWCuWcMVzb/dGwDBtuyyxvqTD4EF+zn+gSYq9od2G8XdF+0o6ZVLM # mXEHwNwB6UjOkLt2cYaay59SXcJFvwxKbEGTDnA7T+kgd3rknuBaWdVBIazoSPQh # +522nPz5qq/3wO1l7+iQXuvd38fWyw== # =nKRx # -----END PGP SIGNATURE----- # gpg: Signature made Mon 08 Jan 2024 14:03:04 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-replay-fixes-080124-1' of https://gitlab.com/stsquad/qemu: tests/avocado: remove skips from replay_kernel chardev: force write all when recording replay logs replay: stop us hanging in rr_wait_io_event replay/replay-char: use report_sync_error replay: introduce a central report point for sync errors replay: make has_unread_data a bool replay: add proper kdoc for ReplayState replay: remove host_clock_last scripts/replay_dump: track total number of instructions scripts/replay-dump: update to latest format tests/avocado: modernise the drive args for replay_linux tests/avocado: fix typo in replay_linux tests/avocado: add a simple i386 replay kernel test Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-09acpi/tests/avocado/bits: disable smilatency testsAni Sinha
smilatncy tests in bios bits seems to generate some flakyness in running the bits avocado tests. Disable them for now. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2077 CC: peter.maydell@linaro.org CC: crosa@redhat.com CC: philmd@linaro.org CC: bleal@redhat.com CC: mst@redhat.com CC: wainersm@redhat.com Signed-off-by: Ani Sinha <anisinha@redhat.com> Message-id: 20240108103643.4434-3-anisinha@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-09acpi/tests/avocado/bits: import smilatency test from bits in order to disable itAni Sinha
Add smilatency test script in the bits avocado tests from bios-bits. No changes have been made to the original test script. The test will be disabled in the subsequent patch. CC: peter.maydell@linaro.org CC: crosa@redhat.com CC: philmd@linaro.org CC: bleal@redhat.com CC: mst@redhat.com CC: wainersm@redhat.com Signed-off-by: Ani Sinha <anisinha@redhat.com> Message-id: 20240108103643.4434-2-anisinha@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-08Rename "QEMU global mutex" to "BQL" in comments and docsStefan Hajnoczi
The term "QEMU global mutex" is identical to the more widely used Big QEMU Lock ("BQL"). Update the code comments and documentation to use "BQL" instead of "QEMU global mutex". Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Message-id: 20240102153529.486531-6-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-01-08Replace "iothread lock" with "BQL" in commentsStefan Hajnoczi
The term "iothread lock" is obsolete. The APIs use Big QEMU Lock (BQL) in their names. Update the code comments to use "BQL" instead of "iothread lock". Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Message-id: 20240102153529.486531-5-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-01-08qemu/main-loop: rename qemu_cond_wait_iothread() to qemu_cond_wait_bql()Stefan Hajnoczi
The name "iothread" is overloaded. Use the term Big QEMU Lock (BQL) instead, it is already widely used and unambiguous. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20240102153529.486531-4-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-01-08qemu/main-loop: rename QEMU_IOTHREAD_LOCK_GUARD to BQL_LOCK_GUARDStefan Hajnoczi
The name "iothread" is overloaded. Use the term Big QEMU Lock (BQL) instead, it is already widely used and unambiguous. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20240102153529.486531-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-01-08system/cpus: rename qemu_mutex_lock_iothread() to bql_lock()Stefan Hajnoczi
The Big QEMU Lock (BQL) has many names and they are confusing. The actual QemuMutex variable is called qemu_global_mutex but it's commonly referred to as the BQL in discussions and some code comments. The locking APIs, however, are called qemu_mutex_lock_iothread() and qemu_mutex_unlock_iothread(). The "iothread" name is historic and comes from when the main thread was split into into KVM vcpu threads and the "iothread" (now called the main loop thread). I have contributed to the confusion myself by introducing a separate --object iothread, a separate concept unrelated to the BQL. The "iothread" name is no longer appropriate for the BQL. Rename the locking APIs to: - void bql_lock(void) - void bql_unlock(void) - bool bql_locked(void) There are more APIs with "iothread" in their names. Subsequent patches will rename them. There are also comments and documentation that will be updated in later patches. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Paul Durrant <paul@xen.org> Acked-by: Fabiano Rosas <farosas@suse.de> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Cédric Le Goater <clg@kaod.org> Acked-by: Peter Xu <peterx@redhat.com> Acked-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com> Acked-by: Hyman Huang <yong.huang@smartx.com> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-id: 20240102153529.486531-2-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-01-08iothread: Remove unused Error** argument in aio_context_set_aio_paramsPhilippe Mathieu-Daudé
aio_context_set_aio_params() doesn't use its undocumented Error** argument. Remove it to simplify. Note this removes a use of "unchecked Error**" in iothread_set_aio_context_params(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231120171806.19361-1-philmd@linaro.org>
2024-01-08tests/avocado: remove skips from replay_kernelAlex Bennée
With the latest fixes for #2010 and #2013 these tests look pretty stable now. Of course the only way to be really sure is to run it in the CI infrastructure and see what breaks. Acked-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231211091346.14616-14-alex.bennee@linaro.org>
2024-01-08chardev: force write all when recording replay logsAlex Bennée
This is mostly a problem within avocado as serial generally isn't busy enough to overfill pipes. However the consequences of recording a failed write will haunt us on replay when the log will be out of sync to the playback. Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2010 Acked-by: Pavel Dovgalyuk <Pavel.Dovgalyuk@ispras.ru> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20231211091346.14616-13-alex.bennee@linaro.org>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-14 00:05:13 +0000