You cannot build any softmmu targets without it by default unless you
build with --disable-install-blobs.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20251204194902.1340008-5-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
QEMU iotests 049, 134 and 158 are currently failing if you compiled
QEMU without the crypto libraries. Thus make sure that the "secret"
object is really usable and skip the tests otherwise.
Reported-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20251205130014.693799-1-thuth@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Currently configure can identify all the targets that have
cross-compilers available from the supplied target-list. By default
this is the default_target_list which is all possible targets we can
build.
At the same time the target list passed to meson is filtered down
depending on various factors including not building 64 bit targets on
32 bit hosts. As a result make check-tcg will erroneously attempt to
run tests for which we haven't built a QEMU.
Solve this by filtering the final list of TCG_TEST_TARGETS based on
what actually was configured by meson. Rename the variable that
configure spits out to TCG_TESTS_WITH_COMPILERS for clarity and to
avoid larger churn in the Makefile.
Message-ID: <20251204194902.1340008-4-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
The FreeBSD 14.2 job fails since the image disappeared
from the cloud. We already bumped FreeBSD image to 14.3
in tests/vm in c8958b7eb4 (part of v10.1.0).
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20251204205025.2423326-1-mjt@tls.msk.ru>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
This needs libslirp to run and as debian-all-test-cross will soon be
based on qemu-minimal we won't have it in a few commits.
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20251204194902.1340008-3-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Since we have upgraded to 24.04 with its new libc we no longer need
this workaround.
Link: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1987438
Suggested-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20251204194902.1340008-2-alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
When introducing DM_MPATH_PROBE_PATHS, we already anticipated that
dm-multipath devices might be suspended for a short time when the DM
tables are reloaded and that they return -EAGAIN in this case. We then
wait for a millisecond and retry.
However, meanwhile it has also turned out that libmpathpersist (which is
used by qemu-pr-helper) may need to perform more complex recovery
operations to get reservations back to expected state if a path failure
happened in the middle of a PR operation. In this case, the device is
suspended for a longer time compared to the case we originally expected.
This patch changes hdev_co_ioctl() to treat -EAGAIN separately so that
it doesn't result in an immediate failure if the device is suspended for
more than 1ms, and moves to incremental backoff to cover both quick and
slow cases without excessive delays.
Buglink: https://issues.redhat.com/browse/RHEL-121543
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20251128221440.89125-1-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
If we fail to read an incoming request, recycle the message.
Resolves: Coverity CID 1611807
Resolves: Coverity CID 1611808
Signed-off-by: John Levon <john.levon@nutanix.com>
Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Link: https://lore.kernel.org/qemu-devel/20251203100316.3604456-6-john.levon@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
This function was unnecessarily difficult to understand due to the
separate handling of request and reply messages. Use common code for
both where we can.
Signed-off-by: John Levon <john.levon@nutanix.com>
Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Link: https://lore.kernel.org/qemu-devel/20251203100316.3604456-5-john.levon@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
It can figure out if it's a reply by itself, rather than passing that
information in.
Signed-off-by: John Levon <john.levon@nutanix.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Link: https://lore.kernel.org/qemu-devel/20251203100316.3604456-2-john.levon@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
Refresh the protocol specification to the latest version implemented by
libvfio-user. All changes are backward compatible.
Note that QEMU client itself does not yet implement these extensions,
but as this is now the canonical specification, it needs to be kept up
to date.
Signed-off-by: John Levon <john.levon@nutanix.com>
Link: https://lore.kernel.org/qemu-devel/20251010102453.711072-1-john.levon@nutanix.com
Signed-off-by: Cédric Le Goater <clg@redhat.com>
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: a27dd2de68 (KVM: keep track of running ioctls)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251128152050.3417834-1-armbru@redhat.com>
Recent changes introduced build errors in the i386 HVF backend:
- ../accel/hvf/hvf-accel-ops.c:163:17: error: no member named 'guest_debug_enabled' in 'struct AccelCPUState'
163 | cpu->accel->guest_debug_enabled = false;
- ../accel/hvf/hvf-accel-ops.c:151:51
error: no member named 'unblock_ipi_mask' in 'struct AccelCPUState'
- ../target/i386/hvf/hvf.c:736:5
error: use of undeclared identifier 'rip'
- ../target/i386/hvf/hvf.c:737:5
error: use of undeclared identifier 'env'
This patch corrects the field usage and move identifier to correct
function ensuring successful compilation of the i386 HVF backend.
These issues were caused by:
Fixes: 2ad756383e (“accel/hvf: Restrict ARM-specific fields of AccelCPUState”)
Fixes: 2a21c92447 (“target/i386/hvf: Factor hvf_handle_vmexit() out”)
Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20251126094601.56403-1-phind.uet@gmail.com>
[PMD: Keep setting vcpu_dirty on AArch64]
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Message-Id: <20251128085854.53539-1-phind.uet@gmail.com>
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: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-id: 20251125164511.255550-1-peter.maydell@linaro.org
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 64678fc45d 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: qemu-stable@nongnu.org
Fixes: 64678fc45d ("target/arm: Fix BTI versus CF_PCREL")
Signed-off-by: Harald van Dijk <hdijk@accesssoftek.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: d2265ebb-84bc-41b7-a2d7-05dc9a5a2055@accesssoftek.com
[PMM: added note about 64678fc45d to commit message]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Few fixes in hw/; also including qtest and replay fixes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmkmI9YACgkQ4+MsLN6t
wN6sSg/9EsnXLpMCfW1HyvgI67Yxb397YCvAxacPqFA+Xm9q6xCo2jKcjBnVI61A
4DkSsYC7OE2wdRzzziiWaXEfydGKHa7rXNGdunYSY52XLk2oElhSS0ykPsUWeFS+
66+YzSgNgBKHIdDHSVRgoTPDOYW6LSLU+Zfbj40FfApnuRw8AFRB+qVQaXvCV8h/
W6fI4B2ce/0Rv8o0AJDWnN3HP6rZZ+l+eyhj9ODPusAC+OU4nowiJBCoCJa8GwDY
KiASI9+mA4jY2vcoCiXG4Bbg1VzOte2TKudZwTwvhqkmGh0S6VejqO/Pn6IKh3j0
H3YrXMDn6h4GrJ3gd3YTseeuEhApYnUP76MWuPy+MjMwp605rMCh/voVkzRvBdmn
xXzklO48hpk8cRD3W4kfvJIlrBZIrMSFG8Q4m6S9FXZkGUP9zm2bOCkRqMxfdEdI
H1/J/sJ5iPOIwd87yElSV16i9BZyalcWZDYkQLKgtroq1uPaGxUR46mlnhMFKeBP
68Xjh9ux6zOuFwb4FIqbEyyKTMVdGrkHuD267YHEKQo0X0frGjFfdRtrW3zJbMIw
vAFsQl2oPAKJ7DpEHae/CeD10piQRb/nTav9UdscaXoIUJdFJ+nPfHNwUkKW30Gw
SSmueD2qJcqwzVa36SRhYxwG5+EW2RsN1kL5wkHv3qhRaoEfKJ8=
=hq47
-----END PGP SIGNATURE-----
Merge tag 'hw-misc-20251125' of https://github.com/philmd/qemu into staging
Misc HW patches
Few fixes in hw/; also including qtest and replay fixes.
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAmkmI9YACgkQ4+MsLN6t
# wN6sSg/9EsnXLpMCfW1HyvgI67Yxb397YCvAxacPqFA+Xm9q6xCo2jKcjBnVI61A
# 4DkSsYC7OE2wdRzzziiWaXEfydGKHa7rXNGdunYSY52XLk2oElhSS0ykPsUWeFS+
# 66+YzSgNgBKHIdDHSVRgoTPDOYW6LSLU+Zfbj40FfApnuRw8AFRB+qVQaXvCV8h/
# W6fI4B2ce/0Rv8o0AJDWnN3HP6rZZ+l+eyhj9ODPusAC+OU4nowiJBCoCJa8GwDY
# KiASI9+mA4jY2vcoCiXG4Bbg1VzOte2TKudZwTwvhqkmGh0S6VejqO/Pn6IKh3j0
# H3YrXMDn6h4GrJ3gd3YTseeuEhApYnUP76MWuPy+MjMwp605rMCh/voVkzRvBdmn
# xXzklO48hpk8cRD3W4kfvJIlrBZIrMSFG8Q4m6S9FXZkGUP9zm2bOCkRqMxfdEdI
# H1/J/sJ5iPOIwd87yElSV16i9BZyalcWZDYkQLKgtroq1uPaGxUR46mlnhMFKeBP
# 68Xjh9ux6zOuFwb4FIqbEyyKTMVdGrkHuD267YHEKQo0X0frGjFfdRtrW3zJbMIw
# vAFsQl2oPAKJ7DpEHae/CeD10piQRb/nTav9UdscaXoIUJdFJ+nPfHNwUkKW30Gw
# SSmueD2qJcqwzVa36SRhYxwG5+EW2RsN1kL5wkHv3qhRaoEfKJ8=
# =hq47
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 25 Nov 2025 01:47:02 PM PST
# gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE
# gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.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: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE
* tag 'hw-misc-20251125' of https://github.com/philmd/qemu:
hw/aspeed/{xdma, rtc, sdhci}: Fix endianness to DEVICE_LITTLE_ENDIAN
hw/core/machine: Provide a description for aux-ram-share property
replay: Improve assert in replay_char_read_all_load()
hw/virtio: Use error_setg_file_open() for a better error message
hw/scsi: Use error_setg_file_open() for a better error message
hw/usb: Convert to qemu_create() for a better error message
docs/deprecated: Remove undeprecated SMP description
hw/pci: Make msix_init take a uint32_t for nentries
qtest: Allow and ignore blank lines in input
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
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 <clg@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251125142631.676689-1-clg@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
It was forgotten when being introduced in commit 91792807d1 ("machine:
aux-ram-share option").
Cc: qemu-stable@nongnu.org
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20251124191408.783473-1-peterx@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
In replay_char_read_all_load() we get a buffer and size from the
replay log. We know the size has to fit an int because of how we
write the log. However the way we assert this is wrong: we cast the
size_t from replay_get_array() to an int and then check that it is
non-negative. This misses cases where an over-large size is
truncated into a positive value by the cast.
Replace the assertion with checking that the size is in-range
before doing the cast.
Coverity complained about the possible overflow: CID 1643440.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251124173407.50124-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The error message changes from
vhost-vsock: failed to open vhost device: REASON
to
Could not open '/dev/vhost-vsock': REASON
I think the exact file name is more useful to know than the file's
purpose.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251121121438.1249498-8-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The error message changes from
vhost-scsi: open vhost char device failed: REASON
to
Could not open '/dev/vhost-scsi': REASON
I think the exact file name is more useful to know than the file's
purpose.
We could put back the "vhost-scsi: " prefix with error_prepend(). Not
worth the bother.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dave@treblig.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251121121438.1249498-7-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The error message changes from
open FILENAME failed
to
Could not create 'FILENAME': REASON
where REASON is the value of strerror(errno).
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251121121438.1249498-3-armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
"Unsupported 'parameter=1' SMP configuration" was proposed to be
deprecated in the commit 54c4ea8f3a ("hw/core/machine-smp: Deprecate
unsupported "parameter=1" SMP configurations").
But the related code was reverted later in the commit 9d7950edb0
("hw/core: allow parameter=1 for SMP topology on any machine").
Thus, this SMP behavior is still valid and is not actually deprecated.
Remove outdated document descriptions.
Reported-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20251121084416.1031466-1-zhao1.liu@intel.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
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 <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20251107131044.1321637-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Currently the code that reads the qtest protocol commands insists
that every input line has a command. If it receives a line with
nothing but whitespace it will trip an assertion in
qtest_process_command().
This is a little awkward for the case where we are feeding qtest a
set of bug-reproduction commands via standard input or a file,
because it means you need to be careful not to leave a blank line at
the start or the end when cutting and pasting the command sequence
from a bug report.
Change the code to allow and ignore blank lines in the input.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Fabiano Rosas <farosas@suse.de>
Message-ID: <20251106151959.1088095-1-peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
This qemu-iotests test case is based on the reproducer that Jean-Louis
Dupond <jean-louis@dupond.be> shared in
https://gitlab.com/qemu-project/qemu/-/issues/3127.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20251007141700.71891-4-stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Since commit 5634622bcb ("file-posix: allow BLKZEROOUT with -t
writeback"), qemu-img create errors out on a Linux loop block device
with a 4 KB sector size:
# dd if=/dev/zero of=blockfile bs=1M count=1024
# losetup --sector-size 4096 /dev/loop0 blockfile
# qemu-img create -f raw /dev/loop0 1G
Formatting '/dev/loop0', fmt=raw size=1073741824
qemu-img: /dev/loop0: Failed to clear the new image's first sector: Invalid argument
Use the pwrite_zeroes_alignment block limit to avoid misaligned
fallocate(2) or ioctl(BLKZEROOUT) in the block/file-posix.c block
driver.
Cc: qemu-stable@nongnu.org
Fixes: 5634622bcb ("file-posix: allow BLKZEROOUT with -t writeback")
Reported-by: Jean-Louis Dupond <jean-louis@dupond.be>
Buglink: https://gitlab.com/qemu-project/qemu/-/issues/3127
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20251007141700.71891-3-stefanha@redhat.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Linux block devices require write zeroes alignment whereas files do not.
It may come as a surprise that block devices opened in buffered I/O mode
require the alignment for write zeroes requests although normal
read/write requests do not.
Therefore it is necessary to populate the pwrite_zeroes_alignment field.
Cc: qemu-stable@nongnu.org
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20251007141700.71891-2-stefanha@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
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: qemu-stable@nongnu.org
Reported-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20251119172720.135424-1-kwolf@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Tested-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
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 <marcandre.lureau@redhat.com>
Signed-off-by: Alano Song <AlanoSong@163.com>
[ Marc-André - removed useless Error *err ]
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20251125131955.7024-1-AlanoSong@163.com>
Per the PCI spec 3.0, in section 6.2.5.1, "Address Maps":
A 32-bit register can be implemented to support a single
memory size that is a power of 2 from 16 bytes to 2 GB.
Add a check in nvme_init_pmr(), returning an error if the
PMR region size is too small; and update the QTest.
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Klaus Jensen <k.jensen@samsung.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Set the protection information format (pif) only in the formats that can
support the larger guard types, and update the current in-use format
information when the user changes it.
Signed-off-by: Keith Busch <kbusch@kernel.org>
[k.jensen: fix missing braces and wrong indentation]
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Coverity complains about a possible copy-paste error in the verification
of the namespace atomic parameters (CID 1642811). While the check is
correct, the code (and the intention) is unclear.
Fix this by reworking how the parameters are verified. Peter also
identified that the realize function was not correctly erroring out if
parameters were misconfigured, so fix that too.
Lastly, change the error messages to be more describing.
Coverity: CID 1642811
Fixes: bce51b8370 ("hw/nvme: add atomic boundary support")
Fixes: 3b41acc962 ("hw/nvme: enable ns atomic writes")
Reviewed-by: Jesper Wendel Devantier <foss@defmacro.it>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
'in' will be -1 when file->in is unset. Let's not try to close
invalid fd.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Coverity: CID 1630444
Fixes: 69620c091d "chardev: qemu_chr_open_fd(): add errp"
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20251014145029.949285-1-vsementsov@yandex-team.ru>
Since commit f626116f ("ui/vdagent: factor out clipboard peer
registration"), the QEMU clipboard serial is reset whenever the vdagent
chardev receives the guest caps. This triggers a CHR_EVENT_CLOSED which
is handled by virtio_serial_close() to notify the guest.
The "reconnection logic" is there to reset the agent when a
client (dbus, spice etc) reconnects, or the agent is restarted.
It is required to sync the clipboard serials and to prevent races or
loops due to clipboard managers on both ends (but this is not
implemented by windows vdagent).
The Unix agent has been reconnecting without resending caps, thus
working with this approach.
However, the Windows agent does not seem to have a way to handle
VIRTIO_CONSOLE_PORT_OPEN=0 event and do not receive further data...
Let's not trigger this disconnection/reset logic if the agent does not
support VD_AGENT_CAP_CLIPBOARD_GRAB_SERIAL.
Fixes: f626116f ("ui/vdagent: factor out clipboard peer registration")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reported-by: Lucas Kornicki <lucas.kornicki@nutanix.com>
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
Tested-by: Lucas Kornicki <lucas.kornicki@nutanix.com>
With the latest updates the last year has been made possible by:
Top changeset contributors by employer
Linaro 2959 (37.0%)
Red Hat 1919 (24.0%)
Intel 313 (3.9%)
(None) 308 (3.9%)
ASPEED Technology Inc. 231 (2.9%)
Loongson Technology 227 (2.8%)
IBM 192 (2.4%)
Oracle 187 (2.3%)
Nutanix 133 (1.7%)
Academics (various) 99 (1.2%)
Top lines changed by employer
Linaro 109812 (31.8%)
Red Hat 91050 (26.4%)
ASPEED Technology Inc. 11811 (3.4%)
Intel 10606 (3.1%)
IBM 10146 (2.9%)
(None) 8965 (2.6%)
Oracle 8574 (2.5%)
Loongson Technology 7614 (2.2%)
Nutanix 7404 (2.1%)
Microsoft 6927 (2.0%)
Employers with the most hackers (total 433)
Red Hat 54 (12.5%)
IBM 30 (6.9%)
Intel 17 (3.9%)
(None) 13 (3.0%)
AMD 13 (3.0%)
Google 11 (2.5%)
Rivos Inc 10 (2.3%)
Linaro 9 (2.1%)
Oracle 8 (1.8%)
Huawei 8 (1.8%)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmkkKsAACgkQ+9DbCVqe
KkRbcQgAhc2I0HQa9fqFnp8vAZPMEEp3FFuPf1Dhwl4SWP95uZe/giooFyUhoZjw
fmLu3V+Tza1oX9ymgHcbGu465jgIORotIG9c2jfTNStbWQWMLT+3fsS3+/9oNgry
TtTNrSR2RpcUvnOWbMCPm68FiekQEmm4lbzNjh5uuGb6IddFyP/gZatbdMw3KzaX
kYKnlV6Ul5wBjzfH68paRfC1ZcM0/iPy5EbK3FhPVozpA3fV729ZR535WnFHNjc9
Gk6+oN2o4KQnvgSBY00NNnKUMcvMnvg3LSgmd2YUWh3O5jfVBbzaebP06HgfjLI3
WwBdlAnhAQRFZqJhiH7mCVmJhuwigQ==
=OPEI
-----END PGP SIGNATURE-----
Merge tag 'pull-10.2-gitdm-241125-1' of https://gitlab.com/stsquad/qemu into staging
gitdm updates for 2025
With the latest updates the last year has been made possible by:
Top changeset contributors by employer
Linaro 2959 (37.0%)
Red Hat 1919 (24.0%)
Intel 313 (3.9%)
(None) 308 (3.9%)
ASPEED Technology Inc. 231 (2.9%)
Loongson Technology 227 (2.8%)
IBM 192 (2.4%)
Oracle 187 (2.3%)
Nutanix 133 (1.7%)
Academics (various) 99 (1.2%)
Top lines changed by employer
Linaro 109812 (31.8%)
Red Hat 91050 (26.4%)
ASPEED Technology Inc. 11811 (3.4%)
Intel 10606 (3.1%)
IBM 10146 (2.9%)
(None) 8965 (2.6%)
Oracle 8574 (2.5%)
Loongson Technology 7614 (2.2%)
Nutanix 7404 (2.1%)
Microsoft 6927 (2.0%)
Employers with the most hackers (total 433)
Red Hat 54 (12.5%)
IBM 30 (6.9%)
Intel 17 (3.9%)
(None) 13 (3.0%)
AMD 13 (3.0%)
Google 11 (2.5%)
Rivos Inc 10 (2.3%)
Linaro 9 (2.1%)
Oracle 8 (1.8%)
Huawei 8 (1.8%)
# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmkkKsAACgkQ+9DbCVqe
# KkRbcQgAhc2I0HQa9fqFnp8vAZPMEEp3FFuPf1Dhwl4SWP95uZe/giooFyUhoZjw
# fmLu3V+Tza1oX9ymgHcbGu465jgIORotIG9c2jfTNStbWQWMLT+3fsS3+/9oNgry
# TtTNrSR2RpcUvnOWbMCPm68FiekQEmm4lbzNjh5uuGb6IddFyP/gZatbdMw3KzaX
# kYKnlV6Ul5wBjzfH68paRfC1ZcM0/iPy5EbK3FhPVozpA3fV729ZR535WnFHNjc9
# Gk6+oN2o4KQnvgSBY00NNnKUMcvMnvg3LSgmd2YUWh3O5jfVBbzaebP06HgfjLI3
# WwBdlAnhAQRFZqJhiH7mCVmJhuwigQ==
# =OPEI
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 24 Nov 2025 01:52:00 AM PST
# 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.2-gitdm-241125-1' of https://gitlab.com/stsquad/qemu:
contrib/gitdm: add more individual contributors
contrib/gitdm: add mapping for Nutanix
contrib/gitdm: add mapping for Eviden
contrib/gitdm: add University of Tokyo to academic group
contrib/gitdm: add group-map for Microsoft
contrib/gitdm: add group-map for Huawei
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
