summary refs log tree commit diff stats
path: root/rust/qemu-api-macros/src (unfollow)
Commit message (Collapse)AuthorFilesLines
2024-11-05crypto: fix error check on gcry_md_openDaniel P. Berrangé1-2/+2
Gcrypt does not return negative values on error, it returns non-zero values. This caused QEMU not to detect failure to open an unsupported hash, resulting in a later crash trying to use a NULL context. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2024-11-05crypto: Introduce SM3 hash hmac pbkdf algorithmliequan che13-1/+135
Introduce the SM3 cryptographic hash algorithm (GB/T 32905-2016). SM3 (GB/T 32905-2016) is a cryptographic standard issued by the Organization of State Commercial Cryptography Administration (OSCCA) as an authorized cryptographic algorithm for use within China. Detect the SM3 cryptographic hash algorithm and enable the feature silently if it is available. Signed-off-by: cheliequan <cheliequan@inspur.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2024-11-05crypto: purge 'loaded' property that was not fully removedDaniel P. Berrangé6-161/+7
The 'loaded' property on TLS creds and secret objects was marked as deprecated in 6.0.0. In 7.1.0 the deprecation info was moved into the 'removed-features.rst' file, but the property was not actually removed, just made read-only. This was a highly unusual practice, so finish the long overdue removal job. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2024-11-05vfio/migration: Add vfio_save_block_precopy_empty_hit trace eventMaciej S. Szmigiero3-0/+10
This way it is clearly known when there's no more data to send for that device. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
2024-11-05vfio/migration: Add save_{iterate, complete_precopy}_start trace eventsMaciej S. Szmigiero3-0/+13
This way both the start and end points of migrating a particular VFIO device are known. Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
2024-11-05tests/tcg: Add SIGRTMIN/SIGRTMAX testIlya Leoshkevich2-2/+76
Test the lowest and the highest real-time signals. This requires configuring the real-time signal mapping, and therefore some knowledge about the host. To this end, pass the emulator path in the QEMU environment variable to all tests (this should not disturb the existing ones), and assume that all hosts have signals 36-39 available. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Message-ID: <20241029232211.206766-3-iii@linux.ibm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-11-05linux-user: Allow custom rt signal mappingsIlya Leoshkevich6-23/+106
Some applications want to use low priority realtime signals (e.g., SIGRTMAX). Currently QEMU cannot map all target realtime signals to host realtime signals, and chooses to sacrifice the end of the target realtime signal range. Allow users to choose how to map target realtime signals to host realtime signals using the new -t option, the new QEMU_RTSIG_MAP environment variable, and the new -Drtsig_map=\"...\" meson flag. To simplify things, the meson flag is not per-target, because the intended use case is app-specific qemu-user builds. The mapping is specified using the "tsig hsig count[,...]" syntax. Target realtime signals [tsig,tsig+count) are mapped to host realtime signals [hsig,hsig+count). Care is taken to avoid double and out-of-range mappings. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20241029232211.206766-2-iii@linux.ibm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-11-05linux-user: Fix GDB complaining about system-supplied DSO string table indexIlya Leoshkevich2-51/+87
When debugging qemu-user processes using gdbstub, the following warning appears every time: warning: BFD: warning: system-supplied DSO at 0x7f8253cc3000 has a corrupt string table index The reason is that QEMU does not map the VDSO's section headers. The VDSO's ELF header's e_shoff points to zeros, which GDB fails to parse. The difference with the kernel's VDSO is that the latter is mapped as a blob, ignoring program headers - which also don't cover the section table. QEMU, on the other hand, loads it as an ELF file. There appears to be no way to place section headers inside a section, and, therefore, no way to refer to them from a linker script. Also, ld hardcodes section headers to be non-loadable, see _bfd_elf_assign_file_positions_for_non_load(). In theory ld could be enhanced by implementing an "SHDRS" keyword in addition to the existing "FILEHDR" and "PHDRS". There are multiple ways to resolve the issue: - Copy VDSO as a blob in load_elf_vdso(). This would require creating specialized loader logic, that duplicates parts of load_elf_image(). - Fix up VDSO's PHDR size in load_elf_vdso(). This would require either duplicating the parsing logic, or adding an ugly parameter to load_elf_image(). - Fix up VDSO's PHDR size in gen-vdso. This is the simplest solution, so do it. There are two tricky parts: - Byte-swaps need to be done either on local copies, or in-place and then reverted in the end. To preserve the existing code structure, do the former for Sym and Dyn, and the latter for Ehdr, Phdr, and Shdr. - There must be no .bss, which is already the case - but having an explicit check is helpful to ensure correctness. To verify this change, I diffed the on-disk and the loaded VDSOs; the result does not show anything unusual, except for what seems to be an existing oversight (which should probably be fixed separately): │ Symbol table '.dynsym' contains 8 entries: │ Num: Value Size Type Bind Vis Ndx Name │ - 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND │ - 6: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.29 │ + 0: 00007f61075bf000 0 NOTYPE LOCAL DEFAULT UND │ + 6: 00007f61075bf000 0 OBJECT GLOBAL DEFAULT ABS LINUX_2.6.29 Fixes: 2fa536d10797 ("linux-user: Add gen-vdso tool") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20241023202850.55211-1-iii@linux.ibm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-11-05tests/tcg: Replace -mpower8-vector with -mcpu=power8Ilya Leoshkevich1-5/+5
[1] deprecated -mpower8-vector, resulting in: powerpc64-linux-gnu-gcc: warning: switch '-mpower8-vector' is no longer supported qemu/tests/tcg/ppc64/vsx_f2i_nan.c:4:15: error: expected ';' before 'float' 4 | typedef vector float vsx_float32_vec_t; | ^~~~~~ Use -mcpu=power8 instead. In order to properly verify that this works, one needs a big-endian (the minimum supported CPU for 64-bit little-endian is power8 anyway) GCC configured with --enable-checking (see GCC commit e154242724b0 ("[RS6000] Don't pass -many to the assembler"). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987 Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Acked-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20241023131250.48510-1-iii@linux.ibm.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-11-05target/arm: Enable FEAT_CMOW for -cpu maxGustavo Romero5-0/+13
FEAT_CMOW introduces support for controlling cache maintenance instructions executed in EL0/1 and is mandatory from Armv8.8. On real hardware, the main use for this feature is to prevent processes from invalidating or flushing cache lines for addresses they only have read permission, which can impact the performance of other processes. QEMU implements all cache instructions as NOPs, and, according to rule [1], which states that generating any Permission fault when a cache instruction is implemented as a NOP is implementation-defined, no Permission fault is generated for any cache instruction when it lacks read and write permissions. QEMU does not model any cache topology, so the PoU and PoC are before any cache, and rules [2] apply. These rules state that generating any MMU fault for cache instructions in this topology is also implementation-defined. Therefore, for FEAT_CMOW, we do not generate any MMU faults either, instead, we only advertise it in the feature register. [1] Rule R_HGLYG of section D8.14.3, Arm ARM K.a. [2] Rules R_MZTNR and R_DNZYL of section D8.14.3, Arm ARM K.a. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241104142606.941638-1-gustavo.romero@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-11-05hw/net/npcm_gmac: Change error log to trace eventNabih Estefan2-3/+3
Convert the LOG_GUEST_ERROR for the "tx descriptor is owned by software" to a trace message. This condition is normal when there is there is nothing to transmit, and we would otherwise spam the logs with it in that situation. Signed-off-by: Nabih Estefan <nabihestefan@google.com> Signed-off-by: Roque Arcudia Hernandez <roqueh@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241014184847.1594056-1-roqueh@google.com [PMM: tweaked commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-11-05hw/sensor/tmp105: Convert printf() to trace event, add tracing for ↵Bernhard Beschow4-1/+14
read/write access printf() unconditionally prints to the console which disturbs `-serial stdio`. Fix that by converting into a trace event. While at it, add some tracing for read and write access. Fixes: 7e7c5e4c1ba5 "Nokia N800 machine support (ARM)." Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241103143330.123596-5-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-11-05hw/watchdog/wdt_imx2: Remove redundant assignmentBernhard Beschow1-1/+0
The same statement is executed unconditionally right before the if statement. Cc: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241103143330.123596-4-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-11-05hw/timer/imx_gpt: Convert DPRINTF to trace eventsBernhard Beschow2-13/+11
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-id: 20241103143330.123596-3-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-11-05hw/rtc/ds1338: Trace send and receive operationsBernhard Beschow2-0/+10
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-id: 20241103143330.123596-2-shentey@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-11-05disas: Fix build against Capstone v6 (again)Richard Henderson1-0/+1
Like 9971cbac2f3, which set CAPSTONE_AARCH64_COMPAT_HEADER, also set CAPSTONE_SYSTEMZ_COMPAT_HEADER. Fixes the build against capstone v6-alpha. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org> Message-id: 20241022013047.830273-1-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-11-05target/arm: Fix SVE SDOT/UDOT/USDOT (4-way, indexed)Peter Maydell1-1/+8
Our implementation of the indexed version of SVE SDOT/UDOT/USDOT got the calculation of the inner loop terminator wrong. Although we correctly account for the element size when we calculate the terminator for the first iteration: intptr_t segend = MIN(16 / sizeof(TYPED), opr_sz_n); we don't do that when we move it forward after the first inner loop completes. The intention is that we process the vector in 128-bit segments, which for a 64-bit element size should mean (1, 2), (3, 4), (5, 6), etc. This bug meant that we would iterate (1, 2), (3, 4, 5, 6), (7, 8, 9, 10) etc and apply the wrong indexed element to some of the operations, and also index off the end of the vector. You don't see this bug if the vector length is small enough that we don't need to iterate the outer loop, i.e. if it is only 128 bits, or if it is the 64-bit special case from AA32/AA64 AdvSIMD. If the vector length is 256 bits then we calculate the right results for the elements in the vector but do index off the end of the vector. Vector lengths greater than 256 bits see wrong answers. The instructions that produce 32-bit results behave correctly. Fix the recalculation of 'segend' for subsequent iterations, and restore a version of the comment that was lost in the refactor of commit 7020ffd656a5 that explains why we only need to clamp segend to opr_sz_n for the first iteration, not the later ones. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2595 Fixes: 7020ffd656a5 ("target/arm: Macroize helper_gvec_{s,u}dot_idx_{b,h}") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241101185544.2130972-1-peter.maydell@linaro.org
2024-11-05target/arm: Add new MMU indexes for AArch32 Secure PL1&0Peter Maydell6-20/+86
Our current usage of MMU indexes when EL3 is AArch32 is confused. Architecturally, when EL3 is AArch32, all Secure code runs under the Secure PL1&0 translation regime: * code at EL3, which might be Mon, or SVC, or any of the other privileged modes (PL1) * code at EL0 (Secure PL0) This is different from when EL3 is AArch64, in which case EL3 is its own translation regime, and EL1 and EL0 (whether AArch32 or AArch64) have their own regime. We claimed to be mapping Secure PL1 to our ARMMMUIdx_EL3, but didn't do anything special about Secure PL0, which meant it used the same ARMMMUIdx_EL10_0 that NonSecure PL0 does. This resulted in a bug where arm_sctlr() incorrectly picked the NonSecure SCTLR as the controlling register when in Secure PL0, which meant we were spuriously generating alignment faults because we were looking at the wrong SCTLR control bits. The use of ARMMMUIdx_EL3 for Secure PL1 also resulted in the bug that we wouldn't honour the PAN bit for Secure PL1, because there's no equivalent _PAN mmu index for it. Fix this by adding two new MMU indexes: * ARMMMUIdx_E30_0 is for Secure PL0 * ARMMMUIdx_E30_3_PAN is for Secure PL1 when PAN is enabled The existing ARMMMUIdx_E3 is used to mean "Secure PL1 without PAN" (and would be named ARMMMUIdx_E30_3 in an AArch32-centric scheme). These extra two indexes bring us up to the maximum of 16 that the core code can currently support. This commit: * adds the new MMU index handling to the various places where we deal in MMU index values * adds assertions that we aren't AArch32 EL3 in a couple of places that currently use the E10 indexes, to document why they don't also need to handle the E30 indexes * documents in a comment why regime_has_2_ranges() doesn't need updating Notes for backporting: this commit depends on the preceding revert of 4c2c04746932; that revert and this commit should probably be backported to everywhere that we originally backported 4c2c04746932. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2326 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2588 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241101142845.1712482-3-peter.maydell@linaro.org
2024-11-05Revert "target/arm: Fix usage of MMU indexes when EL3 is AArch32"Peter Maydell8-81/+34
This reverts commit 4c2c0474693229c1f533239bb983495c5427784d. This commit tried to fix a problem with our usage of MMU indexes when EL3 is AArch32, using what it described as a "more complicated approach" where we share the same MMU index values for Secure PL1&0 and NonSecure PL1&0. In theory this should work, but the change didn't account for (at least) two things: (1) The design change means we need to flush the TLBs at any point where the CPU state flips from one to the other. We already flush the TLB when SCR.NS is changed, but we don't flush the TLB when we take an exception from NS PL1&0 into Mon or when we return from Mon to NS PL1&0, and the commit didn't add any code to do that. (2) The ATS12NS* address translate instructions allow Mon code (which is Secure) to do a stage 1+2 page table walk for NS. I thought this was OK because do_ats_write() does a page table walk which doesn't use the TLBs, so because it can pass both the MMU index and also an ARMSecuritySpace argument we can tell the table walk that we want NS stage1+2, not S. But that means that all the code within the ptw that needs to find e.g. the regime EL cannot do so only with an mmu_idx -- all these functions like regime_sctlr(), regime_el(), etc would need to pass both an mmu_idx and the security_space, so they can tell whether this is a translation regime controlled by EL1 or EL3 (and so whether to look at SCTLR.S or SCTLR.NS, etc). In particular, because regime_el() wasn't updated to look at the ARMSecuritySpace it would return 1 even when the CPU was in Monitor mode (and the controlling EL is 3). This meant that page table walks in Monitor mode would look at the wrong SCTLR, TCR, etc and would generally fault when they should not. Rather than trying to make the complicated changes needed to rescue the design of 4c2c04746932, we revert it in order to instead take the route that that commit describes as "the most straightforward" fix, where we add new MMU indexes EL30_0, EL30_3, EL30_3_PAN to correspond to "Secure PL1&0 at PL0", "Secure PL1&0 at PL1", and "Secure PL1&0 at PL1 with PAN". This revert will re-expose the "spurious alignment faults in Secure PL0" issue #2326; we'll fix it again in the next commit. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Tested-by: Thomas Huth <thuth@redhat.com> Message-id: 20241101142845.1712482-2-peter.maydell@linaro.org Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2024-11-05softfloat: Remove fallback rule from pickNaN()Peter Maydell2-27/+6
Now that all targets have been converted to explicitly set a NaN propagation rule, we can remove the set of target ifdefs (which now list every target) and clean up the references to fallback behaviour for float_2nan_prop_none. The "default" case in the switch will catch any remaining places where status->float_2nan_prop_rule was not set by the target. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-22-peter.maydell@linaro.org
2024-11-05target/rx: Explicitly set 2-NaN propagation rulePeter Maydell2-1/+9
Set the NaN propagation rule explicitly for the float_status word used in the rx target. This not the architecturally correct behaviour, but since this is a no-behaviour-change patch, we leave a TODO note to that effect. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-21-peter.maydell@linaro.org
2024-11-05target/openrisc: Explicitly set 2-NaN propagation rulePeter Maydell2-1/+7
Set the NaN propagation rule explicitly for the float_status word used in the openrisc target. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-20-peter.maydell@linaro.org
2024-11-05target/microblaze: Explicitly set 2-NaN propagation rulePeter Maydell2-1/+7
Set the NaN propagation rule explicitly for the float_status word used in the microblaze target. This is probably not the architecturally correct behaviour, but since this is a no-behaviour-change patch, we leave a TODO note to that effect. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-19-peter.maydell@linaro.org
2024-11-05target/microblaze: Move setting of float rounding mode to resetPeter Maydell1-3/+2
Although the floating point rounding mode for Microblaze is always nearest-even, we cannot set it just once in the CPU initfn. This is because env->fp_status is in the part of the CPU state struct that is zeroed on reset. Move the call to set_float_rounding_mode() into the reset fn. (This had no guest-visible effects because it happens that the float_round_nearest_even enum value is 0, so when the struct was zeroed it didn't corrupt the setting.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-18-peter.maydell@linaro.org
2024-11-05target/alpha: Explicitly set 2-NaN propagation rulePeter Maydell2-1/+12
Set the NaN propagation rule explicitly for the float_status word used in this target. This is a no-behaviour-change commit, so we retain the existing behaviour of x87-style pick-largest-significand NaN propagation. This is however not the architecturally correct handling, so we leave a TODO note to that effect. We also leave a TODO note pointing out that all this code in the cpu initfn (including the existing setting up of env->flags and the FPCR) should be in a currently non-existent CPU reset function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-17-peter.maydell@linaro.org
2024-11-05target/i386: Set 2-NaN propagation rule explicitlyPeter Maydell4-1/+49
Set the NaN propagation rule explicitly for the float_status words used in the x86 target. This is a no-behaviour-change commit, so we retain the existing behaviour of using the x87-style "prefer QNaN over SNaN, then prefer the NaN with the larger significand" for MMX and SSE. This is however not the documented hardware behaviour, so we leave a TODO note about what we should be doing instead. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-16-peter.maydell@linaro.org
2024-11-05target/xtensa: Explicitly set 2-NaN propagation rulePeter Maydell2-11/+3
Set the NaN propagation rule explicitly in xtensa_use_first_nan(). (When we convert the softfloat pickNaNMulAdd routine to also select a NaN propagation rule at runtime, we will be able to remove the use_first_nan flag because the propagation rules will handle everything.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-15-peter.maydell@linaro.org
2024-11-05target/xtensa: Factor out calls to set_use_first_nan()Peter Maydell3-15/+26
In xtensa we currently call set_use_first_nan() in a lot of places where we want to switch the NaN-propagation handling. We're about to change the softfloat API we use to do that, so start by factoring all the calls out into a single xtensa_use_first_nan() function. The bulk of this change was done with sed -i -e 's/set_use_first_nan(\([^,]*\),[^)]*)/xtensa_use_first_nan(env, \1)/' target/xtensa/fpu_helper.c Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-14-peter.maydell@linaro.org
2024-11-05target/sparc: Explicitly set 2-NaN propagation rulePeter Maydell3-6/+18
Set the NaN propagation rule explicitly in the float_status words we use. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-13-peter.maydell@linaro.org
2024-11-05target/sparc: Move cpu_put_fsr(env, 0) call to resetPeter Maydell1-1/+1
Currently we call cpu_put_fsr(0) in sparc_cpu_realizefn(), which initializes various fields in the CPU struct: * fsr_cexc_ftt * fcc[] * fsr_qne * fsr It also sets the rounding mode in env->fp_status. This is largely pointless, because when we later reset the CPU this will zero out all the fields up until the "end_reset_fields" label, which includes all of these (but not fp_status!) Move the cpu_put_fsr(env, 0) call to reset, because that expresses the logical requirement: we want to reset FSR to 0 on every reset. This isn't a behaviour change because the fields are all zero anyway. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-12-peter.maydell@linaro.org
2024-11-05target/m68k: Initialize float_status fields in gdb set/get functionsPeter Maydell1-2/+2
In cf_fpu_gdb_get_reg() and cf_fpu_gdb_set_reg() we use a temporary float_status variable to pass to floatx80_to_float64() and float64_to_floatx80(), but we don't initialize it, meaning that those functions could access uninitialized data. Zero-init the structs. (We don't need to set a NaN-propagation rule here because we don't use these with a 2-argument fpu operation.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-11-peter.maydell@linaro.org
2024-11-05target/m68k: Explicitly set 2-NaN propagation rulePeter Maydell3-18/+18
Explicitly set the 2-NaN propagation rule on env->fp_status and on the temporary fp_status that we use in frem (since we pass that to a division operation function). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-11-05target/ppc: Explicitly set 2-NaN propagation rulePeter Maydell2-8/+10
Set the 2-NaN propagation rule explicitly in env->fp_status and env->vec_status. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-9-peter.maydell@linaro.org
2024-11-05target/s390x: Explicitly set 2-NaN propagation rulePeter Maydell2-3/+3
Set the 2-NaN propagation rule explicitly in env->fpu_status. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-8-peter.maydell@linaro.org
2024-11-05target/hppa: Explicitly set 2-NaN propagation rulePeter Maydell2-2/+8
Set the 2-NaN propagation rule explicitly in env->fp_status. Really we only need to do this at CPU reset (after reset has zeroed out most of the CPU state struct, which typically includes fp_status fields). However target/hppa does not currently implement CPU reset at all, so leave a TODO comment to note that this could be moved if we ever do implement reset. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-7-peter.maydell@linaro.org
2024-11-05target/loongarch: Explicitly set 2-NaN propagation rulePeter Maydell2-3/+4
Set the 2-NaN propagation rule explicitly in the float_status word we use. (There are a couple of places in fpu_helper.c where we create a dummy float_status word with "float_status *s = { };", but these are only used for calling float*_is_quiet_nan() so it doesn't matter that we don't set a 2-NaN propagation rule there.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-6-peter.maydell@linaro.org
2024-11-05target/mips: Explicitly set 2-NaN propagation rulePeter Maydell4-17/+42
Set the 2-NaN propagation rule explicitly in the float_status words we use. For active_fpu.fp_status, we do this in a new fp_reset() function which mirrors the existing msa_reset() function in doing "first call restore to set the fp status parts that depend on CPU state, then set the fp status parts that are constant". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241025141254.2141506-5-peter.maydell@linaro.org
2024-11-05target/arm: Explicitly set 2-NaN propagation rulePeter Maydell3-19/+37
Set the 2-NaN propagation rule explicitly in the float_status words we use. We wrap this plus the pre-existing setting of the tininess-before-rounding flag in a new function arm_set_default_fp_behaviours() to avoid repetition, since we have a lot of float_status words at this point. The situation with FPA11 emulation in linux-user is a little odd, and arguably "correct" behaviour there would be to exactly match a real Linux kernel's FPA11 emulation. However FPA11 emulation is essentially dead at this point and so it seems better to continue with QEMU's current behaviour and leave a comment describing the situation. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-4-peter.maydell@linaro.org
2024-11-05tests/fp: Explicitly set 2-NaN propagation rulePeter Maydell3-0/+5
Explicitly set a 2-NaN propagation rule in the softfloat tests. In meson.build we put -DTARGET_ARM in fpcflags, and so we should select here the Arm propagation rule of float_2nan_prop_s_ab. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-3-peter.maydell@linaro.org
2024-11-05softfloat: Allow 2-operand NaN propagation rule to be set at runtimePeter Maydell3-95/+183
IEEE 758 does not define a fixed rule for which NaN to pick as the result if both operands of a 2-operand operation are NaNs. As a result different architectures have ended up with different rules for propagating NaNs. QEMU currently hardcodes the NaN propagation logic into the binary because pickNaN() has an ifdef ladder for different targets. We want to make the propagation rule instead be selectable at runtime, because: * this will let us have multiple targets in one QEMU binary * the Arm FEAT_AFP architectural feature includes letting the guest select a NaN propagation rule at runtime * x86 specifies different propagation rules for x87 FPU ops and for SSE ops, and specifying the rule in the float_status would let us emulate this, instead of wrongly using the x87 rules everywhere In this commit we add an enum for the propagation rule, the field in float_status, and the corresponding getters and setters. We change pickNaN to honour this, but because all targets still leave this field at its default 0 value, the fallback logic will pick the rule type with the old ifdef ladder. It's valid not to set a propagation rule if default_nan_mode is enabled, because in that case there's no need to pick a NaN; all the callers of pickNaN() catch this case and skip calling it. So we can already assert that we don't get into the "no rule defined" codepath for our four targets which always set default_nan_mode: Hexagon, RiscV, SH4 and Tricore, and for the one target which does not have FP at all: avr. These targets will not need to be updated to call set_float_2nan_prop_rule(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20241025141254.2141506-2-peter.maydell@linaro.org
2024-11-05contrib/plugins: remove Makefile for contrib/pluginsPierrick Bouvier3-115/+0
Now replaced by meson build. Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-Id: <20241023212812.1376972-4-pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2024-11-05meson: build contrib/plugins with mesonPierrick Bouvier2-0/+32
Tried to unify this meson.build with tests/tcg/plugins/meson.build but the resulting modules are not output in the right directory. Originally proposed by Anton Kochkov, thank you! Solves: https://gitlab.com/qemu-project/qemu/-/issues/1710 Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-Id: <20241023212812.1376972-3-pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2024-11-05contrib/plugins/cflow: fix warningPierrick Bouvier1-3/+3
contrib/plugins/cflow.c: In function ‘plugin_exit’: contrib/plugins/cflow.c:167:19: error: declaration of ‘n’ shadows a previous local [-Werror=shadow=local] 167 | NodeData *n = l->data; | ^ contrib/plugins/cflow.c:139:9: note: shadowed declaration is here 139 | int n = 0; | ^ Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Message-Id: <20241023212812.1376972-2-pierrick.bouvier@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
2024-11-04bsd-user: Set TaskState ts_tid for initial threadsJessica Clarke1-0/+1
Currently we only set it on fork. Note: Upstream (blitz) commit also did new threads, but that code isn't in qemu project repo yet. Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com> Pull-Request: https://github.com/qemu-bsd-user/qemu-bsd-user/pull/52 Reviewed-by: Warner Losh <imp@bsdimp.com> Signed-off-by: Warner Losh <imp@bsdimp.com>
2024-11-04bsd-user/main: Allow setting tb-sizeIlya Leoshkevich1-0/+9
While qemu-system can set tb-size using -accel tcg,tb-size=n, there is no similar knob for qemu-bsd-user. Add one in a way similar to how one-insn-per-tb is already handled. Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Warner Losh <imp@bsdimp.com> Signed-off-by: Warner Losh <imp@bsdimp.com>
2024-11-04bsd-user/x86_64/target_arch_thread.h: Align stackIlya Leoshkevich1-1/+1
bsd-user qemu-x86_64 almost immediately dies with: qemu: 0x4002201a68: unhandled CPU exception 0xd - aborting on FreeBSD 14.1-RELEASE. This is an instruction that requires alignment: (gdb) x/i 0x4002201a68 0x4002201a68: movaps %xmm0,-0x40(%rbp) and the argument is not aligned: (gdb) p/x env->regs[5] $1 = 0x822443b58 A quick experiment shows that the userspace entry point expects misaligned rsp: (gdb) starti (gdb) p/x $rsp $1 = 0x7fffffffeaa8 Emulate this behavior in bsd-user. [[ applied Richard's suggestion ]] Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Warner Losh <imp@bsdimp.com> Signed-off-by: Warner Losh <imp@bsdimp.com>
2024-11-04intel_iommu: Add missed reserved bit check for IEC descriptorZhenzhong Duan2-0/+11
IEC descriptor is 128-bit invalidation descriptor, must be padded with 128-bits of 0s in the upper bytes to create a 256-bit descriptor when the invalidation queue is configured for 256-bit descriptors (IQA_REG.DW=1). Fixes: 02a2cbc872df ("x86-iommu: introduce IEC notifiers") Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20241104125536.1236118-4-zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-11-04intel_iommu: Add missed sanity check for 256-bit invalidation queueZhenzhong Duan2-22/+59
According to VTD spec, a 256-bit descriptor will result in an invalid descriptor error if submitted in an IQ that is setup to provide hardware with 128-bit descriptors (IQA_REG.DW=0). Meanwhile, there are old inv desc types (e.g. iotlb_inv_desc) that can be either 128bits or 256bits. If a 128-bit version of this descriptor is submitted into an IQ that is setup to provide hardware with 256-bit descriptors will also result in an invalid descriptor error. The 2nd will be captured by the tail register update. So we only need to focus on the 1st. Because the reserved bit check between different types of invalidation desc are common, so introduce a common function vtd_inv_desc_reserved_check() to do all the checks and pass the differences as parameters. With this change, need to replace error_report_once() call with error_report() to catch different call sites. This isn't an issue as error_report_once() here is mainly used to help debug guest error, but it only dumps once in qemu life cycle and doesn't help much, we need error_report() instead. Fixes: c0c1d351849b ("intel_iommu: add 256 bits qi_desc support") Suggested-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20241104125536.1236118-3-zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-11-04intel_iommu: Send IQE event when setting reserved bit in IQT_TAILZhenzhong Duan1-0/+1
According to VTD spec, Figure 11-22, Invalidation Queue Tail Register, "When Descriptor Width (DW) field in Invalidation Queue Address Register (IQA_REG) is Set (256-bit descriptors), hardware treats bit-4 as reserved and a value of 1 in the bit will result in invalidation queue error." Current code missed to send IQE event to guest, fix it. Fixes: c0c1d351849b ("intel_iommu: add 256 bits qi_desc support") Suggested-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Message-Id: <20241104125536.1236118-2-zhenzhong.duan@intel.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-11-04hw/acpi: Update GED with vCPU Hotplug VMSD for migrationSalil Mehta1-0/+19
The ACPI CPU hotplug states must be migrated along with other vCPU hotplug states to the destination VM. Update the GED's VM State Description (VMSD) table subsection to conditionally include the CPU Hotplug VM State Description (VMSD). Excerpt of GED VMSD State Dump at Source: "acpi-ged (16)": { "ged_state": { "sel": "0x00000000" }, [...] "acpi-ged/cpuhp": { "cpuhp_state": { "selector": "0x00000005", "command": "0x00", "devs": [ { "is_inserting": false, "is_removing": false, "ost_event": "0x00000000", "ost_status": "0x00000000" }, [...] { "is_inserting": false, "is_removing": false, "ost_event": "0x00000000", "ost_status": "0x00000000" } ] } } }, Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Message-Id: <20241103102419.202225-6-salil.mehta@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>