Thomas Huth [Fri, 1 Aug 2025 06:01:52 +0000 (08:01 +0200)]
hw/intc/loongarch_pch_pic: Fix ubsan warning and endianness issue
When booting the Linux kernel from tests/functional/test_loongarch64_virt.py
with a QEMU that has been compiled with --enable-ubsan, there is
a warning like this:
.../hw/intc/loongarch_pch_pic.c:171:46: runtime error: index 512 out of
bounds for type 'uint8_t[64]' (aka 'unsigned char[64]')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
.../hw/intc/loongarch_pch_pic.c:171:46
.../hw/intc/loongarch_pch_pic.c:175:45: runtime error: index 256 out of
bounds for type 'uint8_t[64]' (aka 'unsigned char[64]')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
.../hw/intc/loongarch_pch_pic.c:175:45
It happens because "addr" is added first before substracting the base
(PCH_PIC_HTMSI_VEC or PCH_PIC_ROUTE_ENTRY).
Additionally, this code looks like it is not endianness safe, since
it uses a 64-bit pointer to write values into an array of 8-bit values.
Thus rework the code to use the stq_le_p / ldq_le_p helpers here
and make sure that we do not create pointers with undefined behavior
by accident.
Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit 86bca40402316891b8b9a920c2e3bf8cf37ba9a4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
WANG Rui [Fri, 25 Jul 2025 03:12:32 +0000 (11:12 +0800)]
target/loongarch: Guard 64-bit-only insn translation with TRANS64 macro
This patch replaces uses of the generic TRANS macro with TRANS64 for
instructions that are only valid when 64-bit support is available.
This improves correctness and avoids potential assertion failures or
undefined behavior during translation on 32-bit-only configurations.
Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
(cherry picked from commit 96e7448c1f820c56caea8447c01f5227b0c95c79) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Michael Tokarev [Sun, 24 Aug 2025 00:05:32 +0000 (03:05 +0300)]
block/curl: fix curl internal handles handling
block/curl.c uses CURLMOPT_SOCKETFUNCTION to register a socket callback.
According to the documentation, this callback is called not just with
application-created sockets but also with internal curl sockets, - and
for such sockets, user data pointer is not set by the application, so
the result qemu crashing.
Pass BDRVCURLState directly to the callback function as user pointer,
instead of relying on CURLINFO_PRIVATE.
This problem started happening with update of libcurl from 8.9 to 8.10 --
apparently with this change curl started using private handles more.
(CURLINFO_PRIVATE is used in one more place, in curl_multi_check_completion() -
it might need a similar fix too)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3081 Cc: qemu-stable@qemu.org Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 606978500c3d18fb89a49844f253097b17f757de) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 21 Aug 2025 15:43:58 +0000 (16:43 +0100)]
hw/char/max78000_uart: Destroy FIFO on deinit
In the max78000_uart we create a FIFO in the instance_init function,
but we don't destroy it on deinit, so ASAN reports a leak in the
device-introspect-test:
#0 0x561cc92d5de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 98fdf9fc85c3beaeca8eda0be8412f1e11b9c6ad)
#1 0x70cbf2afab09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x561ccc4c884d in fifo8_create /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../util/fifo8.c:27:18
#3 0x561cc9744ec9 in max78000_uart_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/char/max78000_uart.c:241:5
Add an instance_finalize method to destroy the FIFO.
Cc: qemu-stable@nongnu.org Fixes: d447e4b70295 ("MAX78000: UART Implementation") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250821154358.2417744-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit ac6b124180f7698084ef2a59282e8fa65a45f23b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Thu, 21 Aug 2025 15:44:59 +0000 (16:44 +0100)]
hw/gpio/pca9554: Avoid leak in pca9554_set_pin()
In pca9554_set_pin() we have a string property which we parse in
order to set some non-string fields in the device state. So we call
visit_type_str(), passing it the address of the local variable
state_str.
visit_type_str() will allocate a new copy of the string; we
never free this string, so the result is a memory leak, detected
by ASAN during a "make check" run:
Direct leak of 5 byte(s) in 1 object(s) allocated from:
#0 0x5d605212ede3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (
BuildId: 3d5373c89317f58bfcd191a33988c7347714be14)
#1 0x7f7edea57b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75)
#2 0x7f7edea6d4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75)
#3 0x5d6055289a91 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10
#4 0x5d6055289a91 in qobject_input_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qo
bject-input-visitor.c:542:12
#5 0x5d605528479c in visit_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qapi-visit
-core.c:349:10
#6 0x5d60528bdd87 in pca9554_set_pin /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/gpio/pca9554.c:179:10
#7 0x5d60549bcbbb in object_property_set /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1450:5
#8 0x5d60549d2055 in object_property_set_qobject /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/qom-qobject.c:28:10
#9 0x5d60549bcdf1 in object_property_set_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1458:15
#10 0x5d605439d077 in gb200nvl_bmc_i2c_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:1267:5
#11 0x5d60543a3bbc in aspeed_machine_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:493:9
Make the state_str g_autofree, so that we will always free
it, on both error-exit and success codepaths.
Cc: qemu-stable@nongnu.org Fixes: de0c7d543bca ("misc: Add a pca9554 GPIO device model") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250821154459.2417976-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 3284d1c07cfd8d42aa27d1cf83d3e65fcd62e35e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Aditya Gupta [Wed, 20 Aug 2025 12:25:17 +0000 (17:55 +0530)]
hw/ppc: Fix build error with CONFIG_POWERNV disabled
Currently when CONFIG_POWERNV is not enabled, the build fails, such as
with --without-default-devices:
$ ./configure --without-default-devices
$ make
[281/283] Linking target qemu-system-ppc64
FAILED: qemu-system-ppc64
cc -m64 @qemu-system-ppc64.rsp
/usr/bin/ld: libqemu-ppc64-softmmu.a.p/target_ppc_misc_helper.c.o: in function `helper_load_sprd':
.../target/ppc/misc_helper.c:335:(.text+0xcdc): undefined reference to `pnv_chip_find_core'
/usr/bin/ld: libqemu-ppc64-softmmu.a.p/target_ppc_misc_helper.c.o: in function `helper_store_sprd':
.../target/ppc/misc_helper.c:375:(.text+0xdf4): undefined reference to `pnv_chip_find_core'
collect2: error: ld returned 1 exit status
...
This is since target/ppc/misc_helper.c references PowerNV specific
'pnv_chip_find_core' call.
Split the PowerNV specific SPRD code out of the generic PowerPC code, by
moving the SPRD code to pnv.c
Fixes: 9808ce6d5cb ("target/ppc: Big-core scratch register fix") Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Reported-by: Thomas Huth <thuth@redhat.com> Suggested-by: Cédric Le Goater <clg@redhat.com> Signed-off-by: Aditya Gupta <adityag@linux.ibm.com> Acked-by: Cédric Le Goater <clg@redhat.com>
Message-ID: <20250820122516.949766-2-adityag@linux.ibm.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 46d03bb23dde86513465724760d85f42eb17539e) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Denis Rastyogin [Thu, 14 Aug 2025 10:48:32 +0000 (13:48 +0300)]
target/mips: fix TLB huge page check to use 64-bit shift
Use extract64(entry, psn, 1) instead of (entry & (1 << psn)) to avoid
undefined behavior for shifts by 32–63 and to make bit extraction intent explicit.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Denis Rastyogin <gerben@altlinux.org>
Message-ID: <20250814104914.13101-1-gerben@altlinux.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 1f82ca723478f44823a18e7151e487d58da03659) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
linux-user/mips: Select M14Kc CPU to run microMIPS binaries
The M14Kc is our latest CPU supporting the microMIPS ASE.
Note, currently QEMU doesn't have 64-bit CPU supporting microMIPS ASE.
Cc: qemu-stable@nongnu.org Fixes: 3c824109da0 ("target-mips: microMIPS ASE support")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3054 Reported-by: Justin Applegate <justink.applegate@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-4-philmd@linaro.org>
(cherry picked from commit 51c3aebfda6489b49cebef593a1ceb597cb97a7e)
(Mjt: in 10.1 and before, the code is in linux-user/mips/target_elf.h) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
linux-user/mips: Select 74Kf CPU to run MIPS16e binaries
The 74Kf is our latest CPU supporting MIPS16e ASE.
Note, currently QEMU doesn't have 64-bit CPU supporting MIPS16e ASE.
Cc: qemu-stable@nongnu.org Fixes: 6ea219d0196..d19954f46df ("target-mips: MIPS16 support")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3054 Reported-by: Justin Applegate <justink.applegate@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-3-philmd@linaro.org>
(cherry picked from commit 7a09b3cc70ab6d717b18dec5c5995f7a06af4593)
(Mjt: in 10.1 and before the code is in linux-user/mips/target_elf.h) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Include MIPS ASE ELF definitions from binutils:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/elf/mips.h;h=4fc190f404d828ded84e621bfcece5fa9f9c23c8;hb=HEAD#l210
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250814070650.78657-2-philmd@linaro.org>
(cherry picked from commit 14ab44b96d5bf761af81cc723314ef5ecf73ed17) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Laurent Vivier [Thu, 7 Aug 2025 11:08:06 +0000 (13:08 +0200)]
e1000e: Prevent crash from legacy interrupt firing after MSI-X enable
A race condition between guest driver actions and QEMU timers can lead
to an assertion failure when the guest switches the e1000e from legacy
interrupt mode to MSI-X. If a legacy interrupt delay timer (TIDV or
RDTR) is active, but the guest enables MSI-X before the timer fires,
the pending interrupt cause can trigger an assert in
e1000e_intmgr_collect_delayed_causes().
This patch removes the assertion and executes the code that clears the
pending legacy causes. This change is safe and introduces no unintended
behavioral side effects, as it only alters a state that previously led
to termination.
- when core->delayed_causes == 0 the function was already a no-op and
remains so.
- when core->delayed_causes != 0 the function would previously
crash due to the assertion failure. The patch now defines a safe
outcome by clearing the cause and returning. Since behavior after
the assertion never existed, this simply corrects the crash.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1863 Suggested-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Message-ID: <20250807110806.409065-1-lvivier@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 8e4649cac9bcddc050d2df07908075e9e69bccc7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
vfio scsi ui: Error-check qio_channel_socket_connect_sync() the same way
qio_channel_socket_connect_sync() returns 0 on success, and -1 on
failure, with errp set. Some callers check the return value, and some
check whether errp was set.
For consistency, always check the return value, and always check it's
negative.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250723133257.1497640-3-armbru@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
(cherry picked from commit ec14a3de622ae30a8afa78b6f564bc743b753ee1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
i386/kvm/vmsr_energy: Plug memory leak on failure to connect socket
vmsr_open_socket() leaks the Error set by
qio_channel_socket_connect_sync(). Plug the leak by not creating the
Error.
Fixes: 0418f90809ae (Add support for RAPL MSRs in KVM/Qemu) Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250723133257.1497640-2-armbru@redhat.com> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
(cherry picked from commit b2e4534a2c9ce3d20ba44d855f1e2b71cc53c3a3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
QGA-VSS writes error using error_setg_win32_internal,
which call g_win32_error_message.
g_win32_error_message - translate a Win32 error code
(as returned by GetLastError()) into the corresponding message.
In the same time, we call error_setg_win32_internal with
error codes from different Windows componets like VSS or
Performance monitor that provides different codes and
can't be converted with g_win32_error_message. In this
case, the empty suffix will be returned so error will be
masked.
This commit directly add hex value of error code.
Reproduce:
- Run QGA command: {"execute": "guest-fsfreeze-freeze-list", "arguments": {"mountpoints": ["D:"]}}
QGA error example:
- before changes:
{"error": {"class": "GenericError", "desc": "failed to add D: to snapshot set: "}}
- after changes:
{"error": {"class": "GenericError", "desc": "failed to add D: to snapshot set: Windows error 0x8004230e: "}}
qga/installer: Remove QGA VSS if QGA installation failed
When QGA Installer failed to install QGA service but install
QGA VSS provider, provider should be removed before installer
exits. Otherwise QGA VSS will has broken infomation and
prevent QGA installation in next run.
In stm32f250_soc_initfn() we mostly use the standard pattern
for child objects of calling object_initialize_child(). However
for s->adc_irqs we call object_new() and then later qdev_realize(),
and we never unref the object on deinit. This causes a leak,
detected by ASAN on the device-introspect-test:
Indirect leak of 10 byte(s) in 1 object(s) allocated from:
#0 0x5b9fc4789de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 267a2619a026ed91c78a07b1eb2ef15381538efe)
#1 0x740de3f28b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#2 0x740de3f3e4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75)
#3 0x5b9fc70159e1 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10
#4 0x5b9fc70159e1 in object_property_try_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1276:18
#5 0x5b9fc7015f94 in object_property_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1294:12
#6 0x5b9fc701b900 in object_add_link_prop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2021:10
#7 0x5b9fc701b3fc in object_property_add_link /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2037:12
#8 0x5b9fc4c299fb in qdev_init_gpio_out_named /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:90:9
#9 0x5b9fc4c29b26 in qdev_init_gpio_out /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:101:5
#10 0x5b9fc4c0f77a in or_irq_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/or-irq.c:70:5
#11 0x5b9fc70257e1 in object_init_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:428:9
#12 0x5b9fc700cd4b in object_initialize_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:570:5
#13 0x5b9fc700e66d in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:774:5
#14 0x5b9fc700e750 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12
#15 0x5b9fc68b2162 in stm32f205_soc_initfn /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/stm32f205_soc.c:69:26
Switch to using object_initialize_child() like all our
other child objects for this SoC object.
Cc: qemu-stable@nongnu.org Fixes: b63041c8f6b ("STM32F205: Connect the ADC devices") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20250821154229.2417453-1-peter.maydell@linaro.org
(cherry picked from commit 2e27650bddd35477d994a795a3b1cb57c8ed5c76) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Peter Maydell [Tue, 19 Aug 2025 11:56:48 +0000 (12:56 +0100)]
scripts/kernel-doc: Avoid new Perl precedence warning
Newer versions of Perl (5.41.x and up) emit a warning for code in
kernel-doc:
Possible precedence problem between ! and pattern match (m//) at /scripts/kernel-doc line 1597.
This is because the code does:
if (!$param =~ /\w\.\.\.$/) {
In Perl, the ! operator has higher precedence than the =~
pattern-match binding, so the effect of this condition is to first
logically-negate the string $param into a true-or-false value and
then try to pattern match it against the regex, which in this case
will always fail. This is almost certainly not what the author
intended.
In the new Python version of kernel-doc in the Linux kernel,
the equivalent code is written:
if KernRe(r'\w\.\.\.$').search(param):
# For named variable parameters of the form `x...`,
# remove the dots
param = param[:-3]
else:
# Handles unnamed variable parameters
param = "..."
which is a more sensible way of writing the behaviour you would
get if you put in brackets to make the regex match first and
then negate the result.
Take this as the intended behaviour, and update the Perl to match.
For QEMU, this produces no change in output, presumably because we
never used the "unnamed variable parameters" syntax.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Message-id: 20250819115648.2125709-1-peter.maydell@linaro.org
(cherry picked from commit 5ffd387e9e0f787744fadaad35e1bf92224b0642) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Smail AIDER [Tue, 26 Aug 2025 10:21:28 +0000 (11:21 +0100)]
target/arm: Trap PMCR when MDCR_EL2.TPMCR is set
Trap PMCR_EL0 or PMCR accesses to EL2 when MDCR_EL2.TPMCR is set.
Similar to MDCR_EL2.TPM, MDCR_EL2.TPMCR allows trapping EL0 and EL1
accesses to the PMCR register to EL2.
Cc: qemu-stable@nongnu.org Signed-off-by: Smail AIDER <smail.aider@huawei.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20250811112143.1577055-2-smail.aider@huawei.com
Message-Id: <20250722131925.2119169-1-smail.aider@huawei.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 186db6a73bc5c01026bb9f4f4a59e442c0156841) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Steve Sistare [Tue, 26 Aug 2025 10:21:28 +0000 (11:21 +0100)]
hw/intc/arm_gicv3_kvm: preserve pending interrupts during cpr
Close a race condition that causes cpr-transfer to lose VFIO
interrupts on ARM.
CPR stops VCPUs but does not disable VFIO interrupts, which may continue
to arrive throughout the transition to new QEMU.
CPR calls kvm_irqchip_remove_irqfd_notifier_gsi in old QEMU to force
future interrupts to the producer eventfd, where they are preserved.
Old QEMU then destroys the old KVM instance. However, interrupts may
already be pending in KVM state. To preserve them, call ioctl
KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES to flush them to guest RAM, where
they will be picked up when the new KVM+VCPU instance is created.
Cc: qemu-stable@nongnu.org Signed-off-by: Steve Sistare <steven.sistare@oracle.com> Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-id: 1754936384-278328-1-git-send-email-steven.sistare@oracle.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 376cdd7e9c94f1e03b2c58e068e8ebfe78b49514) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
This commit fixes the asset precaching in the reverse_debugging test on
aarch64.
QemuBaseTest.main() precaches assets (kernel, rootfs, DT blobs, etc.)
that are defined in variables with the ASSET_ prefix. This works because
it ultimately calls Asset.precache_test(), which relies on introspection
to locate these variables.
If an asset variable is not named with the ASSET_ prefix, precache_test
cannot find the asset and precaching silently fails. Hence, fix the
asset precaching by fixing the asset variable name.
Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Message-ID: <20250827001008.22112-1-gustavo.romero@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 36fb9796662e8d1f8626b1cacb1a6d5e35a8bd00) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250826060341.1118670-1-joel@jms.id.au>
(cherry picked from commit f91563d011a0439cd6709e169cdfac268779d562) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Zero Tang [Mon, 18 Aug 2025 10:16:47 +0000 (12:16 +0200)]
i386/tcg/svm: fix incorrect canonicalization
For all 32-bit systems and 64-bit Windows systems, "long" is 4 bytes long.
Due to using "long" for a linear address, svm_canonicalization would
set all high bits to 1 when (assuming 48-bit linear address) the segment
base is bigger than 0x7FFF.
This fixes booting guests under TCG when the guest IDT and GDT bases are
above 0x7FFF, thereby resulting in incorrect bases. When an interrupt
arrives, it would trigger a #PF exception; the #PF would trigger again,
resulting in a #DF exception; the #PF would trigger for the third time,
resulting in triple-fault, and eventually causes a shutdown VM-Exit to
the hypervisor right after guest boot.
Cc: qemu-stable@nongnu.org Signed-off-by: Zero Tang <zero.tangptr@gmail.com>
(cherry picked from commit c12cbaa007c9da97a11e74119ea3aed9fcc3ac4c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
mark_unavailable_features() actively blocks usage of the feature,
so it is a functional change, not merely a emitting warning.
The commit was intended to merely warn if PDCM was enabled when
the performance counters are not, so revert it.
Reported-by: Christian A. Ehrhardt <christian.ehrhardt@canonical.com> Analyzed-by: Daniel P. Berrangé <berrange@redhat.com> Analyzed-by: Xiaoyao Li <xiaoyao.li@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250819150235.785559-1-pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'uefi-20250812-pull-request' of https://gitlab.com/kraxel/qemu:
hw/uefi: open json file in binary mode
hw/uefi: check access for first variable
hw/uefi: return success for notifications
hw/uefi: clear uefi-vars buffer in uefi_vars_write callback
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 12 Aug 2025 20:26:05 +0000 (16:26 -0400)]
Merge tag 'for-upstream' of git://repo.or.cz/qemu/kevin into staging
Patches for QEMU 10.1.0-rc3
- configure: Don't disable Rust for too old meson version
- rbd: Fix hang in query-named-block-nodes if the server is down
- iotests: Fix reference output for newer bash versions
* tag 'for-upstream' of git://repo.or.cz/qemu/kevin:
qemu-iotests: Ignore indentation in Killed messages
rbd: Fix .bdrv_get_specific_info implementation
configure: Don't disable Rust for too old meson version
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
ui/spice: Destroy the temporary egl fb after the blit is submitted
The temporary egl fb scanout_tex_fb is only needed to facilitate the
blit to the display surface's texture (ssd->ds->texture). Therefore,
destroy it after the blit is submitted. And, also make sure that it
is empty initialized before it is actually used.
Fixes: f851cd65 ("ui/spice: Blit the scanout texture if its memory layout is not linear") Reported-by: Peter Maydell <peter.maydell@linaro.org> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20250718234039.2266704-1-vivek.kasireddy@intel.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Alex Bennée [Mon, 4 Aug 2025 16:29:59 +0000 (17:29 +0100)]
readthedocs: don't build extra formats
We don't build the PDFs ourselves for the hosted docs and it looks
like rtd can't manage building PDFs now they have gone over a certain
size. Disable the extra formats so we can at least have the online
stuff again.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-ID: <20250804162959.330060-1-alex.bennee@linaro.org> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* tag 'sdmmc-20250812' of https://github.com/philmd/qemu:
tests/functional: Test SPI-SD adapter without SD card connected
hw/sd/ssi-sd: Return noise (dummy byte) when no card connected
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Sv. Lockal <lockalsash@gmail.com>
[Edits: Type "safety" whackamole --js] Signed-off-by: John Snow <jsnow@redhat.com>
Message-ID: <20250811190159.237321-1-jsnow@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
tests/functional: Test SPI-SD adapter without SD card connected
SPI-SD adapter should be usable, even without any SD card
wired. Refactor test_riscv64_sifive_u_mmc_spi() to make it
more generic and add another test, inspired by this report:
https://lore.kernel.org/qemu-devel/5b2dc427-f0db-4332-a997-fe0c82415acd@roeck-us.net/
Inspired-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20250812140415.70153-3-philmd@linaro.org>
hw/sd/ssi-sd: Return noise (dummy byte) when no card connected
Commit 1585ab9f1ba ("hw/sd/sdcard: Fill SPI response bits in card
code") exposed a bug in the SPI adapter: if no SD card is plugged,
we are returning "there is a card with an error". This is wrong,
we shouldn't return any particular packet response, but the noise
shifted on the MISO line. Return the dummy byte, otherwise we get:
Werner Fink [Wed, 6 Aug 2025 06:54:51 +0000 (08:54 +0200)]
qemu-iotests: Ignore indentation in Killed messages
New bash 5.3 uses a different padding for reporting job status.
Resolves: boo#1246830
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3050 Signed-off-by: Werner Fink <werner@suse.de>
Message-ID: <aJL8RH8ePPNEteMg@boole.nue2.suse.org> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Mon, 11 Aug 2025 13:40:10 +0000 (15:40 +0200)]
rbd: Fix .bdrv_get_specific_info implementation
qemu_rbd_get_specific_info() has at least two problems:
The first is that it issues a blocking rbd_read() call in order to probe
the encryption format for the image while querying the node. This means
that if the connection to the server goes down, not only I/O is stuck
(which is unavoidable), but query-names-block-nodes will actually make
the whole QEMU instance unresponsive. .bdrv_get_specific_info
implementations shouldn't perform blocking operations, but only return
what is already known.
The second is that the information returned isn't even correct. If the
image is already opened with encryption enabled at the RBD level, we'll
probe for "double encryption", i.e. if the encrypted data contains
another encryption header. If it doesn't (which is the normal case), we
won't return the encryption format. If it does, we return misleading
information because it looks like we're talking about the outer level
(the encryption format of the image itself) while the information is
about an encryption header in the guest data.
Fix this by storing the encryption format in BDRVRBDState when the image
is opened (and we do blocking operations anyway) and returning only the
stored information in qemu_rbd_get_specific_info().
The information we'll store is either the actual encryption format that
we enabled on the RBD level, or if the image is unencrypted, the result
of the same probing as we previously did when querying the node. Probing
image formats based on content that can be modified by the guest has
long been known as problematic, but as long as we only output it to the
user instead of making decisions based on it, it should be okay. It is
undoubtedly useful in the context of 'qemu-img info' when you're trying
to figure out which encryption options you have to use to open the
image successfully.
Fixes: 42e4ac9ef5a6 ("block/rbd: Add support for rbd image encryption") Buglink: https://issues.redhat.com/browse/RHEL-105440 Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250811134010.81787-1-kwolf@redhat.com> Reviewed-by: Hanna Czenczek <hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Kevin Wolf [Mon, 11 Aug 2025 14:29:23 +0000 (16:29 +0200)]
configure: Don't disable Rust for too old meson version
If the user explicitly specified --enable-rust, don't just fail if meson
is too old for Rust support, but do the same thing as if meson was too
old for the C code: Just download a newer one.
In order to avoid the additional download for people who aren't
intentionally opting in to Rust, keep the automatic disabling based on
the meson version as the default if neither --enable-rust nor
--disable-rust were given.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20250811142923.89983-1-kwolf@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Gerd Hoffmann [Mon, 11 Aug 2025 13:01:09 +0000 (15:01 +0200)]
hw/uefi: check access for first variable
When listing variables (via get-next-variable-name) only the names of
variables which can be accessed will be returned. That check was
missing for the first variable though. Add it.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20250811130110.820958-3-kraxel@redhat.com>
hw/uefi: clear uefi-vars buffer in uefi_vars_write callback
When the guest writes to register UEFI_VARS_REG_BUFFER_SIZE, the .write
callback `uefi_vars_write` is invoked. The function allocates a
heap buffer without zeroing the memory, leaving the buffer filled with
residual data from prior allocations. When the guest later reads from
register UEFI_VARS_REG_PIO_BUFFER_TRANSFER, the .read callback
`uefi_vars_read` returns leftover metadata or other sensitive process
memory from the previously allocated buffer, leading to an information
disclosure vulnerability.
Stefan Hajnoczi [Mon, 11 Aug 2025 16:57:55 +0000 (12:57 -0400)]
Merge tag 'pull-nvme-20250811' of https://gitlab.com/birkelund/qemu into staging
nvme queue
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmiZmYQACgkQTeGvMW1P
# DenI0wf9GPov0a82A2F23UTU+R8NC/NASBovEfPRTz7/J9fGL844ID3G6uT4emFP
# wAilGmMbNuPHKAtII4holCximP/7yosVZJIIdjLsRBBP9AZqpMHkr27VBny9rklZ
# X7TW6zI8INIjdqvRlIBevH5t5By/qLiaDc6GzRWJ3PoeXE6SKACDi0lNBsn75xah
# IbcHi72c96CwYJCEtOHXBs+zECo1yGDhK0OPvs/s7OykuRcOumF21IzuY958bVs/
# 7dJZkTL+oarZHIvKiUrErKK3gWfSrLeaWrR6sW1QNuOhzEeNHk47w86p+CEQ7CrU
# w0ioEaZ9awXk7wnZeY//CpUKFbsmwQ==
# =Qfvu
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 11 Aug 2025 03:19:32 EDT
# gpg: using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9
# gpg: Good signature from "Klaus Jensen <its@irrelevant.dk>" [unknown]
# gpg: aka "Klaus Jensen <k.jensen@samsung.com>" [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: DDCA 4D9C 9EF9 31CC 3468 4272 63D5 6FC5 E55D A838
# Subkey fingerprint: 5228 33AA 75E2 DCE6 A247 66C0 4DE1 AF31 6D4F 0DE9
* tag 'pull-nvme-20250811' of https://gitlab.com/birkelund/qemu:
hw/nvme: cap MDTS value for internal limitation
hw/nvme: revert CMIC behavior
hw/nvme: fix namespace attachment
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Mon, 11 Aug 2025 16:23:15 +0000 (12:23 -0400)]
tests/functional: fix URLs in PCI hotplug test for aarch64
Debian trixie has been released. The "stable" alias no longer refers to
the Debian bookworm release, so URLs referring to bookworm artifacts via
the "stable" alias no longer work.
Switch to explicit release naming ("bookworm") to make a permalink so
the test passes again.
Suggested-by: Peter Maydell <peter.maydell@linaro.org> Fixes: 374a245573b8 ("tests/functional: Add PCI hotplug test for aarch64")
Resolves: #3073 ("PCI hotplug test for aarch64 fails due to broken Debian installer URL") Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20250811162315.59997-1-stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Keith Busch [Fri, 1 Aug 2025 14:24:57 +0000 (07:24 -0700)]
hw/nvme: cap MDTS value for internal limitation
The emulated device had let the user set whatever max transfers size
they wanted, including no limit. However the device does have an
internal limit of 1024 segments. NVMe doesn't report max segments,
though. This is implicitly inferred based on the MDTS and MPSMIN values.
IOV_MAX is currently 1024 which 4k PRPs can exceed with 2MB transfers.
Don't allow MDTS values that can exceed this, otherwise users risk
seeing "internal error" status to their otherwise protocol compliant
commands.
Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Klaus Jensen [Tue, 3 Jun 2025 12:59:06 +0000 (14:59 +0200)]
hw/nvme: revert CMIC behavior
Commit cd59f50ab017 ("hw/nvme: always initialize a subsystem") causes
the controller to always set the CMIC.MCTRS ("Multiple Controllers")
bit. While spec-compliant, this is a deviation from the previous
behavior where this was only set if an nvme-subsys device was explicitly
created (to configure a subsystem with multiple controllers/namespaces).
Revert the behavior to only set CMIC.MCTRS if an nvme-subsys device is
created explicitly.
Reported-by: Alan Adamson <alan.adamson@oracle.com> Fixes: cd59f50ab017 ("hw/nvme: always initialize a subsystem") Reviewed-by: Alan Adamson <alan.adamson@oracle.com> Tested-by: Alan Adamson <alan.adamson@oracle.com> Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
* tag 'pull-qapi-2025-08-09' of https://repo.or.cz/qemu/armbru:
docs/devel/qapi-code-gen: Update cross-reference syntax
docs/devel/qapi-code-gen: Fix typos in QAPI schema language grammar
docs/devel/qapi-code-gen: Add two cross-references we missed
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The new QAPI code generator creates a cross-reference target for each
definition documentation. Enabled for the QEMU QMP Reference manual
in commit a377f39f38f, and for the QEMU Storage Daemon QMP Reference
Manual and the QEMU Guest Agent Protocol Reference in commit a6af5443440. We've put these targets to use since, but neglected to
update doc comment markup documentation. Do that now.
Co-developed-by: John Snow <jsnow@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250731054044.4011789-4-armbru@redhat.com>
docs/devel/qapi-code-gen: Fix typos in QAPI schema language grammar
Fixes: 3248c1aaf2db (docs: update the documentation upfront about schema configuration) Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250731054044.4011789-3-armbru@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
docs/devel/qapi-code-gen: Add two cross-references we missed
Missed in commit 9c66762a601 (docs/qapi-code-gen: add
cross-references).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20250731054044.4011789-2-armbru@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
Commit 350785d41d8b ("ramfb: Add property to control if load the
romfile") introduced the `use-legacy-x86-rom` property for the
`vfio-pci-nohotplug` device. Add documentation for the property.
Steve Sistare [Wed, 16 Jul 2025 18:06:09 +0000 (11:06 -0700)]
vfio/pci: preserve pending interrupts
cpr-transfer may lose a VFIO interrupt because the KVM instance is
destroyed and recreated. If an interrupt arrives in the middle, it is
dropped. To fix, stop pending new interrupts during cpr save, and pick
up the pieces. In more detail:
Stop the VCPUs. Call kvm_irqchip_remove_irqfd_notifier_gsi --> KVM_IRQFD to
deassign the irqfd gsi that routes interrupts directly to the VCPU and KVM.
After this call, interrupts fall back to the kernel vfio_msihandler, which
writes to QEMU's kvm_interrupt eventfd. CPR already preserves that
eventfd. When the route is re-established in new QEMU, the kernel tests
the eventfd and injects an interrupt to KVM if necessary.
Deassign INTx in a similar manner. For both MSI and INTx, remove the
eventfd handler so old QEMU does not consume an event.
If an interrupt was already pended to KVM prior to the completion of
kvm_irqchip_remove_irqfd_notifier_gsi, it will be recovered by the
subsequent call to cpu_synchronize_all_states, which pulls KVM interrupt
state to userland prior to saving it in vmstate.
# -----BEGIN PGP SIGNATURE-----
#
# iLMEAAEIAB0WIQTKRzxE1qCcGJoZP81FK5aFKyaCFgUCaJVRCAAKCRBFK5aFKyaC
# Fn9TA/97BaWn3s3HlDy8HhIEereLJ1NWz9FGmYw2jBT77IVrpWeSSmUY3LapmHT0
# lVTrj4aCRlY5zjKn4xw8AQLACrNl2SL5brPXg4YMuwow062Akq/Ow+ooj3LHSlnX
# qXULIMi7hq3gPcmjLeR03AJjiSR2fgIjTzUN8RjangAS+PZ8/A==
# =ZQ4o
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 07 Aug 2025 21:21:12 EDT
# gpg: using RSA key CA473C44D6A09C189A193FCD452B96852B268216
# gpg: Good signature from "Song Gao <gaosong@loongson.cn>" [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: CA47 3C44 D6A0 9C18 9A19 3FCD 452B 9685 2B26 8216
* tag 'pull-loongarch-20250808' of https://github.com/gaosong715/qemu:
target/loongarch: Fix [X]VLDI raising exception incorrectly
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Fri, 8 Aug 2025 13:46:17 +0000 (09:46 -0400)]
Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging
trivial patches for 2025-08-07
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmiVEtUACgkQgqpKJDse
# lHh6Lg/+MdkCRc9q+1lo2pQqu5AY3uWMVxCgHZSGgTkkBpSgp4AXgPU9AusOU7jd
# ZEKsmfHTiSodahE7+c6k09yzD+6FIBO3CTi502YPvzJ4Fmyd1Y5hWjUcG+lh9Qhs
# zDA4rg3Gfg8ecCZX9S4A0DAlLmgxCCnqJaGnJhv1sCYgmG1/jshTdpZbgxHDhxho
# 202yMqJagsWApTPmslEBgdBBC8cKUqd8+Lb9AYd+68As9mvCyLq8VbA4lPJ9sSgm
# PdeJzNdFSc5UNKbUe5AYghXeof++mBdKrvegIzRfCVtDkS64ermh2kL22iZI+9Ij
# nxgxYWQAYrsyF6d3vrRTVDWovAPEReu4j1VywOAbaQX6464EVnXDAeq+y9JOlZDs
# +d2pb1uyyFUqGh1A3OwSApyiGGOeMXxDxm77ixkFgf+WTPZ+BNOOrl/YootRxk87
# z7BmTqzycO2eRo6OGNh04LfEOTILhXtENy7NrS/dC2EG4+lgWuGOb3Cl4v1O6cE9
# E2cS7pqpihGyNTXai//USazr3Dh6NxmBsMEfZvWw/WMDy71kBx7XpKn4jv6Dnh+b
# wgg3CoLu9YeCdpmp1zb/g0wKEvFU41f2W1dR7BvCG18xtalr5zmFbdiDRwhnSwJh
# VW8k0XHcBXYHeBBqyrNglZ31alGq2UlmVG29LOzZyfFEVxz+HfM=
# =GrRa
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 07 Aug 2025 16:55:49 EDT
# gpg: using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478
# gpg: Good signature from "Michael Tokarev <mjt@debian.org>" [unknown]
# gpg: aka "Michael Tokarev <mjt@corpit.ru>" [unknown]
# gpg: aka "Michael Tokarev <mjt@tls.msk.ru>" [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: 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E
# Subkey fingerprint: 64AA 2AB5 31D5 6903 366B FEF9 82AA 4A24 3B1E 9478
* tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu:
meson: Fix brlapi compile test for Windows builds
tests/qemu-iotests/tests/mirror-sparse: actually require O_DIRECT
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
According to the specification, [X]VLDI should trigger an invalid instruction
exception only when Bit[12] is 1 and Bit[11:8] > 12. This patch fixes an issue
where an exception was incorrectly raised even when Bit[12] was 0.
Test case:
```
.global main
main:
vldi $vr0, 3328
ret
```
Reported-by: Zhou Qiankang <wszqkzqk@qq.com> Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn>
Message-ID: <20250804132212.4816-1-wangrui@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
Stefan Weil via [Wed, 6 Aug 2025 20:45:58 +0000 (22:45 +0200)]
meson: Fix brlapi compile test for Windows builds
brlapi__openConnection returns a brlapi_fileDescriptor which is a pointer
for Windows builds.
The test for brlapi fails with cross builds on Debian trixie
(x86_64-w64-mingw32-gcc (GCC) 14-win32):
testfile.c:4:30: error: returning 'brlapi_fileDescriptor' {aka 'void *'} from a function with return type 'int' makes integer from pointer without a cast [-Wint-conversion]
4 | int main(void) { return brlapi__openConnection (NULL, NULL, NULL); }
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------
../../../meson.build:1607: WARNING: could not link brlapi, disabling
Signed-off-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit c0ddcb2cbc146e introduced the test which uses cache=direct
mode, without checking if the scratch filesystem supports O_DIRECT.
A subsequent commit, afeb002e0ad49d, tried to fix that issue, but
instead of checking for o_direct, it checked for
`_supported_cache_modes none directsync`, which is not what the
original mirror-sparse test uses. Fix both by actually checking
for o_direct.
Fixes: c0ddcb2cbc146e "tests: Add iotest mirror-sparse for recent patches" Fixes: afeb002e0ad49d "tests/qemu-iotests/tests/mirror-sparse: skip if O_DIRECT is not supported" Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
meson: remove 'gnutls-bug1717-workaround' for migration TLS crashes
The implementation of this workaround does not currently work, so
remove the option entirely to avoid exposing it to users. The code
will remain (temporarily dormant) to be fixed in the next release
cycle.
* tag 'hw-misc-20250805' of https://github.com/philmd/qemu:
hw/i386/microvm: Explicitly select ACPI_PCI
target/i386/cpu: Move addressable ID encoding out of compat property in CPUID[0x1]
tests/functional: Test SD cards in SPI mode (using sifive_u machine)
hw/sd/sdcard: Remove SDState::mode field
hw/sd/sdcard: Disable checking STBY mode in SPI SEND_CSD/CID
hw/sd/sdcard: Factor spi_cmd_SEND_CxD() out
hw/sd/sdcard: Allow using SWITCH_FUNCTION in more SPI states
hw/sd/sdcard: Use complete SEND_OP_COND implementation in SPI mode
hw/sd/sdcard: Implement SPI R2 return value
hw/sd/sdcard: Fill SPI response bits in card code
hw/sd/sdbus: Provide buffer size to sdbus_do_command()
hw/sd/sdcard: Factor sd_response_size() out
hw/sd/sdcard: Do not ignore errors in sd_cmd_to_sendingdata()
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Michael Tokarev [Tue, 5 Aug 2025 18:17:30 +0000 (21:17 +0300)]
tests/qemu-iotests/tests/mirror-sparse: skip if O_DIRECT is not supported
This test uses cache.direct=true, but does not check if O_DIRECT
is supported by the underlying filesystem, and fails, for example,
on a tmpfs (which is rather common on various auto-builders, in CI,
etc).
Fix this by using `_supported_cache_modes none directsync`.
Fixes: c0ddcb2cbc146e "tests: Add iotest mirror-sparse for recent patches" Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250805181731.282677-1-mjt@tls.msk.ru> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Michael Tokarev [Fri, 1 Aug 2025 11:53:14 +0000 (14:53 +0300)]
qga: correctly write to /sys/power/state on linux
Commit v9.0.0-343-g2048129625 introduced usage of
g_file_set_contents() function to write to /sys/power/state.
This function uses G_FILE_SET_CONTENTS_CONSISTENT flag to
g_file_set_contents_full(), which is implemented by creating
a temp file in the same directory and renaming it to the final
destination. Which is not how sysfs works.
Here, there's not a big deal to do open/write/close - it becomes
almost the same as using g_file_set_contents[_full](). But it
does not have surprises like this.
Also, since this is linux code, it should be ok to use %m in
the error reporting function.
Fixes: 2048129625 "qga/commands-posix: don't do fork()/exec() when suspending via sysfs"
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3057 Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20250801115316.6845-1-mjt@tls.msk.ru> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Eric Auger [Mon, 4 Aug 2025 15:20:07 +0000 (17:20 +0200)]
hw/i386/microvm: Explicitly select ACPI_PCI
With a microvm-only build based on a custom device config,
we get a link failure due to undefined reference to
build_pci_host_bridge_osc_method() which is defined in hw/acpi/pci.c and
whose compilation depends on CONFIG_ACPI_PCI. Although CONFIG_ACPI
and CONFIG_PCI are set with such configuration, implied CONFIG_ACPI_PCI
in config PCI_EXPRESS_GENERIC_BRIDGE is not selected as expected.
It Looks like CONFIG_ACPI_PCI must be enforced and this patch selects
CONFIG_ACPI_PCI in MICROVM config directly as done for PC config.
FAILED: qemu-system-x86_64
cc -m64 @qemu-system-x86_64.rsp
/usr/bin/ld: libsystem.a.p/hw_pci-host_gpex-acpi.c.o: in function `acpi_dsdt_add_host_bridge_methods':
hw/pci-host/gpex-acpi.c:83:(.text+0x274): undefined reference to `build_pci_host_bridge_osc_method'
collect2: error: ld returned 1 exit status
Fixes: af151d50eac24 "hw/pci-host/gpex-acpi: Use build_pci_host_bridge_osc_method" Signed-off-by: Eric Auger <eric.auger@redhat.com> Reported-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20250804152008.247673-1-eric.auger@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Zhao Liu [Mon, 4 Aug 2025 05:35:48 +0000 (13:35 +0800)]
target/i386/cpu: Move addressable ID encoding out of compat property in CPUID[0x1]
Currently, the addressable ID encoding for CPUID[0x1].EBX[bits 16-23]
(Maximum number of addressable IDs for logical processors in this
physical package) is covered by vendor_cpuid_only_v2 compat property.
The previous consideration was to avoid breaking migration and this
compat property makes it unfriendly to backport the commit f985a1195ba2
("i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX
[23:16]").
However, NetBSD booting is broken since the commit 88dd4ca06c83
("i386/cpu: Use APIC ID info to encode cache topo in CPUID[4]"),
because NetBSD calculates smt information via `lp_max` / `core_max` for
legacy Intel CPUs which doesn't support 0xb leaf, where `lp_max` is from
CPUID[0x1].EBX.bits[16-23] and `core_max` is from CPUID[0x4].0x0.bits[26
-31].
The commit 88dd4ca0 changed the encoding rule of `core_max` but didn't
update `lp_max`, so that NetBSD would get the wrong smt information,
which leads to the module loading failure.
Luckily, the commit f985a1195ba2 ("i386/cpu: Fix number of addressable
IDs field for CPUID.01H.EBX[23:16]") updated the encoding rule for
`lp_max` and accidentally fixed the NetBSD issue too. This also shows
that using CPUID[0x1] and CPUID[0x4].0x0 to calculate HT/SMT information
is a common practice to detect CPU topology on legacy Intel CPUs.
Therefore, it's necessary to backport the commit f985a1195ba2 to
previous stable QEMU to help address the similar issues as well. Then
the compat property is not needed any more since all stable QEMUs will
follow the same encoding way.
So, in CPUID[0x1], move addressable ID encoding out of compat property.
Reported-by: Michael Tokarev <mjt@tls.msk.ru> Inspired-by: Chuang Xu <xuchuangxclwt@bytedance.com> Fixes: commit f985a1195ba2 ("i386/cpu: Fix number of addressable IDs field for CPUID.01H.EBX[23:16]")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3061 Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20250804053548.1808629-1-zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Stefan Hajnoczi [Tue, 5 Aug 2025 14:11:32 +0000 (10:11 -0400)]
Merge tag 'pull-10.1-rc2-maintainer-040825-2' of https://gitlab.com/stsquad/qemu into staging
Testing and doc fixes
- add information about patch submission with b4
- fix make-release script to include all EDK submodules
- fix debian-all-test-cross docker image
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmiQzlAACgkQ+9DbCVqe
# KkScxAf/dMJeC1SWwyXK/To44W0IMRNTKSisAksEVg5MeDAwxZkGjwh2einCyGne
# +Ac3KetXunswne3OOxBF24TyYwk6ITX1WSs2ViYI6qOKAehvKuweiTZSZiNUg9KB
# fSP4NTMrkk6sbD1fGjLWBOb/E84qoVOdoxW6Th0cnQxCX5WpaIcL84xvR4yOl37i
# nRisB36ZiO7ntMKRLU/yYffLq8gnRLQaYt/S17k6SlNTCQkL/rlYwpNwfvEaCwIX
# B3Nb6QveeNiyRdIP5TnmqSzu/OtIoJHe62pKcbHXpuDqynycnh/I+ML7nTbOHjWA
# tTDHjoLKo8be2jfYT14lkQbS11loHg==
# =lQIU
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 04 Aug 2025 11:14:24 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-10.1-rc2-maintainer-040825-2' of https://gitlab.com/stsquad/qemu:
tests/docker: fix debian-all-test-cross
scripts/make-release: Go back to cloning all the EDK2 submodules
docs/devel/submitting-a-patch.rst: add b4 section
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
tests/functional: Test SD cards in SPI mode (using sifive_u machine)
Add a test which uses the sifive_u machine to boot a Linux
kernel from a SD card connected via a SPI interface.
Inspired from the command provided in:
- https://lore.kernel.org/qemu-devel/94b2c5bf-53d0-4c74-8264-f3021916f38c@roeck-us.net/
- https://lore.kernel.org/qemu-devel/840016d0-0d49-4ef4-8372-b62b3bcd0ac6@codethink.co.uk/
Inspired-by: Guenter Roeck <linux@roeck-us.net> Inspired-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250804133406.17456-12-philmd@linaro.org>
hw/sd/sdcard: Disable checking STBY mode in SPI SEND_CSD/CID
The card should be in STANDBY mode to process SEND_CSD or SEND_CID,
but is still in IDLE mode.
Unfortunately I don't have enough time to keep debugging this issue,
so disable the check for the time being and the next release, as it
blocks Linux. I'll keep looking.
Reported-by: Guenter Roeck <linux@roeck-us.net> Reported-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250804133406.17456-10-philmd@linaro.org>
spi_cmd_SEND_CSD() and spi_cmd_SEND_CID() are very
similar. Factor the common code as spi_cmd_SEND_CxD().
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250804133406.17456-9-philmd@linaro.org>
hw/sd/sdcard: Use complete SEND_OP_COND implementation in SPI mode
While spi_cmd_SEND_OP_COND() is incomplete, sd_cmd_SEND_OP_COND()
is, except it doesn't return the correct value in SPI mode.
Correct and use, removing the need for spi_cmd_SEND_OP_COND().
Fixes: 775616c3ae8 ("Partial SD card SPI mode support") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250804133406.17456-7-philmd@linaro.org>
ssi-sd.c contains the SPI link layer adaptation,
while sd.c contains all the SD card internal details.
We already handle the response values in sd.c, but
missed the SPI case. Complete them (fill R1, prepend
R1 in R3/R7 and always return something in SPI mode).
Remove all the duplication in ssi-sd.c.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250804133406.17456-5-philmd@linaro.org>
hw/sd/sdbus: Provide buffer size to sdbus_do_command()
We provide to sdbus_do_command() a pointer to a buffer to be
filled with a varying number of bytes. By not providing the
buffer size, the callee can not check the buffer is big enough.
Pass the buffer size as argument to follow good practices.
sdbus_do_command() doesn't return any error, only the size filled
in the buffer. Convert the returned type to unsigned and remove
the few unreachable lines in callers.
This allow to check for possible overflow in sd_do_command().
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250804133406.17456-4-philmd@linaro.org>
Set @rsplen once before switching to fill the response buffer.
This will allow to assert in a single place that the buffer is
big enough to be filled with the response.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20250804133406.17456-3-philmd@linaro.org>
Alex Bennée [Mon, 4 Aug 2025 10:43:08 +0000 (11:43 +0100)]
tests/docker: fix debian-all-test-cross
It turns out you can't easily expand an ENV var across multiple steps
in a dockerfile. This meant we silently dropped the architectures we
should have even on amd64 hosts. As the updated AVAILABLE_COMPILERS is
only needed for the following apt install line just merge them.
Fixes: 6da616bb170 (tests/docker: handle host-arch selection for all-test-cross) Reviewed-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-ID: <20250804104308.250949-1-alex.bennee@linaro.org>
Stefan Hajnoczi [Mon, 4 Aug 2025 12:56:59 +0000 (08:56 -0400)]
Merge tag 'pull-target-arm-20250801' of https://gitlab.com/pm215/qemu into staging
target-arm queue:
* Add missing 64-bit PMCCNTR in AArch32 mode
* Reinstate bogus AArch32 DBGDTRTX register for migration compat
* fix big-endian handling of AArch64 FPU registers in gdbstub
* fix handling of setting SVE registers from gdbstub
* hw/intc/arm_gicv3_kvm: fix writing of enable/active/pending state to KVM
* hw/display/framebuffer: Add cast to force 64x64 multiply
* tests/tcg: Fix run for tests with specific plugin
* tag 'pull-target-arm-20250801' of https://gitlab.com/pm215/qemu:
tests/tcg: Fix run for tests with specific plugin
target/arm: Fix handling of setting SVE registers from gdb
target/arm: Fix big-endian handling of NEON gdb remote debugging
target/arm: Reinstate bogus AArch32 DBGDTRTX register for migration compat
hw/display/framebuffer: Add cast to force 64x64 multiply
hw/intc/arm_gicv3_kvm: Write all 1's to clear enable/active
hw/intc/arm_gicv3_kvm: Remove writes to ICPENDR registers
target/arm: add support for 64-bit PMCCNTR in AArch32 mode
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Peter Maydell [Mon, 21 Jul 2025 15:33:41 +0000 (16:33 +0100)]
scripts/make-release: Go back to cloning all the EDK2 submodules
In commit bd0da3a3d4f we changed make-release so that instead of
cloning every git submodule of EDK2 we only cloned a fixed list.
The original motivation for this was that one of the submodules:
* was from a non-github repo
* that repo had a "SSL certificate expired" failure
* wasn't actually needed for the set of EDK2 binaries we build
and at the time we were trying to build the EDK2 binaries in one of
our CI jobs.
Unfortunately this change meant that we were exposed to bugs where
EDK2 adds a new submodule and the sources we ship in the release
tarball won't build any more. In particular, in EDK2 commit c6bb7d54beb05 the MipiSysTLib submodule was added, causing failure of
the ROM build in our tarball starting from QEMU release 8.2.0:
/tmp/qemu-10.0.0/roms/edk2/MdePkg/MdePkg.dec(32): error 000E: File/directory not found in workspace
Library/MipiSysTLib/mipisyst/library/include is not found in packages path:
/tmp/qemu-10.0.0/roms/.
/tmp/qemu-10.0.0/roms/edk2
(Building from a QEMU git checkout works fine.)
In the intervening time EDK2 moved the submodule that had a problem
to be one they mirrored themselves (and at time of writing all their
submodules are hosted on github), and we stopped trying to build
EDK2 binaries in our own CI jobs with commit 690ceb71936f9037f6.
Go back to cloning every EDK2 submodule, so we don't have an
untested explicit list of submodules which will break without
our noticing it.
This increases the size of the QEMU tarball .tar.xz file from
133M to 139M in my testing.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3041 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20250721153341.2910800-1-peter.maydell@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Jamin Lin [Mon, 4 Aug 2025 01:46:33 +0000 (09:46 +0800)]
hw/ssi/aspeed_smc: Fix incorrect FMC_WDT2 register read on AST1030
On AST1030, reading the FMC_WDT2 register always returns 0xFFFFFFFF.
This issue is due to the aspeed_smc_read function, which checks for the
ASPEED_SMC_FEATURE_WDT_CONTROL feature. Since AST1030 was missing this
feature flag, the read operation fails and returns -1.
To resolve this, add the WDT_CONTROL feature to AST1030's feature set
so that FMC_WDT2 can be correctly accessed by firmware.
Hao Wu (2):
Automatically search for UBOOT location for NPCM8xx images.
Dynamically detects NPCM8XX UBOOT destination and size.
Jamin Lin (5):
Add initial support for AST27x0
ast27x0: Show build date and git version
ast27x0: Initialize and enable SSP/TSP using SCU with reserved-memory from DTB
ast27x0: Fix missing SCU module reset for SSP and TSP initialization
ast27x0: Fix Makefile to unconditionally set CC to support correct cross-compilation
Compiled with gcc version 13.3.0
Reviewed-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Cédric Le Goater <clg@redhat.com>
7b1eb5f ast27x0: Fix Makefile to unconditionally set CC to support correct cross-compilation 601d410 ast27x0: Fix missing SCU module reset for SSP and TSP initialization 80768e4 ast27x0: Initialize and enable SSP/TSP using SCU with reserved-memory from DTB f8ab635 ast27x0: Show build date and git version 53294f5 Add initial support for AST27x0 b1c2803 Dynamically detects NPCM8XX UBOOT destination and size. 4f54dfc Automatically search for UBOOT location for NPCM8xx images.
Gustavo Romero [Fri, 1 Aug 2025 00:13:05 +0000 (00:13 +0000)]
tests/tcg: Fix run for tests with specific plugin
Commit 25aaf0cb7f (“tests/tcg: reduce the number of plugin test
combinations”) added support for running tests with specific plugins
passed via the EXTRA_RUNS variable.
However, due to the optimization, the rules generated as a shuffled
combination of tests and plugins might not cover the rules required to
run the tests with a specific plugin passed via EXTRA_RUNS.
This commit fixes it by correctly generating the rules for the tests
that require a specific plugin to run, which are now passed via the
EXTRA_RUNS_WITH_PLUGIN instead of via the EXTRA_RUNS variable.
The fix essentially excludes the tests passed via EXTRA_RUNS_WITH_PLUGIN
from the rules created by the shuffled combination of tests and plugins,
to avoid running the tests twice, and generates the rules for the
test/plugin combinations listed in the EXTRA_RUNS_WITH_PLUGIN variable.
target/arm: Fix handling of setting SVE registers from gdb
The code to handle setting SVE registers via the gdbstub is broken:
* it sets each pair of elements in the zregs[].d[] array in the
wrong order for the most common (little endian) case: the least
significant 64-bit value comes first
* it makes no attempt to handle target_endian()
* it does a simple copy out of the (target endian) gdbstub buffer
into the (host endan) zregs data structure, which is wrong on
big endian hosts
Fix all these problems:
* use ldq_p() to read from the gdbstub buffer
* check target_big_endian() to see if we need to handle the
128-bit values the opposite way around
target/arm: Fix big-endian handling of NEON gdb remote debugging
In the code for allowing the gdbstub to set the value of an AArch64
FP/SIMD register, we weren't accounting for target_big_endian()
being true. This meant that for aarch64_be-linux-user we would
set the two halves of the FP register the wrong way around.
The much more common case of a little-endian guest is not affected;
nor are big-endian hosts.
Peter Maydell [Thu, 31 Jul 2025 13:43:38 +0000 (14:43 +0100)]
target/arm: Reinstate bogus AArch32 DBGDTRTX register for migration compat
In commit 655659a74a we fixed some bugs in the encoding of the
Debug Communications Channel registers, including that we were
incorrectly exposing an AArch32 register at p14, 3, c0, c5, 0.
Unfortunately removing a register is a break of forwards migration
compatibility for TCG, because we will fail the migration if the
source QEMU passes us a cpreg which the destination QEMU does not
have. We don't have a mechanism for saying "it's OK to ignore this
sysreg in the inbound data", so for the 10.1 release reinstate the
incorrect AArch32 register.
(We probably have had other cases in the past of breaking migration
compatibility like this, but we didn't notice because we didn't test
and in any case not that many people care about TCG migration
compatibility. KVM migration compat is not affected because for KVM
we treat the kernel as the source of truth for what system registers
are present.)
Peter Maydell [Thu, 10 Jul 2025 17:43:12 +0000 (18:43 +0100)]
hw/display/framebuffer: Add cast to force 64x64 multiply
In framebuffer_update_display(), Coverity complains because we
multiply two values of type 'int' (which will be done as a 32x32
multiply and so in theory might overflow) and then add the result to
a ram_addr_t, which can be 64 bits.
4GB framebuffers are not plausible anyway, but keep Coverity happy
by adding casts which force these multiplies to be done as 64x64.
hw/intc/arm_gicv3_kvm: Write all 1's to clear enable/active
KVM's userspace access interface to the GICD enable and active bits
is via set/clear register pairs which implement the hardware's "write
1s to the clear register to clear the 0 bits, and write 1s to the set
register to set the 1 bits" semantics. We didn't get this right,
because we were writing 0 to the clear register.
Writing 0 to GICD_IC{ENABLE,ACTIVE}R architecturally has no effect on
interrupt status (all writes are simply ignored by KVM) and doesn't
comply with the intention of "first write to the clear-reg to clear
all bits".
Write all 1's to actually clear the enable/active status.
This didn't have any adverse effects on migration because there
we start with a clean VM state; it would be guest-visible when
doing a system reset, but since Linux always cleans up the
register state of the GIC during bootup before it enables it
most users won't have run into a problem here.
projects / thirdparty / qemu.git / log
