summary refs log tree commit diff stats
path: root/rust/qemu-api/src/assertions.rs (unfollow)
Commit message (Collapse)AuthorFilesLines
2025-05-20target/riscv: convert TT Ascalon to RISCVCPUDefPaolo Bonzini1-67/+60
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: convert THead C906 to RISCVCPUDefPaolo Bonzini1-33/+28
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: generalize custom CSR functionalityPaolo Bonzini4-23/+40
While at it, constify it so that the RISCVCSR array in RISCVCPUDef can also be const. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: th: make CSR insertion test a bit more intuitivePaolo Bonzini1-9/+4
In preparation for generalizing the custom CSR functionality, make the test return bool instead of int. Make the insertion_test optional, too. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: convert SiFive U models to RISCVCPUDefPaolo Bonzini2-43/+37
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: convert ibex CPU models to RISCVCPUDefPaolo Bonzini1-23/+16
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: convert SiFive E CPU models to RISCVCPUDefPaolo Bonzini2-54/+21
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: convert dynamic CPU models to RISCVCPUDefPaolo Bonzini1-82/+31
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: convert bare CPU models to RISCVCPUDefPaolo Bonzini1-41/+17
Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: convert profile CPU models to RISCVCPUDefPaolo Bonzini2-38/+48
Profile CPUs reuse the instance_init function for bare CPUs; make them proper subclasses instead. Enabling a profile is now done based on the RISCVCPUDef struct: even though there is room for only one in RISCVCPUDef, subclasses check that the parent class's profile is enabled through the parent profile mechanism. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: convert abstract CPU classes to RISCVCPUDefPaolo Bonzini2-48/+46
Start from the top of the hierarchy: dynamic and vendor CPUs are just markers, whereas bare CPUs can have their instance_init function replaced by RISCVCPUDef. The only difference is that the maximum supported SATP mode has to be specified separately for 32-bit and 64-bit modes. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: add more RISCVCPUDef fieldsPaolo Bonzini3-1/+51
Allow using RISCVCPUDef to replicate all the logic of custom .instance_init functions. To simulate inheritance, merge the child's RISCVCPUDef with the parent and then finally move it to the CPUState at the end of TYPE_RISCV_CPU's own instance_init function. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: include default value in cpu_cfg_fields.h.incPaolo Bonzini2-12/+12
In preparation for adding a function to merge two RISCVCPUConfigs (pulling values from the parent if they are not overridden) annotate cpu_cfg_fields.h.inc with the default value of the fields. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: move RISCVCPUConfig fields to a header filePaolo Bonzini2-160/+173
To support merging a subclass's RISCVCPUDef into the superclass, a list of all the CPU features is needed. Put them into a header file that can be included multiple times, expanding the macros BOOL_FIELD and TYPE_FIELD to different operations. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: merge riscv_cpu_class_init with the class_base functionPaolo Bonzini1-11/+10
Since all TYPE_RISCV_CPU subclasses support a class_data of type RISCVCPUDef, process it even before calling the .class_init function for the subclasses. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: store RISCVCPUDef struct directly in the classPaolo Bonzini8-29/+39
Prepare for adding more fields to RISCVCPUDef and reading them in riscv_cpu_init: instead of storing the misa_mxl_max field in RISCVCPUClass, ensure that there's always a valid RISCVCPUDef struct and go through it. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: introduce RISCVCPUDefPaolo Bonzini2-9/+22
Start putting all the CPU definitions in a struct. Later this will replace instance_init functions with declarative code, for now just remove the ugly cast of class_data. Reviewed-by: Alistair Francis <alistair23@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: move satp_mode.{map,init} out of CPUConfigPaolo Bonzini3-30/+30
They are used to provide the nice QOM properties for svNN, but the canonical source of the CPU configuration is now cpu->cfg.max_satp_mode. Store them in the ArchCPU struct. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: remove supported from RISCVSATPMapPaolo Bonzini2-11/+23
"supported" can be computed on the fly based on the max_satp_mode. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: update max_satp_mode based on QOM propertiesPaolo Bonzini5-32/+24
Almost all users of cpu->cfg.satp_mode care about the "max" value satp_mode_max_from_map(cpu->cfg.satp_mode.map). Convert the QOM properties back into it. For TCG, deduce the bitmap of supported modes from valid_vm[]. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: cpu: store max SATP mode as a single integerPaolo Bonzini3-7/+8
The maximum available SATP mode implies all the shorter virtual address sizes. Store it in RISCVCPUConfig and avoid recomputing it via satp_mode_max_from_map. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20target/riscv: assert argument to set_satp_mode_max_supported is validPaolo Bonzini1-1/+5
Check that the argument to set_satp_mode_max_supported is valid for the MXL value of the CPU. It would be a bug in the CPU definition if it weren't. In fact, there is such a bug in riscv_bare_cpu_init(): not just SV64 is not a valid VM mode for 32-bit CPUs, SV64 is not a valid VM mode at all, not yet at least. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20hw/riscv: acpi: only create RHCT MMU entry for supported typesPaolo Bonzini1-3/+6
Do not create the RHCT MMU type entry for RV32 CPUs, since it only has definitions for SV39/SV48/SV57. Likewise, check that satp_mode_max_from_map() will actually return a valid value, skipping the MMU type entry if all MMU types were disabled on the command line. Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20qapi/misc-target: Fix the doc to distinguish query-sgx and ↵Zhao Liu1-2/+2
query-sgx-capabilities There're 2 QMP commands: query-sgx and query-sgx-capabilities, but their outputs are very similar and the documentation lacks clear differentiation. From the codes, query-sgx is used to gather guest's SGX capabilities (including SGX related CPUIDs and EPC sections' size, in SGXInfo), and if guest doesn't have SGX, then QEMU will report the error message. On the other hand, query-sgx-capabilities is used to gather host's SGX capabilities (descripted by SGXInfo as well). And if host doesn't support SGX, then QEMU will also report the error message. Considering that SGXInfo is already documented and both these 2 commands have enough error messages (for the exception case in their codes). Therefore the QAPI documentation for these two commands only needs to emphasize that one of them applies to the guest and the other to the host. Fix their documentation to reflect this difference. Reported-by: Markus Armbruster <armbru@redhat.com> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Acked-by: Markus Armbruster <armbru@redhat.com> Link: https://lore.kernel.org/r/20250513143131.2008078-3-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20qapi/misc-target: Fix the doc related SGXEPCSectionZhao Liu1-2/+2
The "sections" field of SGXInfo is used to gather EPC section information for both the guest and the host. Therefore, delete the "for guest" limitation. Additionally, avoid the abbreviation "info" and use "information" instead. And for SGXEPCSection, delete the redundant word "info". Reported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Acked-by: Markus Armbruster <armbru@redhat.com> Link: https://lore.kernel.org/r/20250513143131.2008078-2-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20qapi/misc-target: Rename SGXInfo to SgxInfoZhao Liu3-15/+15
QAPI requires strict PascalCase naming style, i.e., only the first letter of a single word is allowed to be uppercase, which could help with readability. Rename SGXInfo to SgxInfo. Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250516091130.2374221-3-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20qapi/misc-target: Rename SGXEPCSection to SgxEpcSectionZhao Liu2-12/+12
QAPI requires strict PascalCase naming style, i.e., only the first letter of a single word is allowed to be uppercase, which could help with readability. Rename SGXEPCSection to SgxEpcSection. Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Link: https://lore.kernel.org/r/20250516091130.2374221-2-zhao1.liu@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20hw/pci-host: Remove unused pci_host_data_be_opsRakesh Jeyasingh3-11/+0
pci_host_data_be_ops became unused after endianness fixes Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Rakesh Jeyasingh <rakeshjb010@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/r/20250429170354.150581-3-rakeshjb010@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20hw/pci-host/gt64120: Fix endianness handlingRakesh Jeyasingh1-34/+48
The GT-64120 PCI controller requires special handling where: 1. Host bridge(bus 0 ,device 0) must never be byte-swapped 2. Other devices follow MByteSwap bit in GT_PCI0_CMD The previous implementation incorrectly swapped all accesses, breaking host bridge detection (lspci -d 11ab:4620). Changes made: 1. Removed gt64120_update_pci_cfgdata_mapping() and moved data_mem initialization to gt64120_realize() for cleaner setup 2. Implemented custom read/write handlers that: - Preserve host bridge accesses (extract32(config_reg,11,13)==0) - apply swapping only for non-bridge devices in big-endian mode Fixes: 145e2198 ("hw/mips/gt64xxx_pci: Endian-swap using PCI_HOST_BRIDGE MemoryRegionOps") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2826 Signed-off-by: Rakesh Jeyasingh <rakeshjb010@gmail.com> Tested-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/r/20250429170354.150581-2-rakeshjb010@gmail.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20i386/hvf: Make CPUID_HT supportedXiaoyao Li1-1/+1
Since Commit c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in x86_cpu_expand_features() instead of cpu_x86_cpuid()"), CPUID_HT will be set in env->features[] in x86_cpu_expand_features() when vcpus >= 2. Later in x86_cpu_filter_features() it will check against the HVF supported bits. It will trigger the warning like qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:EDX.ht [bit 28] Add CPUID_HT to HVF supported CPUID bits to fix it. Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250514031652.838763-3-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-20i386/tcg: Make CPUID_HT and CPUID_EXT3_CMP_LEG supportedXiaoyao Li1-3/+5
Since commit c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in x86_cpu_expand_features() instead of cpu_x86_cpuid()") and commit 99a637a86f55 ("i386/cpu: Set and track CPUID_EXT3_CMP_LEG in env->features[FEAT_8000_0001_ECX]"), it gets warnings when booting the VM with vcpus >= 2 and with tcg: qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EDX.ht [bit 28] qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.cmp-legacy [bit 1] This is because, after the two commits, CPUID_HT and CPUID_EXT3_CMP_LEG are set in env->features[] when vcpus >=2 (in x86_cpu_expand_features()) later in x86_cpu_filter_features() it will check against the TCG supported bits. However, current TCG doesn't mark the two bits as supported, hence the warnings. Fix it by adding the two bits to the supported bits of TCG since multiple vcpus are supported by TCG. Fixes: c6bd2dd63420 ("i386/cpu: Set up CPUID_HT in x86_cpu_expand_features() instead of cpu_x86_cpuid()") Fixes: 99a637a86f55 ("i386/cpu: Set and track CPUID_EXT3_CMP_LEG in env->features[FEAT_8000_0001_ECX]") Reported-by: Ewan Hai <ewanhai-oc@zhaoxin.com> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com> Link: https://lore.kernel.org/r/20250514031652.838763-2-xiaoyao.li@intel.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-05-19hw/riscv/virt.c: remove 'long' casts in fmt stringsDaniel Henrique Barboza1-15/+17
We can avoid the 'long' casts by using PRIx64 and HWADDR_PRIx on the fmt strings for uint64_t and hwaddr types. Signed-off-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: <20250429125811.224803-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19hw/riscv/virt.c: use s->memmap in finalize_fdt() functionsDaniel Henrique Barboza1-22/+22
Change create_fdt_pcie(), create_fdt_reset(), create_fdt_uart() and create_fdt_rtc() to use s->memmap in their logic. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250429125811.224803-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19hw/riscv/virt.c: use s->memmap in create_fdt_virtio()Daniel Henrique Barboza1-7/+10
create_fdt_virtio() can use s->memmap instead of having an extra argument for it. While we're at it rewrite it a little bit to avoid the clunky line in 'name' and code repetition: - declare 'virtio_base' out of the loop since it never changes; - declare a 'size' variable. Use it to calculate the address of the virtio device in an 'addr' variable; - use 'addr' in the 'name' g_strdup_printf(); - use 'addr' and 'size' when creating the 'reg' property. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250429125811.224803-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19hw/riscv/virt.c: use s->memmap in create_fdt_sockets() pathDaniel Henrique Barboza1-42/+47
create_fdt_sockets() and all its fdt helpers (create_fdt_socket_aplic(), create_fdt_imsic(), create_fdt_socket_plic(), create_fdt_socket_aclint() and create_fdt_socket_memory()) can use s->memmap from their RISCVVirtState pointer instead of having an extra memmap argument. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250429125811.224803-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19hw/riscv/virt.c: use s->memmap in create_fdt() pathDaniel Henrique Barboza1-9/+10
create_fdt(), create_fdt_flash() and create_fdt_fw_cfg() can access the memmap via their RISCVVirtState pointers. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250429125811.224803-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19hw/riscv/virt.c: add 'base' arg in create_fw_cfg()Daniel Henrique Barboza1-3/+2
The function can receive the value via s->memmap[VIRT_FW_CFG].base from the caller, avoiding the use of virt_memmap. Signed-off-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: <20250429125811.224803-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19hw/riscv/virt.c: use s->memmap in virt_machine_done()Daniel Henrique Barboza1-8/+7
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250429125811.224803-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19hw/riscv/virt.c: remove trivial virt_memmap referencesDaniel Henrique Barboza1-15/+14
We should use s->memmap instead of virt_memmap to be able to use an updated memmap when we start versioning the board. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250429125811.224803-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19hw/riscv/virt.c: enforce s->memmap use in machine_init()Daniel Henrique Barboza1-27/+27
Throughout the code we're accessing the board memmap, most of the time, by accessing it statically via 'virt_memmap'. This static map is also assigned in the machine state in s->memmap. We're also passing it as a variable to some fdt functions, which is unorthodox since we can spare a function argument by accessing it statically or via the machine state. All the current forms are valid but not all of the are scalable. In the future we will version this board, and then all this code will need rework because it should point to the updated memmap. In this case, we'll want to assign the adequate versioned memmap once during init, in s->memmap like it is being done today, and the rest of the code will access the updated map via s->memmap. We're also enforcing the pattern of using s->memmap instead of assigning it to a temp variable 'memmap'. Code is copy/pasted around all the time and being consistent is important. We'll start these rather mechanical changes with virt_machine_init(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-ID: <20250429125811.224803-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19target/riscv/kvm: add scounteren CSRDaniel Henrique Barboza1-0/+2
Add support for the scounteren KVM CSR. Note that env->scounteren is a 32 bit and all KVM CSRs are target_ulong, so scounteren will be capped to 32 bits read/writes. Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250429124421.223883-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19target/riscv/kvm: read/write KVM regs via env sizeDaniel Henrique Barboza1-5/+7
We're going to add support for scounteren in the next patch. KVM defines as a target_ulong CSR, while QEMU defines env->scounteren as a 32 bit field. This will cause the current code to read/write a 64 bit CSR in a 32 bit field when running in a 64 bit CPU. To prevent that, change the current logic to honor the size of the QEMU storage instead of the KVM CSR reg. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20250429124421.223883-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19target/riscv/kvm: add senvcfg CSRDaniel Henrique Barboza1-0/+2
We're missing the senvcfg CSRs which is already present in the KVM UAPI. Reported-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: <20250429124421.223883-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2025-05-19target/riscv/kvm: do not read unavailable CSRsDaniel Henrique Barboza1-3/+59
[1] reports that commit 4db19d5b21 broke a KVM guest running kernel 6.6. This happens because the kernel does not know 'senvcfg', making it unable to boot because QEMU is reading/wriiting it without any checks. After converting the CSRs to do "automated" get/put reg procedures in the previous patch we can now scan for availability. Two functions are created: - kvm_riscv_read_csr_cfg_legacy() will check if the CSR exists by brute forcing KVM_GET_ONE_REG in each one of them, interpreting an EINVAL return as indication that the CSR isn't available. This will be use in absence of KVM_GET_REG_LIST; - kvm_riscv_read_csr_cfg() will use the existing result of get_reg_list to check if the CSRs ids are present. kvm_riscv_init_multiext_cfg() is now kvm_riscv_init_cfg() to reflect that the function is also dealing with CSRs. [1] https://lore.kernel.org/qemu-riscv/CABJz62OfUDHYkQ0T3rGHStQprf1c7_E0qBLbLKhfv=+jb0SYAw@mail.gmail.com/ Fixes: 4db19d5b21 ("target/riscv/kvm: add missing KVM CSRs") Reported-by: Andrea Bolognani <abologna@redhat.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: <20250429124421.223883-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
2025-05-19target/riscv/kvm: add kvm_csr_cfgs[]Daniel Henrique Barboza2-36/+86
At this moment we're not checking if the host has support for any specific CSR before doing get/put regs. This will cause problems if the host KVM doesn't support it (see [1] as an example). We'll use the same approach done with the CPU extensions: read all known KVM CSRs during init() to check for availability, then read/write them if they are present. This will be made by either using get-reglist or by directly reading the CSRs. For now we'll just convert the CSRs to use a kvm_csr_cfg[] array, reusing the same KVMCPUConfig abstraction we use for extensions, and use the array in (get|put)_csr_regs() instead of manually listing them. A lot of boilerplate will be added but at least we'll automate the get/put procedure for CSRs, i.e. adding a new CSR in the future will be a matter of adding it in kvm_csr_regs[] and everything else will be taken care of. Despite all the code changes no behavioral change is made. [1] https://lore.kernel.org/qemu-riscv/CABJz62OfUDHYkQ0T3rGHStQprf1c7_E0qBLbLKhfv=+jb0SYAw@mail.gmail.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: <20250429124421.223883-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
2025-05-19target/riscv/kvm: turn kvm_riscv_reg_id_ulong() into a macroDaniel Henrique Barboza1-58/+41
We need the reg_id_ulong() helper to be a macro to be able to create a static array of KVMCPUConfig that will hold CSR information. Despite the amount of changes all of them are tedious/trivial: - replace instances of "kvm_riscv_reg_id_ulong" with "KVM_RISCV_REG_ID_ULONG"; - RISCV_CORE_REG(), RISCV_CSR_REG(), RISCV_CONFIG_REG() and RISCV_VECTOR_CSR_REG() only receives one 'name' arg. Remove unneeded 'env' variables when applicable. 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: <20250429124421.223883-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
2025-05-19target/riscv/kvm: turn u32/u64 reg functions into macrosDaniel Henrique Barboza1-13/+9
This change is motivated by a future change w.r.t CSRs management. We want to handle them the same way as KVM extensions, i.e. a static array with KVMCPUConfig objs that will be read/write during init and so on. But to do that properly we must be able to declare a static array that hold KVM regs. C does not allow to init static arrays and use functions as initializers, e.g. we can't do: .kvm_reg_id = kvm_riscv_reg_id_ulong(...) When instantiating the array. We can do that with macros though, so our goal is turn kvm_riscv_reg_ulong() in a macro. It is cleaner to turn every other reg_id_*() function in macros, and ulong will end up using the macros for u32 and u64, so we'll start with them. 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: <20250429124421.223883-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
2025-05-19target/riscv/kvm: fix leak in kvm_riscv_init_multiext_cfg()Daniel Henrique Barboza1-1/+1
'reglist' is being g-malloc'ed but never freed. Reported-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20250429124421.223883-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
2025-05-19target/riscv/kvm: minor fixes/tweaksDaniel Henrique Barboza1-15/+14
Remove an unused 'KVMScratchCPU' pointer argument in kvm_riscv_check_sbi_dbcn_support(). Put kvm_riscv_reset_regs_csr() after kvm_riscv_put_regs_csr(). This will make a future patch diff easier to read, when changes in kvm_riscv_reset_regs_csr() and kvm_riscv_get_regs_csr() will be made. Fixes: a6b53378f5 ("target/riscv/kvm: implement SBI debug console (DBCN) calls") 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: <20250429124421.223883-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Cc: qemu-stable@nongnu.org
2025-05-19target/riscv: Fix write_misa vs aligned next_pcRichard Henderson1-5/+17
Do not examine a random host return address, but properly compute the next pc for the guest cpu. Fixes: f18637cd611 ("RISC-V: Add misa runtime write support") Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250425152311.804338-8-richard.henderson@linaro.org> [ Changes by AF: - Change `& ~3` to `& 3` ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>