aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-10-12softmmu: pass the main loop status to gdb "Wxx" packetClément Chigot3-4/+4
gdb_exit function aims to close gdb sessions and sends the exit code of the current execution. It's being called by qemu_cleanup once the main loop is over. Until now, the exit code sent was always 0. Now that hardware can shutdown this main loop with custom exit codes, these codes must be transfered to gdb as well. Signed-off-by: Clément Chigot <chigot@adacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231003071427.188697-3-chigot@adacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12softmmu: add means to pass an exit code when requesting a shutdownClément Chigot2-1/+13
As of now, the exit code was either EXIT_FAILURE when a panic shutdown was requested or EXIT_SUCCESS otherwise. However, some hardware could want to pass more complex exit codes. Thus, introduce a new shutdown request function allowing that. Signed-off-by: Clément Chigot <chigot@adacore.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20231003071427.188697-2-chigot@adacore.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/tcg-cpu.c: add extension properties for all cpusDaniel Henrique Barboza1-14/+50
At this moment we do not expose extension properties for vendor CPUs because that would allow users to change them via command line. The drawback is that if we were to add an API that shows all CPU properties, e.g. qmp-query-cpu-model-expansion, we won't be able to show extensions state of vendor CPUs. We have the required machinery to create extension properties for vendor CPUs while not allowing users to enable extensions. Disabling existing extensions is allowed since it can be useful for debugging. Change the set() callback cpu_set_multi_ext_cfg() to allow enabling extensions only for generic CPUs. In cpu_add_multi_ext_prop() let's not set the default values for the properties if we're not dealing with generic CPUs, otherwise the values set in cpu_init() of vendor CPUs will be overwritten. And finally, in tcg_cpu_instance_init(), add cpu user properties for all CPUs. For the veyron-v1 CPU, we're now able to disable existing extensions like smstateen: $ ./build/qemu-system-riscv64 --nographic -M virt \ -cpu veyron-v1,smstateen=false But setting extensions that the CPU didn't set during cpu_init(), like V, is not allowed: $ ./build/qemu-system-riscv64 --nographic -M virt \ -cpu veyron-v1,v=true qemu-system-riscv64: can't apply global veyron-v1-riscv-cpu.v=true: 'veyron-v1' CPU does not allow enabling extensions Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230926183109.165878-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: add riscv_cpu_get_name()Daniel Henrique Barboza3-1/+15
We'll introduce generic errors that will output a CPU type name via its RISCVCPU pointer. Create a helper for that. Use the helper in tcg_cpu_realizefn() instead of hardcoding the 'host' CPU name. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230926183109.165878-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu: move priv spec functions to tcg-cpu.cDaniel Henrique Barboza3-40/+38
Priv spec validation is TCG specific. Move it to the TCG accel class. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230925175709.35696-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: export isa_edata_arr[]Daniel Henrique Barboza2-26/+28
This array will be read by the TCG accel class, allowing it to handle priv spec verifications on its own. The array will remain here in cpu.c because it's also used by the riscv,isa string function. To export it we'll finish it with an empty element since ARRAY_SIZE() won't work outside of cpu.c. Get rid of its ARRAY_SIZE() usage now to alleviate the changes for the next patch. 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: <20230925175709.35696-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/tcg: move riscv_cpu_add_misa_properties() to tcg-cpu.cDaniel Henrique Barboza3-91/+90
All code related to MISA TCG properties is also moved. At this point, all TCG properties handling is done in tcg-cpu.c, all KVM properties handling is done in kvm-cpu.c. 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: <20230925175709.35696-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: make misa_ext_cfgs[] 'const'Daniel Henrique Barboza1-13/+8
The array isn't marked as 'const' because we're initializing their elements in riscv_cpu_add_misa_properties(), 'name' and 'description' fields. In a closer look we can see that we're not using these 2 fields after creating the MISA properties. And we can create the properties by using riscv_get_misa_ext_name() and riscv_get_misa_ext_description() directly. Remove the 'name' and 'description' fields from RISCVCPUMisaExtConfig and make misa_ext_cfgs[] a const array. 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: <20230925175709.35696-17-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/tcg: introduce tcg_cpu_instance_init()Daniel Henrique Barboza3-151/+149
tcg_cpu_instance_init() will be the 'cpu_instance_init' impl for the TCG accelerator. It'll be called from within riscv_cpu_post_init(), via accel_cpu_instance_init(), similar to what happens with KVM. In fact, to preserve behavior, the implementation will be similar to what riscv_cpu_post_init() already does. In this patch we'll move riscv_cpu_add_user_properties() and riscv_init_max_cpu_extensions() and all their dependencies to tcg-cpu.c. All multi-extension properties code was moved. The 'multi_ext_user_opts' hash table was also moved to tcg-cpu.c since it's a TCG only structure, meaning that we won't have to worry about initializing a TCG hash table when running a KVM CPU anymore. riscv_cpu_add_user_properties() will remain in cpu.c for now due to how much code it requires to be moved at the same time. We'll do that in the next patch. 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: <20230925175709.35696-16-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: export set_misa()Daniel Henrique Barboza2-16/+19
We'll move riscv_init_max_cpu_extensions() to tcg-cpu.c in the next patch and set_misa() needs to be usable from there. Rename it to riscv_cpu_set_misa() and make it public. 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: <20230925175709.35696-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/kvm: do not use riscv_cpu_add_misa_properties()Daniel Henrique Barboza3-9/+18
riscv_cpu_add_misa_properties() is being used to fill the missing KVM MISA properties but it is a TCG helper that was adapted to do so. We'll move it to tcg-cpu.c in the next patches, meaning that KVM needs to fill the remaining MISA properties on its own. Do not use riscv_cpu_add_misa_properties(). Let's create a new array with all available MISA bits we support that can be read by KVM. The array is zero terminate to allow us to iterate through it without knowing its size. Then, inside kvm_riscv_add_cpu_user_properties(), we'll create all KVM MISA properties as usual and then use this array to add any missing MISA properties with the riscv_cpu_add_kvm_unavail_prop() helper. Note that we're creating misa_bits[], and not using the existing 'riscv_single_letter_exts[]', because the latter is tuned for riscv,isa related functions and it doesn't have all MISA bits we support. Commit 0e2c377023 ("target/riscv: misa to ISA string conversion fix") has the full context. While we're at it, move both satp and the multi-letter extension properties to kvm_riscv_add_cpu_user_properties() as well. 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: <20230925175709.35696-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move KVM only files to kvm subdirDaniel Henrique Barboza7-4/+5
Move the files to a 'kvm' dir to promote more code separation between accelerators and making our lives easier supporting build options such as --disable-tcg. Rename kvm.c to kvm-cpu.c to keep it in line with its TCG counterpart. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: introduce KVM AccelCPUClassDaniel Henrique Barboza3-8/+27
Add a KVM accelerator class like we did with TCG. The difference is that, at least for now, we won't be using a realize() implementation for this accelerator. We'll start by assiging kvm_riscv_cpu_add_kvm_properties(), renamed to kvm_cpu_instance_init(), as a 'cpu_instance_init' implementation. Change riscv_cpu_post_init() to invoke accel_cpu_instance_init(), which will go through the 'cpu_instance_init' impl of the current acceleration (if available) and execute it. The end result is that the KVM initial setup, i.e. starting registers and adding its specific properties, will be done via this hook. Add a 'tcg_enabled()' condition in riscv_cpu_post_init() to avoid calling riscv_cpu_add_user_properties() when running KVM. We'll remove this condition when the TCG accel class get its own 'cpu_instance_init' implementation. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: remove kvm-stub.cDaniel Henrique Barboza2-31/+1
This file is not needed for some time now. Both kvm_riscv_reset_vcpu() and kvm_riscv_set_irq() have public declarations in kvm_riscv.h and are wrapped in 'if kvm_enabled()' blocks that the compiler will rip it out in non-KVM builds. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: make riscv_add_satp_mode_properties() publicDaniel Henrique Barboza3-3/+4
This function is used for both accelerators. Make it public, and call it from kvm_riscv_cpu_add_kvm_properties(). This will make it easier to split KVM specific code for the KVM accelerator class in the next patch. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move riscv_cpu_add_kvm_properties() to kvm.cDaniel Henrique Barboza4-84/+86
We'll introduce the KVM accelerator class with a 'cpu_instance_init' implementation that is going to be invoked during the common riscv_cpu_post_init() (via accel_cpu_instance_init()). This instance_init will execute KVM exclusive code that TCG doesn't care about, such as adding KVM specific properties, initing registers using a KVM scratch CPU and so on. The core of the forementioned cpu_instance_init impl is the current riscv_cpu_add_kvm_properties() that is being used by the common code via riscv_cpu_add_user_properties() in cpu.c. Move it to kvm.c, together will all the relevant artifacts, exporting and renaming it to kvm_riscv_cpu_add_kvm_properties() so cpu.c can keep using it for now. To make this work we'll need to export riscv_cpu_extensions, riscv_cpu_vendor_exts and riscv_cpu_experimental_exts from cpu.c as well. The TCG accelerator will also need to access those in the near future so this export will benefit us in the long run. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: mark extensions arrays as 'const'Daniel Henrique Barboza1-9/+13
We'll need to export these arrays to the accelerator classes in the next patches. Mark them as 'const' now because they should not be modified at runtime. Note that 'riscv_cpu_options' will also be exported, but can't be marked as 'const', because the properties are changed via qdev_property_add_static(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move 'host' CPU declaration to kvm.cDaniel Henrique Barboza2-15/+21
This CPU only exists if we're compiling with KVM so move it to the kvm specific file. 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: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: add .instance_post_init()Daniel Henrique Barboza1-11/+32
All generic CPUs call riscv_cpu_add_user_properties(). The 'max' CPU calls riscv_init_max_cpu_extensions(). Both can be moved to a common instance_post_init() callback, implemented in riscv_cpu_post_init(), called by all CPUs. The call order then becomes: riscv_cpu_init() -> cpu_init() of each CPU -> .instance_post_init() In the near future riscv_cpu_post_init() will call the init() function of the current accelerator, providing a hook for KVM and TCG accel classes to change the init() process of the CPU. 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: <20230925175709.35696-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move riscv_tcg_ops to tcg-cpu.cDaniel Henrique Barboza3-63/+59
Move the remaining of riscv_tcg_ops now that we have a working realize() implementation. 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: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move riscv_cpu_validate_set_extensions() to tcg-cpu.cDaniel Henrique Barboza5-357/+397
This function is the core of the RISC-V validations for TCG CPUs, and it has a lot going on. Functions in cpu.c were made public to allow them to be used by the KVM accelerator class later on. 'cpu_cfg_ext_get_min_version()' is notably hard to move it to another file due to its dependency with isa_edata_arr[] array, thus make it public and use it as is for now. riscv_cpu_validate_set_extensions() is kept public because it's used by csr.c in write_misa(). Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: move riscv_cpu_realize_tcg() to TCG::cpu_realizefn()Daniel Henrique Barboza2-128/+133
riscv_cpu_realize_tcg() was added to allow TCG cpus to have a different realize() path during the common riscv_cpu_realize(), making it a good choice to start moving TCG exclusive code to tcg-cpu.c. Rename it to tcg_cpu_realizefn() and assign it as a implementation of accel::cpu_realizefn(). tcg_cpu_realizefn() will then be called during riscv_cpu_realize() via cpu_exec_realizefn(). We'll use a similar approach with KVM in the near future. riscv_cpu_validate_set_extensions() is too big and with too many dependencies to be moved in this same patch. We'll do that next. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Message-ID: <20230925175709.35696-3-dbarboza@ventanamicro.com> [ Changes by AF: - Renames to fix build failures after rebase ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: introduce TCG AccelCPUClassDaniel Henrique Barboza5-4/+67
target/riscv/cpu.c needs to handle all possible accelerators (TCG and KVM at this moment) during both init() and realize() time. This forces us to resort to a lot of "if tcg" and "if kvm" throughout the code, which isn't wrong, but can get cluttered over time. Splitting acceleration specific code from cpu.c to its own file will help to declutter the existing code and it will also make it easier to support KVM/TCG only builds in the future. We'll start by adding a new subdir called 'tcg' and a new file called 'tcg-cpu.c'. This file will be used to introduce a new accelerator class for TCG acceleration in RISC-V, allowing us to center all TCG exclusive code in its file instead of using 'cpu.c' for everything. This design is inpired by the work Claudio Fontana did in x86 a few years ago in commit f5cc5a5c1 ("i386: split cpu accelerators from cpu.c, using AccelCPUClass"). To avoid moving too much code at once we'll start by adding the new file and TCG AccelCPUClass declaration. The 'class_init' from the accel class will init 'tcg_ops', relieving the common riscv_cpu_class_init() from doing it. 'riscv_tcg_ops' is being exported from 'cpu.c' for now to avoid having to deal with moving code and files around right now. We'll focus on decoupling the realize() logic first. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230925175709.35696-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12disas/riscv: Fix the typo of inverted order of pmpaddr13 and pmpaddr14Alvin Chang1-2/+2
Fix the inverted order of pmpaddr13 and pmpaddr14 in csr_name(). Signed-off-by: Alvin Chang <alvinga@andestech.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230907084500.328-1-alvinga@andestech.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: Clear CSR values at reset and sync MPSTATE with hostliguang.zhang2-0/+45
This patch fixes guest reboot errors when using KVM. There are two issues when rebooting a guest using KVM 1. When the guest initiates a reboot the host is unable to stop the vcpu 2. When running a SMP guest the qemu monitor system_reset causes a vcpu crash This can be fixed by clearing the CSR values at reset and syncing the MPSTATE with the host. Signed-off-by: liguang.zhang <liguang.zhang@hexintek.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230913091332.17355-1-18622748025@163.com> [ Changes by AF - Fixup commit message - Fixup patch style ] Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: consider user option with RVGDaniel Henrique Barboza1-2/+16
Enabling RVG will enable a set of extensions that we're not checking if the user was okay enabling or not. And in this case we want to error out, instead of ignoring, otherwise we will be inconsistent enabling RVG without all its extensions. After this patch, disabling ifencei or icsr while enabling RVG will result in error: $ ./build/qemu-system-riscv64 -M virt -cpu rv64,g=true,Zifencei=false --nographic qemu-system-riscv64: RVG requires Zifencei but user set Zifencei to false 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: <20230912132423.268494-21-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: honor user choice in cpu_cfg_ext_auto_update()Daniel Henrique Barboza1-0/+16
Add a new cpu_cfg_ext_is_user_set() helper to check if an extension was set by the user in the command line. Use it inside cpu_cfg_ext_auto_update() to verify if the user set a certain extension and, if that's the case, do not change its value. This will make us honor user choice instead of overwriting the values. Users will then be informed whether they're using an incompatible set of extensions instead of QEMU setting a magic value that works. The reason why we're not implementing user choice for MISA extensions right now is because, today, we do not silently change any MISA bit during realize() time (we do warn when enabling bits if RVG is enabled). We do that - a lot - with multi-letter extensions though, so we're handling the most immediate concern first. After this patch, we'll now error out if the user explicitly set 'zce' to true and 'zca' to false: $ ./build/qemu-system-riscv64 -M virt -cpu rv64,zce=true,zca=false -nographic qemu-system-riscv64: Zcf/Zcd/Zcb/Zcmp/Zcmt extensions require Zca extension This didn't happen before because we were enabling 'zca' if 'zce' was enabled regardless if the user set 'zca' to false. 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: <20230912132423.268494-20-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: use isa_ext_update_enabled() in init_max_cpu_extensions()Daniel Henrique Barboza1-9/+9
Before adding support to detect if an extension was user set we need to handle how we're enabling extensions in riscv_init_max_cpu_extensions(). object_property_set_bool() calls the set() callback for the property, and we're going to use this callback to set the 'multi_ext_user_opts' hash. This means that, as is today, all extensions we're setting for the 'max' CPU will be seen as user set in the future. Let's change set_bool() to isa_ext_update_enabled() that will just enable/disable the flag on a certain offset. 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: <20230912132423.268494-19-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: introduce RISCVCPUMultiExtConfigDaniel Henrique Barboza1-99/+159
If we want to make better decisions when auto-enabling extensions during realize() we need a way to tell if an user set an extension manually. The RISC-V KVM driver has its own solution via a KVMCPUConfig struct that has an 'user_set' flag that is set during the Property set() callback. The set() callback also does init() time validations based on the current KVM driver capabilities. For TCG we would want a 'user_set' mechanic too, but we would look ad-hoc via cpu_cfg_ext_auto_update() if a certain extension was user set or not. If we copy what was made in the KVM side we would look for 'user_set' for one into 60+ extension structs spreaded in 3 arrays (riscv_cpu_extensions, riscv_cpu_experimental_exts, riscv_cpu_vendor_exts). We'll still need an extension struct but we won't be using the 'user_set' flag: - 'RISCVCPUMultiExtConfig' will be our specialized structure, similar to what we're already doing with the MISA extensions in 'RISCVCPUMisaExtConfig'. DEFINE_PROP_BOOL() for all 3 extensions arrays were replaced by MULTI_EXT_CFG_BOOL(), a macro that will init our specialized struct; - the 'multi_ext_user_opts' hash will be used to store the offset of each extension that the user set via the set() callback, cpu_set_multi_ext_cfg(). For now we're just initializing and populating it - next patch will use it to determine if a certain extension was user set; - cpu_add_multi_ext_prop() is a new helper that will replace the qdev_property_add_static() calls that our macros are doing to populate user properties. The macro was renamed to ADD_CPU_MULTIEXT_PROPS_ARRAY() for clarity. Note that the non-extension properties in riscv_cpu_options[] still need to be declared via qdev(). 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: <20230912132423.268494-18-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: use cpu_cfg_ext_auto_update() during realize()Daniel Henrique Barboza1-25/+25
Let's change the other instances in realize() where we're enabling an extension based on a certain criteria (e.g. it's a dependency of another extension). We're leaving icsr and ifencei being enabled during RVG for later - we'll want to error out in that case. Every other extension enablement during realize is now done via cpu_cfg_ext_auto_update(). The end goal is that only cpu init() functions will handle extension flags directly via "cpu->cfg.ext_N = true|false". 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: <20230912132423.268494-17-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: introduce cpu_cfg_ext_auto_update()Daniel Henrique Barboza1-3/+40
During realize() time we're activating a lot of extensions based on some criteria, e.g.: if (cpu->cfg.ext_zk) { cpu->cfg.ext_zkn = true; cpu->cfg.ext_zkr = true; cpu->cfg.ext_zkt = true; } This practice resulted in at least one case where we ended up enabling something we shouldn't: RVC enabling zca/zcd/zcf when using a CPU that has priv_spec older than 1.12.0. We're also not considering user choice. There's no way of doing it now but this is about to change in the next few patches. cpu_cfg_ext_auto_update() will check for priv version mismatches before enabling extensions. If we have a mismatch between the current priv version and the extension we want to enable, do not enable it. In the near future, this same function will also consider user choice when deciding if we're going to enable/disable an extension or not. For now let's use it to handle zca/zcd/zcf enablement if RVC is enabled. 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: <20230912132423.268494-16-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: make CPUCFG() macro publicDaniel Henrique Barboza3-6/+6
The RISC-V KVM driver uses a CPUCFG() macro that calculates the offset of a certain field in the struct RISCVCPUConfig. We're going to use this macro in target/riscv/cpu.c as well in the next patches. Make it public. Rename it to CPU_CFG_OFFSET() for more clarity while we're at it. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-15-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: use offset in isa_ext_is_enabled/update_enabledDaniel Henrique Barboza1-9/+9
We'll have future usage for a function where, given an offset of the struct RISCVCPUConfig, the flag is updated to a certain val. Change all existing callers to use edata->ext_enable_offset instead of 'edata'. 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: <20230912132423.268494-14-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: deprecate the 'any' CPU typeDaniel Henrique Barboza2-0/+17
The 'any' CPU type was introduced in commit dc5bd18fa5725 ("RISC-V CPU Core Definition"), being around since the beginning. It's not an easy CPU to use: it's undocumented and its name doesn't tell users much about what the CPU is supposed to bring. 'git log' doesn't help us either in knowing what was the original design of this CPU type. The closest we have is a comment from Alistair [1] where he recalls from memory that the 'any' CPU is supposed to behave like the newly added 'max' CPU. He also suggested that the 'any' CPU should be removed. The default CPUs are rv32 and rv64, so removing the 'any' CPU will have impact only on users that might have a script that uses '-cpu any'. And those users are better off using the default CPUs or the new 'max' CPU. We would love to just remove the code and be done with it, but one does not simply remove a feature in QEMU. We'll put the CPU in quarantine first, letting users know that we have the intent of removing it in the future. [1] https://lists.gnu.org/archive/html/qemu-devel/2023-07/msg02891.html Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-13-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12avocado, risc-v: add tuxboot tests for 'max' CPUDaniel Henrique Barboza1-0/+32
Add smoke tests to ensure that we'll not break the 'max' CPU type when adding new frozen/ratified RISC-V extensions. 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> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-12-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: add 'max' CPU typeDaniel Henrique Barboza2-0/+57
The 'max' CPU type is used by tooling to determine what's the most capable CPU a current QEMU version implements. Other archs such as ARM implements this type. Let's add it to RISC-V. What we consider "most capable CPU" in this context are related to ratified, non-vendor extensions. This means that we want the 'max' CPU to enable all (possible) ratified extensions by default. The reasoning behind this design is (1) vendor extensions can conflict with each other and we won't play favorities deciding which one is default or not and (2) non-ratified extensions are always prone to changes, not being stable enough to be enabled by default. All this said, we're still not able to enable all ratified extensions due to conflicts between them. Zfinx and all its dependencies aren't enabled because of a conflict with RVF. zce, zcmp and zcmt are also disabled due to RVD conflicts. When running with 64 bits we're also disabling zcf. MISA bits RVG, RVJ and RVV are also being set manually since they're default disabled. This is the resulting 'riscv,isa' DT for this new CPU: rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_ zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_ zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_ smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt 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> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-11-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: limit cfg->vext_spec log messageDaniel Henrique Barboza1-5/+4
Inside riscv_cpu_validate_v() we're always throwing a log message if the user didn't set a vector version via 'vext_spec'. We're going to include one case with the 'max' CPU where env->vext_ver will be set in the cpu_init(). But that alone will not stop the "vector version is not specified" message from appearing. The usefulness of this log message is debatable for the generic CPUs, but for a 'max' CPU type, where we are supposed to deliver a CPU model with all features possible, it's strange to force users to set 'vext_spec' to get rid of this message. Change riscv_cpu_validate_v() to not throw this log message if env->vext_ver is already set. 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> Message-ID: <20230912132423.268494-10-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: add riscv_cpu_add_kvm_unavail_prop_array()Daniel Henrique Barboza1-11/+13
Use a helper in riscv_cpu_add_kvm_properties() to eliminate some of its code repetition. 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: <20230912132423.268494-9-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: add riscv_cpu_add_qdev_prop_array()Daniel Henrique Barboza1-16/+13
The code inside riscv_cpu_add_user_properties() became quite repetitive after recent changes. Add a helper to hide the repetition away. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-8-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[]Daniel Henrique Barboza1-1/+12
Our goal is to make riscv_cpu_extensions[] hold only ratified, non-vendor extensions. Create a new riscv_cpu_vendor_exts[] array for them, changing riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() accordingly. 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: <20230912132423.268494-7-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: split non-ratified exts from riscv_cpu_extensions[]Daniel Henrique Barboza1-1/+12
Create a new riscv_cpu_experimental_exts[] to store the non-ratified extensions properties. Once they are ratified we'll move them back to riscv_cpu_extensions[]. riscv_cpu_add_user_properties() and riscv_cpu_add_kvm_properties() are changed to keep adding non-ratified properties to users. 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: <20230912132423.268494-6-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv: add DEFINE_PROP_END_OF_LIST() to riscv_cpu_options[]Daniel Henrique Barboza1-5/+7
Add DEFINE_PROP_END_OF_LIST() and eliminate the ARRAY_SIZE() usage when iterating in the riscv_cpu_options[] array, making it similar to what we already do when working with riscv_cpu_extensions[]. We also have a more sophisticated motivation behind this change. In the future we might need to export riscv_cpu_options[] to other files, and ARRAY_LIST() doesn't work properly in that case because the array size isn't exposed to the header file. Here's a future sight of what we would deal with: ./target/riscv/kvm.c:1057:5: error: nested extern declaration of 'riscv_cpu_add_misa_properties' [-Werror=nested-externs] n file included from ../target/riscv/kvm.c:19: home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ | ^~~~~~~~~~ ./target/riscv/kvm.c:1059:5: note: in expansion of macro 'ADD_UNAVAIL_KVM_PROP_ARRAY' 1059 | ADD_UNAVAIL_KVM_PROP_ARRAY(obj, riscv_cpu_extensions); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ home/danielhb/work/qemu/include/qemu/osdep.h:473:31: error: invalid application of 'sizeof' to incomplete type 'const RISCVCPUMultiExtConfig[]' 473 | #define ARRAY_SIZE(x) ((sizeof(x) / sizeof((x)[0])) + \ | ^ ./target/riscv/kvm.c:1047:29: note: in expansion of macro 'ARRAY_SIZE' 1047 | for (int i = 0; i < ARRAY_SIZE(_array); i++) { \ Homogenize the present and change the future by using DEFINE_PROP_END_OF_LIST() in riscv_cpu_options[]. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230912132423.268494-5-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: split kvm prop handling to its own helperDaniel Henrique Barboza2-24/+44
Future patches will split the existing Property arrays even further, and the existing code in riscv_cpu_add_user_properties() will start to scale bad with it because it's dealing with KVM constraints mixed in with TCG constraints. We're going to pay a high price to share a couple of common lines of code between the two. Create a new kvm_riscv_cpu_add_kvm_properties() helper that will be forked from riscv_cpu_add_user_properties() if we're running KVM. The helper includes all properties that a KVM CPU will add. The rest of riscv_cpu_add_user_properties() body will then be relieved from having to deal with KVM constraints. The helper was declared in kvm_stubs.h, while being implemented in cpu.c, to allow '--enable-debug' builds to work. The compiler won't remove the kvm_riscv_cpu_add_kvm_properties() reference when 'kvm_enabled()' is false if we end up with an unused function. Even though being a KVM only helper we can't implement it in kvm.c due to its many dependencies inside cpu.c, so make it public in kvm_riscv.h and keep its implementation in cpu.c for now. We'll move it to kvm.c in the near future. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-4-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: skip 'bool' check when filtering KVM propsDaniel Henrique Barboza1-10/+4
After the introduction of riscv_cpu_options[] all properties in riscv_cpu_extensions[] are booleans. This check is now obsolete. 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: <20230912132423.268494-3-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-12target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[]Daniel Henrique Barboza1-10/+23
We'll add a new CPU type that will enable a considerable amount of extensions. To make it easier for us we'll do a few cleanups in our existing riscv_cpu_extensions[] array. Start by splitting all CPU non-boolean options from it. Create a new riscv_cpu_options[] array for them. Add all these properties in riscv_cpu_add_user_properties() as it is already being done today. 'mmu' and 'pmp' aren't really extensions in the usual way we think about RISC-V extensions. These are closer to CPU features/options, so move both to riscv_cpu_options[] too. In the near future we'll need to match all extensions with all entries in isa_edata_arr[], and so it happens that both 'mmu' and 'pmp' do not have a riscv,isa string (thus, no priv spec version restriction). This further emphasizes the point that these are more a CPU option than an extension. No functional changes made. 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> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Message-ID: <20230912132423.268494-2-dbarboza@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2023-10-11Merge tag 'pull-omnibus-111023-1' of https://gitlab.com/stsquad/qemu into ↵Stefan Hajnoczi50-273/+304
staging testing, gdbstub and plugin updates - enable more sbsa-ref tests in avocado - add swtpm to the package lists - reduce avocado noise in gitlab by limiting tests - make docker engine choice driven by configure and enable override - remove unneeded gcc suffix on some cross compilers - fix some NULL returns in gdbstub - improve locking in execlog plugin - introduce the GDBFeature structure - consistently set gdb_core_xml_file - use cleaner escaping for gdb xml - drop ancient gdb_has_xml() test - disable multi-instruction GUSA emulation when plugins enabled - fix some coverity issues in plugins # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmUmVJkACgkQ+9DbCVqe # KkTfNggAiS02FcL3faGjAN9+60xhvEQ3DJjI473hjvFWu0bSkQTjObcQqGc+V7Cw # 9yNtnxOOWB6KdAU8At7HlVqiUXeyTCJB7Att5/UgNUZj63j+cs7PXb4p7cVCcJOc # 17zni22tnmCBcC8wZaz0yj68jaftL3hz1QNUZOmv6CBt42q0+/4g1WKfaJ+w+SbK # T7cJEiMDObm8qeNAAXpDLB+9v3bRDxMZ8hFJ3p3CatQC8jbDrkuH7RrVPHDWiWQx # w0uXpUHlZEOVX23v6+iIoeb8YQW2bZI9UsfeyIHJlENaVgyL200LHgLvvAE4Qd63 # dCtfQUZzj4t9sfoL4XgxaB7G4qtXTg== # =7PLI # -----END PGP SIGNATURE----- # gpg: Signature made Wed 11 Oct 2023 03:54:01 EDT # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * tag 'pull-omnibus-111023-1' of https://gitlab.com/stsquad/qemu: (25 commits) contrib/plugins: fix coverity warning in hotblocks contrib/plugins: fix coverity warning in lockstep contrib/plugins: fix coverity warning in cache plugins: Set final instruction count in plugin_gen_tb_end target/sh4: Disable decode_gusa when plugins enabled accel/tcg: Add plugin_enabled to DisasContextBase gdbstub: Replace gdb_regs with an array gdbstub: Remove gdb_has_xml variable target/ppc: Remove references to gdb_has_xml target/arm: Remove references to gdb_has_xml gdbstub: Use g_markup_printf_escaped() hw/core/cpu: Return static value with gdb_arch_name() target/arm: Move the reference to arm-core.xml gdbstub: Introduce GDBFeature structure contrib/plugins: Use GRWLock in execlog plugins: Check if vCPU is realized gdbstub: Fix target.xml response gdbstub: Fix target_xml initialization configure: remove gcc version suffixes configure: allow user to override docker engine ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-11Merge tag 'migration-20231011-pull-request' of ↵Stefan Hajnoczi16-641/+757
https://gitlab.com/juan.quintela/qemu into staging Migration Pull request (20231011 edition) Hi In this pull request: - Markus RDMA cleanup series - recover fixes from peter - migration capability from fabiano - negative migration test from fabiano. Please, pull. Thanks, Juan. # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCAAdFiEEGJn/jt6/WMzuA0uC9IfvGFhy1yMFAmUmaQ8ACgkQ9IfvGFhy # 1yN9fA//SBnea3Wl2158J673l5aaI8Vp/1PjfzvNdcr/6EQbXZBgug+haQ3n5Hhf # USNRhemrCkpZAGCUf07g9pfF4R/Jsq1OkOrWF4e6gAaZPNU4V5F7VKBk8pmFMLtr # Kk2XgnH2ZPaFEvts0qBrOfvDHH8gOzzjpF2HGrioM8Zr3p1JHz9OqJoSyawLF0U7 # YFTq2jJSgaOQ6ax1+L8hLLuXlmNccBaTWT8Cv0rbPEgcwrJOM/wMfmd6O39ps929 # yS5NnxqqkrprTDjmeGOgOQd0Cy/flinnzmu+BVMO6/ns9Hu6q1TGG6D+DOBdgmHH # jq7Ej5VILtXWOoZtXLHqA1Xt73ciVlmditVupoC+5vtIJou2JseClutOp98qxxzV # llMF7ldHbRTWnu7qIrwv2OINarowR0pIZfkJqBc6dNHHScwMCnX5L9YAvNePEo2V # 1oJpbqW7mmgwdlFAiKFD+AE6qUWxcnzOvPf+fzWrJMi507Kv5nmxQWTHw9dsFs7k # neWnK21t0s2t77+vVBtLlr06JESG+WndzvQsXKZu8Pd0+ASnzpX8pRVzxEPk5EiH # fT9bhXOCvxTTHulznjkOApODE5NF+KlHAFXU87cSIkdi/6JfzcvTe6KeeIPC248Q # jk3nVlhds1xajTcPAK7HF5Ta6R8rNdTZ6q/kFNhLaTGqv9agxDU= # =hekO # -----END PGP SIGNATURE----- # gpg: Signature made Wed 11 Oct 2023 05:21:19 EDT # gpg: using RSA key 1899FF8EDEBF58CCEE034B82F487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" [full] # gpg: aka "Juan Quintela <quintela@trasno.org>" [full] # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * tag 'migration-20231011-pull-request' of https://gitlab.com/juan.quintela/qemu: (65 commits) migration: Add migration_rp_wait|kick() migration: Remember num of ramblocks to sync during recovery qemufile: Always return a verbose error migration: Introduce migrate_has_error() migration: Display error in query-migrate irrelevant of status migration/rdma: Replace flawed device detail dump by tracing migration/rdma: Use error_report() & friends instead of stderr migration/rdma: Downgrade qemu_rdma_cleanup() errors to warnings migration/rdma: Silence qemu_rdma_register_and_get_keys() migration/rdma: Silence qemu_rdma_block_for_wrid() migration/rdma: Don't report received completion events as error migration/rdma: Silence qemu_rdma_reg_control() migration/rdma: Silence qemu_rdma_connect() migration/rdma: Silence qemu_rdma_resolve_host() migration/rdma: Convert qemu_rdma_alloc_pd_cq() to Error migration/rdma: Convert qemu_rdma_post_recv_control() to Error migration/rdma: Convert qemu_rdma_post_send_control() to Error migration/rdma: Convert qemu_rdma_write() to Error migration/rdma: Convert qemu_rdma_write_one() to Error migration/rdma: Convert qemu_rdma_write_flush() to Error ... Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-11Merge tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu ↵Stefan Hajnoczi2-157/+143
into staging Audio es1370 fix & cleanups # -----BEGIN PGP SIGNATURE----- # # iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmUmQIQcHG1hcmNhbmRy # ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5UiED/0VjK4J6I+MYljyJePj # ki62XC/dtojuxkE+nwsTrU54u86776TLmthRYyHOffSs8mDpk0ynY6sWD99T4r1b # 9Szmm9FJM658RSpN9i128JAiHKD9Vth7UUpekrLIBgRsW5lGuQFapHouTB1wa3hm # 8ZszUNAGEpAgGM2My9t+pvGy8lrOZan2ZAlQzKfMc+msYTnivK6huzjVw/xUc0kD # vzfpVMgKntvl391IBf9hFBBrJCWRtDrydtPl1/PxpVj/96FGIxlx+o30X8z9hSzA # yg96XfwmS/mgqFsw8QqtFyrkSE3iD2yzcrepjtK+erwcv6M0BVG38wn89F571Lcl # Ga8PcqBd7pP0nMXrgjbX8qB6t58TPipEbFMeS2iabO4pwz0jy9aCVQJ2GZqHNqaF # VoMN5hEDBhanxFcNEcjSWZEfJOvK7uVLAZ2Xdqcrsm50ESTu55H/BIQWFipTGlqu # +BlvfpwVYXGziuDsj8h4cUGvyuMY02XWsBU9qvl5aCiyWoyED0ZlR2UJ0jVjn68K # RUbTrxSMF9hLgI1j8FYkNgXMBuR4+Sopc7vp//AXpp92/yxTNCbe44Y06C9iaib1 # 0zrYhd4rfTn0MX+YM9IUKzvoNSVY6VxHoTucyTM9HcT7XtCnmwnMzjY4yGxQ6k3V # X0WBPpH4mCyXla7TJ0zwbnvH0A== # =B/KL # -----END PGP SIGNATURE----- # gpg: Signature made Wed 11 Oct 2023 02:28:20 EDT # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * tag 'audio-pull-request' of https://gitlab.com/marcandre.lureau/qemu: hw/audio/es1370: trace lost interrupts hw/audio/es1370: change variable type and name hw/audio/es1370: block structure coding style fixes hw/audio/es1370: remove #ifdef ES1370_VERBOSE to avoid bit rot hw/audio/es1370: remove #ifdef ES1370_DEBUG to avoid bit rot hw/audio/es1370: remove unused dolog macro hw/audio/es1370: replace bit-rotted code with tracepoints hw/audio/es1370: reset current sample counter Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-10-11migration: Add migration_rp_wait|kick()Peter Xu3-11/+34
It's just a simple wrapper for rp_sem on either wait() or kick(), make it even clearer on how it is used. Prepared to be used even for other things. Reviewed-by: Fabiano Rosas <farosas@suse.de> Signed-off-by: Peter Xu <peterx@redhat.com> Message-ID: <20231004220240.167175-8-peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2023-10-11migration: Remember num of ramblocks to sync during recoveryPeter Xu1-3/+14
Instead of only relying on the count of rp_sem, make the counter be part of RAMState so it can be used in both threads to synchronize on the process. rp_sem will be further reused in follow up patches, as a way to kick the main thread, e.g., on recovery failures. Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231004220240.167175-7-peterx@redhat.com>
generated by cgit v1.1 at 2025-01-28 13:50:53 +0000