Branch: refs/heads/staging-10.0
Home: https://github.com/qemu/qemu
Commit: 83aeacaafa0aa1f11ca65c05b22fb284037d5257
https://github.com/qemu/qemu/commit/83aeacaafa0aa1f11ca65c05b22fb284037d5257
Author: Cornelia Huck <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M tests/functional/test_vnc.py
Log Message:
-----------
tests/functional/test_vnc: skip test if no crypto backend available
The test_change_password test will fail if no cryptographic backend is
available (e.g. if QEMU was built on a system with no cryptographic
library development packages installed); just skip the test in that
case.
Signed-off-by: Cornelia Huck <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 4e3823c68cc5ce04756a8f11d1ec9c18172f0bd3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d18488775f4faddd3e0666e370f7fc40f0711147
https://github.com/qemu/qemu/commit/d18488775f4faddd3e0666e370f7fc40f0711147
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M .gitlab-ci.d/buildtest-template.yml
M .gitlab-ci.d/buildtest.yml
Log Message:
-----------
gitlab-ci: Remove the avocado tests from the CI pipelines
We are going to move the remaining Avocado tests step by step
into the functional test framework. Unfortunately, Avocado fails
with an error if it cannot determine a test to run, so disable
the tests here now to avoid failures in the Gitlab-CI during the
next steps.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 22baa5f340d4fe3e7f271d275367b806ef3da834)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1c491b71863cf40f9c413fef3637d2b906a70da2
https://github.com/qemu/qemu/commit/1c491b71863cf40f9c413fef3637d2b906a70da2
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M tests/avocado/boot_linux_console.py
M tests/functional/qemu_test/tuxruntest.py
Log Message:
-----------
tests/functional: Move the check for the parameters from avocado to functional
test_x86_64_pc in tests/avocado/boot_linux_console.py only checks
whether the kernel parameters have correctly been passed to the
kernel in the guest by looking for them in the console output of the
guest. Let's move that to the functional test framework now, but
instead of doing it in a separate test, let's do it for all tuxrun
tests instead, so it is done automatically for all targets that have
a tuxrun test.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit bc65ae696104c15e52a5e26f225b689e2c2cdba6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c4747e3bebcb937f304f1dca52533817cd1ab972
https://github.com/qemu/qemu/commit/c4747e3bebcb937f304f1dca52533817cd1ab972
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M MAINTAINERS
R tests/avocado/reverse_debugging.py
M tests/functional/meson.build
A tests/functional/reverse_debugging.py
A tests/functional/test_aarch64_reverse_debug.py
A tests/functional/test_ppc64_reverse_debug.py
A tests/functional/test_x86_64_reverse_debug.py
Log Message:
-----------
tests/functional: Convert reverse_debugging tests to the functional framework
These tests are using the gdb-related library functions from the
Avocado framework which we don't have in the functional framework
yet. So for the time being, keep those imports and skip the test
if the Avocado framework is not installed on the host.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 951ededf12a89534195cf5c5210242a169a85656)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 27cfc5ea42ca91c9acdad51aaa4e6ea442aab22e
https://github.com/qemu/qemu/commit/27cfc5ea42ca91c9acdad51aaa4e6ea442aab22e
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M MAINTAINERS
R tests/avocado/replay_kernel.py
M tests/functional/meson.build
A tests/functional/test_i386_replay.py
Log Message:
-----------
tests/functional: Convert the i386 replay avocado test
Since this was the last test in tests/avocado/replay_kernel.py,
we can remove that Avocado file now.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 0e756f404d73ddf7b5506e9109e2c074f30fb79e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f95d41b486238ed7cff3a1168cec99c5ab289281
https://github.com/qemu/qemu/commit/f95d41b486238ed7cff3a1168cec99c5ab289281
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
R tests/avocado/boot_linux_console.py
Log Message:
-----------
tests/avocado: Remove the LinuxKernelTest class
All tests that used this class have been converted to the functional
framework, so we can remove the boot_linux_console.py file now.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 574f71bc1f22640d45a90969805eaaacd38bf859)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ebfa6996dc912aaf0accb45a3895f03ddc97d051
https://github.com/qemu/qemu/commit/ebfa6996dc912aaf0accb45a3895f03ddc97d051
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M tests/avocado/linux_ssh_mips_malta.py
M tests/functional/meson.build
M tests/functional/test_mips_malta.py
Log Message:
-----------
tests/functional: Convert the 32-bit big endian Wheezy mips test
The test checks some entries in /proc and the output of some commands ...
we put these checks into exportable functions now so that they can
be reused more easily.
Additionally the linux_ssh_mips_malta.py uses SSH to test the networking
of the guest. Since we don't have a SSH module in the functional
framework yet, let's use the check_http_download() function here instead.
And while we're at it, also switch the NIC to e1000 now to get some more
test coverage, since the "pcnet" device is already tested in the test
test_mips_malta_cpio.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 42a87f0ce7aaf1923a610cabe4d65f7b1ce9a327)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 902fc01dc232b9f32aff26bec25f4ea4a61ecb37
https://github.com/qemu/qemu/commit/902fc01dc232b9f32aff26bec25f4ea4a61ecb37
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M tests/avocado/linux_ssh_mips_malta.py
M tests/functional/meson.build
M tests/functional/test_mipsel_malta.py
Log Message:
-----------
tests/functional: Convert the 32-bit little endian Wheezy mips test
Reuse the test function from the big endian test to easily
convert the 32-bit little endian Wheezy mips test.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 689a8b56a6f3d16458004006b604950295da87df)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9821c1cb601a192edfff530cc8996e4f7daee96c
https://github.com/qemu/qemu/commit/9821c1cb601a192edfff530cc8996e4f7daee96c
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M tests/avocado/linux_ssh_mips_malta.py
M tests/functional/meson.build
M tests/functional/test_mips64el_malta.py
Log Message:
-----------
tests/functional: Convert the 64-bit little endian Wheezy mips test
Reuse the test function from the 32-bit big endian test to easily
convert the 64-bit little endian Wheezy mips test.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 8e3461c3a6fc0b1bce4571e46e861db0b2bcf621)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0236373fa6a173bf823e7a9421fff134bcafdf4c
https://github.com/qemu/qemu/commit/0236373fa6a173bf823e7a9421fff134bcafdf4c
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M MAINTAINERS
R tests/avocado/linux_ssh_mips_malta.py
M tests/functional/meson.build
A tests/functional/test_mips64_malta.py
Log Message:
-----------
tests/functional: Convert the 64-bit big endian Wheezy mips test
Reuse the test function from the 32-bit big endian test to easily
convert the 64-bit big endian Wheezy mips test.
Since this was the last test in tests/avocado/linux_ssh_mips_malta.py,
we can remove this avocado file now, too.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit f79592f427d7faabb25d533815d6c3dd4ab9726d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d50027a984ff5992750454b3780e88d2a138a5a8
https://github.com/qemu/qemu/commit/d50027a984ff5992750454b3780e88d2a138a5a8
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
R tests/avocado/boot_linux.py
Log Message:
-----------
tests/avocado: Remove the boot_linux.py tests
These tests are based on the cloudinit functions from Avocado.
The cloudinit is very, very slow compared to our other tests,
so most of these Avocado tests have either been disabled by default
with a decorator, or have been marked to only run with KVM.
We won't include this sluggish cloudinit stuff in the functional
framework, and we've already got plenty of other tests there that
check pretty much the same things, so let's simply get rid of these
old tests now.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e83aee9c6a0f169e8c5d9387f2429ec8f539dda9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 43d94f4c415431d4234dd1f6f985892d64630d56
https://github.com/qemu/qemu/commit/43d94f4c415431d4234dd1f6f985892d64630d56
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M tests/avocado/replay_linux.py
M tests/functional/test_x86_64_replay.py
Log Message:
-----------
tests/functional: Use the tuxrun kernel for the x86 replay test
This way we can do a full boot in record-replay mode and
should get a similar test coverage compared to the old
replay test from tests/avocado/replay_linux.py. Thus remove
the x86 avocado replay_linux test now.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 7fecdb0acd99fa838bb461c67164f6119ec1a3bb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 26267e726df4adee4af3fec82965ac0c56469bea
https://github.com/qemu/qemu/commit/26267e726df4adee4af3fec82965ac0c56469bea
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M MAINTAINERS
R tests/avocado/replay_linux.py
M tests/functional/test_aarch64_replay.py
Log Message:
-----------
tests/functional: Use the tuxrun kernel for the aarch64 replay test
This way we can do a full boot in record-replay mode and
should get a similar test coverage compared to the old
replay test from tests/avocado/replay_linux.py.
Since the aarch64 test was the last avocado test in the
tests/avocado/replay_linux.py file, we can remove this
file now completely.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit a820caf8444c963faf69228e4a0a0d4673c24ab5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: eb45f72de08baf106848a08cd68d7d7984a2aa50
https://github.com/qemu/qemu/commit/eb45f72de08baf106848a08cd68d7d7984a2aa50
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M MAINTAINERS
R tests/avocado/smmu.py
M tests/functional/meson.build
A tests/functional/test_aarch64_smmu.py
Log Message:
-----------
tests/functional: Convert the SMMU test to the functional framework
This test was using cloudinit and a "dnf install" command in the guest
to exercise the NIC with SMMU enabled. Since we don't have the cloudinit
stuff in the functional framework and we should not rely on having access
to external networks (once our ASSETs have been cached), we rather boot
into the initrd first, manually mount the root disk and then use the
check_http_download() function from the functional framework here instead
for testing whether the network works as expected.
Unfortunately, there seems to be a small race when using the files
from Fedora 33: To enter the initrd shell, we have to send a "return"
once. But it does not seem to work if we send it too early. Using a
sleep(0.2) makes it work reliably for me, but to make it even more
unlikely to trigger this situation, let's better limit the Fedora 33
tests to only run with KVM.
Finally, while we're at it, we also add some lines for testing writes
to the hard disk, as we already do it in the test_intel_iommu test.
Reviewed-by: Eric Auger <[email protected]>
Tested-by: Eric Auger <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 5c2bae2155b162f7355ca759881c5fdaaf7bc209)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bb4444ba8f1a3a38e4df69e7e13fa56b7351d36b
https://github.com/qemu/qemu/commit/bb4444ba8f1a3a38e4df69e7e13fa56b7351d36b
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M .gitlab-ci.d/base.yml
M .gitlab-ci.d/buildtest-template.yml
M docs/devel/testing/ci-jobs.rst.inc
Log Message:
-----------
gitlab-ci: Update QEMU_JOB_AVOCADO and QEMU_CI_AVOCADO_TESTING
Since we don't run the Avocado jobs in the CI anymore, rename
these variables to QEMU_JOB_FUNCTIONAL and QEMU_CI_FUNCTIONAL.
Also, there was a mismatch between the documentation and the
implementation of QEMU_CI_AVOCADO_TESTING: While the documentation
said that you had to "Set this variable to have the tests using the
Avocado framework run automatically", you indeed needed to set it
to make the pipelines appear in your dashboard - but they were never
run automatically in forks and had to be triggered manually. Let's
improve this now: No need to hide these pipelines from the users
by default anymore (the functional tests should be stable enough
nowadays), and rather allow the users to run the pipelines auto-
matically with this switch now instead, as was documented.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit f8c54844175922d77faa8b586f451e379d53a191)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0818105ab6e70ee8e5e592a7c9b353fe74614143
https://github.com/qemu/qemu/commit/0818105ab6e70ee8e5e592a7c9b353fe74614143
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
R docs/devel/testing/ci-definitions.rst.inc
M docs/devel/testing/ci.rst
M docs/devel/testing/main.rst
Log Message:
-----------
docs/devel/testing: Dissolve the ci-definitions.rst.inc file
This file was meant for defining the vocabulary for our testing
efforts, but it did not age well: First, the definitions are not
only about the CI part, but also about testing in general, so most
of the information should rather reside in main.rst instead.
Second, some vocabulary has never been really adopted by the QEMU
project, for example we never really use the word "system testing"
since "system" rather means the system emulator binaries in the
QEMU project (and we also don't do any testing with other components
like libvirt and virt-managers here). It also defines that the qtests
are the "functional" tests in QEMU, which is not really up to date
anymore after the "tests/functional" framework has been introduced
a couple of months ago (FWIW, the qtests could rather be seen as a
mix between unit testing and functional testing).
To solve this problem, move the useful parts of this file into
main.rst and directly into ci.rst, and drop the ones (like "system
testing") that we don't really need anymore.
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 5748e464150911127d07c0b7adeea474fd905149)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cf4b882ed375a2af0abb191ff81b2cfd4173dc98
https://github.com/qemu/qemu/commit/cf4b882ed375a2af0abb191ff81b2cfd4173dc98
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M MAINTAINERS
M configure
M docs/about/build-platforms.rst
M docs/devel/build-system.rst
M docs/devel/codebase.rst
R docs/devel/testing/avocado.rst
M docs/devel/testing/functional.rst
M docs/devel/testing/index.rst
M docs/devel/testing/main.rst
M pythondeps.toml
M tests/Makefile.include
R tests/avocado/README.rst
R tests/avocado/avocado_qemu/__init__.py
R tests/avocado/avocado_qemu/linuxtest.py
Log Message:
-----------
Remove the remainders of the Avocado tests
Now that all Avocado tests have been converted to or been replaced by
other functional tests, we can delete the remainders of the Avocado
tests from the QEMU source tree.
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 52e9ed6d3ac44424e098333772077a41bb88c4db)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 112d01ce9f4bf7de27159d46d116971e5a82a3ae
https://github.com/qemu/qemu/commit/112d01ce9f4bf7de27159d46d116971e5a82a3ae
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M tests/functional/aspeed.py
M tests/functional/test_aarch64_aspeed.py
M tests/functional/test_arm_aspeed_ast2500.py
M tests/functional/test_arm_aspeed_ast2600.py
M tests/functional/test_arm_aspeed_bletchley.py
M tests/functional/test_arm_aspeed_palmetto.py
M tests/functional/test_arm_aspeed_romulus.py
M tests/functional/test_arm_aspeed_witherspoon.py
M tests/functional/test_arm_bpim2u.py
M tests/functional/test_arm_cubieboard.py
M tests/functional/test_arm_orangepi.py
M tests/functional/test_s390x_topology.py
Log Message:
-----------
tests/functional: Remove semicolons at the end of lines
Yes, we are all C coders who try to write Python code for testing...
but still, let's better avoid semicolons at the end of the lines
to keep "pylint" happy!
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Nina Schoetterl-Glausch <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 858640eaee9f3039580118f5629825825cea311a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bb09656bdf1957c70fd59e2e64974f4a9ca750cf
https://github.com/qemu/qemu/commit/bb09656bdf1957c70fd59e2e64974f4a9ca750cf
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M tests/functional/qemu_test/ports.py
M tests/functional/qemu_test/tuxruntest.py
M tests/functional/qemu_test/uncompress.py
M tests/functional/test_aarch64_rme_sbsaref.py
M tests/functional/test_aarch64_rme_virt.py
M tests/functional/test_aarch64_sbsaref_alpine.py
M tests/functional/test_aarch64_sbsaref_freebsd.py
M tests/functional/test_aarch64_tcg_plugins.py
M tests/functional/test_aarch64_virt.py
M tests/functional/test_arm_aspeed_ast2500.py
M tests/functional/test_arm_cubieboard.py
M tests/functional/test_arm_quanta_gsj.py
M tests/functional/test_arm_smdkc210.py
M tests/functional/test_migration.py
M tests/functional/test_mips64el_replay.py
M tests/functional/test_mips_replay.py
M tests/functional/test_mipsel_replay.py
M tests/functional/test_ppc64_hv.py
M tests/functional/test_vnc.py
M tests/functional/test_x86_64_kvm_xen.py
Log Message:
-----------
tests/functional: Remove unnecessary import statements
pylint complains about these unnecessary import statements,
so let's remove them.
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 99fb9256b761c3cec4a82d2e9597b6cf24ae1285)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 62f897b7d3e080e1c88e7dfb4e3912771fdd4f7b
https://github.com/qemu/qemu/commit/62f897b7d3e080e1c88e7dfb4e3912771fdd4f7b
Author: Thomas Huth <[email protected]>
Date: 2025-11-23 (Sun, 23 Nov 2025)
Changed paths:
M MAINTAINERS
Log Message:
-----------
MAINTAINERS: Add functional tests that are not covered yet
Some functional tests are currently not covered by the entries
in MAINTAINERS yet, so scripts/get_maintainers.pl fails to suggest
the right people who should be CC:-ed for related patches.
Add the uncovered tests to the right sections to close this gap.
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit 12c6b6153063aafcdbadca8fee7eac793ef85e4b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 20a7e4d3e77f23fdded02f4a5bd2184ca895bb03
https://github.com/qemu/qemu/commit/20a7e4d3e77f23fdded02f4a5bd2184ca895bb03
Author: Jack Wang <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M hw/virtio/virtio-qmp.c
Log Message:
-----------
qmp: Fix a typo for a USO feature
There is a copy & paste error, USO6 should be there.
Fixes: 58f81689789f ("qmp: update virtio feature maps, vhost-user-gpio
introspection")
Signed-off-by: Jack Wang <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 5fbcbf76a19a0d3500a4103fc8876c6cace2afcf)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c41f52f5d7189ca3d9bb84f3ae3b1d3e23714c8c
https://github.com/qemu/qemu/commit/c41f52f5d7189ca3d9bb84f3ae3b1d3e23714c8c
Author: Li Zhijian <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Fix transition to COLO state from precopy
Commit 4881411136 ("migration: Always set DEVICE state") set a new DEVICE
state before completed during migration, which broke the original transition
to COLO. The migration flow for precopy has changed to:
active -> pre-switchover -> device -> completed.
This patch updates the transition state to ensure that the Pre-COLO
state corresponds to DEVICE state correctly.
Cc: qemu-stable <[email protected]>
Fixes: 4881411136 ("migration: Always set DEVICE state")
Signed-off-by: Li Zhijian <[email protected]>
Reviewed-by: Zhang Chen <[email protected]>
Tested-by: Zhang Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 0b5bf4ea76205a93386c5e02fbb519871a62e677)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f78cda72cbe0c39aa77ca97184278bec0c5ce5e0
https://github.com/qemu/qemu/commit/f78cda72cbe0c39aa77ca97184278bec0c5ce5e0
Author: Jamin Lin <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M hw/arm/aspeed_ast10x0.c
M hw/arm/aspeed_ast2600.c
M hw/arm/aspeed_ast27x0.c
Log Message:
-----------
hw/arm/aspeed: Fix missing SPI IRQ connection causing DMA interrupt failure
It did not connect SPI IRQ to the Interrupt Controller, so even the SPI
model raised the IRQ, the interrupt was not received. The CPU therefore
did not trigger an interrupt via the controller, and the firmware never
received the interrupt.
Fixes: 356b230ed13889e09d087a96498887de695df17e ("aspeed/soc: Add AST1030
support")
Fixes: f25c0ae1079dc0b9de02676eb3e3949a09df9f41 ("aspeed/soc: Add AST2600
support")
Fixes: 5dd883ab0635c9f715c77cc32622e458a0724581 ("aspeed/soc: Add AST2700
support")
Signed-off-by: Jamin Lin <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Link:
https://lore.kernel.org/qemu-devel/[email protected]
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 510d5c61ad3eb1690b61c804d38c984527a5ea62)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 35819127d1b0281189fa9f4e23663844c78cb861
https://github.com/qemu/qemu/commit/35819127d1b0281189fa9f4e23663844c78cb861
Author: Peter Maydell <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M hw/arm/armv7m.c
Log Message:
-----------
hw/arm/armv7m: Disable reentrancy guard for v7m_sysreg_ns_ops MRs
For M-profile cores which support TrustZone, there are some memory
areas which are "NS aliases" -- a Secure access to these addresses
really performs an NS access to a different part of the device. We
implement these using MemoryRegionOps read and write functions which
pass the access on with adjusted attributes using
memory_region_dispatch_read() and memory_region_dispatch_write().
Since the MR we are dispatching to is owned by the same device that
owns the NS-alias MR (the TYPE_ARMV7M container object), this trips
the reentrancy-guard that is applied by access_with_adjusted_size().
Mark the NS alias MemoryRegions as disable_reentrancy_guard; this is
safe because v7m_sysreg_ns_read() and v7m_sysreg_ns_write() do not
touch any of the device's state. (Any further reentrancy attempts by
the underlying MR will still be caught.)
Without this fix, an attempt to read from an address like 0xe002e010,
which is a register in the NS systick alias, will fail and provoke
qemu-system-arm: warning: Blocked re-entrant IO on MemoryRegion: v7m_systick
at addr: 0x0
We didn't notice this earlier because almost all code accesses
the registers and systick via the non-alias addresses; the NS
aliases are only need for the rarer case of Secure code that needs
to manage the NS timer or system state on behalf of NS code.
Note that although the v7m_systick_ops read and write functions
also call memory_region_dispatch_{read,write}, this MR does not
need to have the reentrancy-guard disabled because the underlying
MR that it forwards to is owned by a different device (the
TYPE_SYSTICK timer device).
Reported via a stackoverflow question:
https://stackoverflow.com/questions/79808107/what-this-error-is-even-about-qemu-system-arm-warning-blocked-re-entrant-io
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 4a934d284dfac9fa19b0f47874f12d9b3519c21c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f4fa2d06dd0404c02273f677d08b9d0330a14d9c
https://github.com/qemu/qemu/commit/f4fa2d06dd0404c02273f677d08b9d0330a14d9c
Author: Peter Maydell <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M hw/display/exynos4210_fimd.c
Log Message:
-----------
hw/display/exynos4210_fimd: Account for zero length in
fimd_update_memory_section()
In fimd_update_memory_section() we attempt ot find and map part of
the RAM MR which backs the framebuffer, based on guest-configurable
size and start address.
If the guest configures framebuffer settings which result in a
zero-sized framebuffer, we hit an assertion(), because
memory_region_find() will return a NULL mem_section.mr.
Explicitly check for the zero-size case and treat this as a
guest error.
Because we now have a code path which can reach error_return without
calling memory_region_find to set w->mem_section, we must NULL out
w->mem_section.mr after the unref of the old MR, so that error_return
does not incorrectly double-unref the old MR.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1407
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 579be921f509fb9d2deccc4233496e36b221abb3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1978079d2a9acb866b36203eb6e5c94eb0132bdc
https://github.com/qemu/qemu/commit/1978079d2a9acb866b36203eb6e5c94eb0132bdc
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M chardev/char-pty.c
Log Message:
-----------
chardev/char-pty: Do not ignore chr_write() failures
Cc: [email protected]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 303f6049358e2ef35f2b107d6bd1a5be07ec35e9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b3c10df2e28c6c0e76a1e994b6d3a93e40aa634e
https://github.com/qemu/qemu/commit/b3c10df2e28c6c0e76a1e994b6d3a93e40aa634e
Author: [email protected] <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M ui/vnc.c
Log Message:
-----------
ui/vnc: Fix qemu abort when query vnc info
When there is no display device on qemu machine,
and user only access qemu by remote vnc.
At the same time user input `info vnc` by QMP,
the qemu will abort.
To avoid the abort above, I add display device check,
when query vnc info in qmp_query_vnc_servers().
Reviewed-by: Marc-AndréLureau <[email protected]>
Signed-off-by: Alano Song <[email protected]>
[ Marc-André - removed useless Error *err ]
Signed-off-by: Marc-André Lureau <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 4c1646e23f761e3dc6d88c8995f13be8f668a012)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9d496598dae1fbbc450d905846a064c1edd4f063
https://github.com/qemu/qemu/commit/9d496598dae1fbbc450d905846a064c1edd4f063
Author: Kevin Wolf <[email protected]>
Date: 2025-11-25 (Tue, 25 Nov 2025)
Changed paths:
M block/block-backend.c
Log Message:
-----------
block-backend: Fix race when resuming queued requests
When new requests arrive at a BlockBackend that is currently drained,
these requests are queued until the drain section ends.
There is a race window between blk_root_drained_end() waking up a queued
request in an iothread from the main thread and blk_wait_while_drained()
actually being woken up in the iothread and calling blk_inc_in_flight().
If the BlockBackend is drained again during this window, drain won't
wait for this request and it will sneak in when the BlockBackend is
already supposed to be quiesced. This causes assertion failures in
bdrv_drain_all_begin() and can have other unintended consequences.
Fix this by increasing the in_flight counter immediately when scheduling
the request to be resumed so that the next drain will wait for it to
complete.
Cc: [email protected]
Reported-by: Andrey Drobyshev <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Hanna Czenczek <[email protected]>
Tested-by: Andrey Drobyshev <[email protected]>
Reviewed-by: Fiona Ebner <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 8eeaa706ba73251063cb80d87ae838d2d5b08e9a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: eb3e5de4500bc92a14cf17ce46aefc745cdcfe5a
https://github.com/qemu/qemu/commit/eb3e5de4500bc92a14cf17ce46aefc745cdcfe5a
Author: Fiona Ebner <[email protected]>
Date: 2025-11-26 (Wed, 26 Nov 2025)
Changed paths:
M block/io_uring.c
Log Message:
-----------
block/io_uring: avoid potentially getting stuck after resubmit at the end of
ioq_submit()
Note that this issue seems already fixed as a consequence of the large
io_uring rework with 047dabef97 ("block/io_uring: use aio_add_sqe()")
in current master, so this is purely for QEMU stable branches.
At the end of ioq_submit(), there is an opportunistic call to
luring_process_completions(). This is the single caller of
luring_process_completions() that doesn't use the
luring_process_completions_and_submit() wrapper.
Other callers use the wrapper, because luring_process_completions()
might require a subsequent call to ioq_submit() after resubmitting a
request. As noted for luring_resubmit():
> Resubmit a request by appending it to submit_queue. The caller must ensure
> that ioq_submit() is called later so that submit_queue requests are started.
So the caller at the end of ioq_submit() violates the contract and can
in fact be problematic if no other requests come in later. In such a
case, the request intended to be resubmitted will never be actually be
submitted via io_uring_submit().
A reproducer exposing this issue is [0], which is based on user
reports from [1]. Another reproducer is iotest 109 with '-i io_uring'.
I had the most success to trigger the issue with [0] when using a
BTRFS RAID 1 storage. With tmpfs, it can take quite a few iterations,
but also triggers eventually on my machine. With iotest 109 with '-i
io_uring' the issue triggers reliably on my ext4 file system.
Have ioq_submit() submit any resubmitted requests after calling
luring_process_completions(). The return value from io_uring_submit()
is checked to be non-negative before the opportunistic processing of
completions and going for the new resubmit logic, to ensure that a
failure of io_uring_submit() is not missed. Also note that the return
value already was not necessarily the total number of submissions,
since the loop might've been iterated more than once even before the
current change.
Only trigger the resubmission logic if it is actually necessary to
avoid changing behavior more than necessary. For example iotest 109
would produce more 'mirror ready' events if always resubmitting after
luring_process_completions() at the end of ioq_submit().
Note iotest 109 still does not pass as is when run with '-i io_uring',
because of two offset values for BLOCK_JOB_COMPLETED events being zero
instead of non-zero as in the expected output. Note that the two
affected test cases are expected failures and still fail, so they just
fail "faster". The test cases are actually not triggering the resubmit
logic, so the reason seems to be different ordering of requests and
completions of the current aio=io_uring implementation versus
aio=threads.
[0]:
> #!/bin/bash -e
> #file=/mnt/btrfs/disk.raw
> file=/tmp/disk.raw
> filesize=256
> readsize=512
> rm -f $file
> truncate -s $filesize $file
> ./qemu-system-x86_64 --trace '*uring*' --qmp stdio \
> --blockdev
> raw,node-name=node0,file.driver=file,file.cache.direct=off,file.filename=$file,file.aio=io_uring
> \
> <<EOF
> {"execute": "qmp_capabilities"}
> {"execute": "human-monitor-command", "arguments": { "command-line": "qemu-io
> node0 \"read 0 $readsize \"" }}
> {"execute": "quit"}
> EOF
[1]: https://forum.proxmox.com/threads/170045/
Cc: [email protected]
Signed-off-by: Fiona Ebner <[email protected]>
Reviewed-by: Stefan Hajnoczi <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 58c32325f240cae2a9a263635e644a91e1e5dd43
https://github.com/qemu/qemu/commit/58c32325f240cae2a9a263635e644a91e1e5dd43
Author: Peter Maydell <[email protected]>
Date: 2025-11-26 (Wed, 26 Nov 2025)
Changed paths:
M hw/pci/msix.c
M include/hw/pci/msix.h
Log Message:
-----------
hw/pci: Make msix_init take a uint32_t for nentries
msix_init() and msix_init_exclusive_bar() take an "unsigned short"
argument for the number of MSI-X vectors to try to use. This is big
enough for the maximum permitted number of vectors, which is 2048.
Unfortunately, we have several devices (most notably virtio) which
allow the user to specify the desired number of vectors, and which
use uint32_t properties for this. If the user sets the property to a
value that is too big for a uint16_t, the value will be truncated
when it is passed to msix_init(), and msix_init() may then return
success if the truncated value is a valid one.
The resulting mismatch between the number of vectors the msix code
thinks the device has and the number of vectors the device itself
thinks it has can cause assertions, such as the one in issue 2631,
where "-device virtio-mouse-pci,vectors=19923041" is interpreted by
msix as "97 vectors" and by the virtio-pci layer as "19923041
vectors"; a guest attempt to access vector 97 thus passes the
virtio-pci bounds checking and hits an essertion in
msix_vector_use().
Avoid this by making msix_init() and its wrapper function
msix_init_exclusive_bar() take the number of vectors as a uint32_t.
The erroneous command line will now produce the warning
qemu-system-i386: -device virtio-mouse-pci,vectors=19923041:
warning: unable to init msix vectors to 19923041
and proceed without crashing. (The virtio device warns and falls
back to not using MSIX, rather than complaining that the option is
not a valid value this is the same as the existing behaviour for
values that are beyond the MSI-X maximum possible value but fit into
a 16-bit integer, like 2049.)
To ensure this doesn't result in potential overflows in calculation
of the BAR size in msix_init_exclusive_bar(), we duplicate the
nentries error-check from msix_init() at the top of
msix_init_exclusive_bar(), so we know nentries is sane before we
start using it.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2631
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit ef44cc0a762438ebc84c4997a5ce29c6f00622c3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 475563823c6a40c0fd91841bc9efaa3e5fd37f45
https://github.com/qemu/qemu/commit/475563823c6a40c0fd91841bc9efaa3e5fd37f45
Author: Peter Xu <[email protected]>
Date: 2025-11-26 (Wed, 26 Nov 2025)
Changed paths:
M hw/core/machine.c
Log Message:
-----------
hw/core/machine: Provide a description for aux-ram-share property
It was forgotten when being introduced in commit 91792807d1 ("machine:
aux-ram-share option").
Cc: [email protected]
Reported-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Xu <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 98ee8aa92e930a447c6108d4689f0bf8b535359d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 88c28f9f9c9c514563af7be2d51a22ac882b3878
https://github.com/qemu/qemu/commit/88c28f9f9c9c514563af7be2d51a22ac882b3878
Author: Cédric Le Goater <[email protected]>
Date: 2025-11-26 (Wed, 26 Nov 2025)
Changed paths:
M hw/misc/aspeed_xdma.c
M hw/rtc/aspeed_rtc.c
M hw/sd/aspeed_sdhci.c
Log Message:
-----------
hw/aspeed/{xdma, rtc, sdhci}: Fix endianness to DEVICE_LITTLE_ENDIAN
When the XDMA, RTC and SDHCI device models of the Aspeed SoCs were
first introduced, their MMIO regions inherited of a DEVICE_NATIVE_ENDIAN
endianness. It should be DEVICE_LITTLE_ENDIAN. Fix that.
Signed-off-by: Cédric Le Goater <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 57756aa01fe52c50d655929c43d9a80f8214cf1a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 06793a36b7a2dc724346067b0a011fbc57df4445
https://github.com/qemu/qemu/commit/06793a36b7a2dc724346067b0a011fbc57df4445
Author: Harald van Dijk <[email protected]>
Date: 2025-12-02 (Tue, 02 Dec 2025)
Changed paths:
M target/arm/tcg/translate-a64.c
Log Message:
-----------
target/arm: Fix assert on BRA.
trans_BRA does
gen_a64_set_pc(s, dst);
set_btype_for_br(s, a->rn);
gen_a64_set_pc does
s->pc_save = -1;
set_btype_for_br (if aa64_bti is enabled and the register is not x16 or
x17) does
gen_pc_plus_diff(s, pc, 0);
gen_pc_plus_diff does
assert(s->pc_save != -1);
Hence, this assert is getting hit. We need to call set_btype_for_br
before gen_a64_set_pc, and there is nothing in set_btype_for_br that
depends on gen_a64_set_pc having already been called, so this commit
simply swaps the calls.
(The commit message for 64678fc45d8f6 says that set_brtype_for_br()
must be "moved after" get_a64_set_pc(), but this is a mistake in
the commit message -- the actual changes in that commit move
set_brtype_for_br() *before* get_a64_set_pc() and this is necessary
to avoid the assert.)
Cc: [email protected]
Fixes: 64678fc45d8f6 ("target/arm: Fix BTI versus CF_PCREL")
Signed-off-by: Harald van Dijk <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
[PMM: added note about 64678fc45d8f6 to commit message]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 7248dab3c9d73fcefe609f7a3414f9d048fefcc1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 95b0af630fd5a01209f0a24b6a5db7b8c9f2c281
https://github.com/qemu/qemu/commit/95b0af630fd5a01209f0a24b6a5db7b8c9f2c281
Author: Peter Maydell <[email protected]>
Date: 2025-12-02 (Tue, 02 Dec 2025)
Changed paths:
M docs/devel/submitting-a-pull-request.rst
Log Message:
-----------
docs/devel: Update URL for make-pullreq script
In the submitting-a-pull-request docs, we have a link to the
make-pullreq script which might be useful for maintainers. The
canonical git repo for this script has moved; update the link.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-id: [email protected]
(cherry picked from commit ebb625262c7f9837d6c7b9d8a0c1349fe8a8f4ff)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ed6a627f85b7ce21f253215feb578cdd8fb028cf
https://github.com/qemu/qemu/commit/ed6a627f85b7ce21f253215feb578cdd8fb028cf
Author: Markus Armbruster <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M accel/kvm/kvm-all.c
Log Message:
-----------
kvm: Fix kvm_vm_ioctl() and kvm_device_ioctl() return value
These functions wrap ioctl(). When ioctl() fails, it sets @errno.
The wrappers then return that @errno negated.
Except they call accel_ioctl_end() between calling ioctl() and reading
@errno. accel_ioctl_end() can clobber @errno, e.g. when a futex()
system call fails. Seems unlikely, but it's a bug all the same.
Fix by retrieving @errno before calling accel_ioctl_end().
Fixes: a27dd2de68f3 (KVM: keep track of running ioctls)
Signed-off-by: Markus Armbruster <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 88be119fb19b8ee04d681ad9048cde9f6a37c631)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/e3f70ada9095...ed6a627f85b7
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
