Branch: refs/heads/stable-9.1
Home: https://github.com/qemu/qemu
Commit: 9b381a2a15a4f450e4979ef9afcb0cf27a3016af
https://github.com/qemu/qemu/commit/9b381a2a15a4f450e4979ef9afcb0cf27a3016af
Author: Peter Maydell <[email protected]>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M hw/intc/openpic.c
Log Message:
-----------
hw/intc/openpic: Avoid taking address of out-of-bounds array index
The clang sanitizer complains about the code in the EOI handling
of openpic_cpu_write_internal():
UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 ./build/clang/qemu-system-ppc -M
mac99,graphics=off -display none -kernel day15/invaders.elf
../../hw/intc/openpic.c:1034:16: runtime error: index -1 out of bounds for type
'IRQSource[264]' (aka 'struct IRQSource[264]')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
../../hw/intc/openpic.c:1034:16 in
This is because we do
src = &opp->src[n_IRQ];
when n_IRQ may be -1. This is in practice harmless because if n_IRQ
is -1 then we don't do anything with the src pointer, but it is
undefined behaviour. (This has been present since this device
was first added to QEMU.)
Rearrange the code so we only do the array index when n_IRQ is not -1.
Cc: [email protected]
Fixes: e9df014c0b ("Implement embedded IRQ controller for PowerPC 6xx/740 & 75")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Mark Cave-Ayland <[email protected]>
Message-id: [email protected]
(cherry picked from commit 3bf7dcd47a3da0e86a9347ce5b2b5d5a1dcb5857)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9b52d9bacce4b188af7b65f933ab2e3a0715986d
https://github.com/qemu/qemu/commit/9b52d9bacce4b188af7b65f933ab2e3a0715986d
Author: Peter Maydell <[email protected]>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M include/qemu/bitmap.h
M include/qemu/bitops.h
Log Message:
-----------
bitops.h: Define bit operations on 'uint32_t' arrays
Currently bitops.h defines a set of operations that work on
arbitrary-length bit arrays. However (largely because they
originally came from the Linux kernel) the bit array storage is an
array of 'unsigned long'. This is OK for the kernel and even for
parts of QEMU where we don't really care about the underlying storage
format, but it is not good for devices, where we often want to expose
the storage to the guest and so need a type that is not
variably-sized between host OSes.
We already have a workaround for this in the GICv3 model:
arm_gicv3_common.h defines equivalents of the bit operations that
work on uint32_t. It turns out that we should also be using
something similar in hw/intc/loongarch_extioi.c, which currently
casts a pointer to a uint32_t array to 'unsigned long *' in
extio_setirq(), which is both undefined behaviour and not correct on
a big-endian host.
Define equivalents of the set_bit() function family which work
with a uint32_t array.
(Cc stable because we're about to provide a bugfix to
loongarch_extioi which will depend on this commit.)
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 3d7680fb18c7b17701730589d241a32e85f763a3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 73a5dffbe16d37fa1df2188a9add995023070c54
https://github.com/qemu/qemu/commit/73a5dffbe16d37fa1df2188a9add995023070c54
Author: Peter Maydell <[email protected]>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M hw/intc/loongarch_extioi.c
Log Message:
-----------
hw/intc/loongarch_extioi: Use set_bit32() and clear_bit32() for s->isr
In extioi_setirq() we try to operate on a bit array stored as an
array of uint32_t using the set_bit() and clear_bit() functions
by casting the pointer to 'unsigned long *'.
This has two problems:
* the alignment of 'uint32_t' is less than that of 'unsigned long'
so we pass an insufficiently aligned pointer, which is
undefined behaviour
* on big-endian hosts the 64-bit 'unsigned long' will have
its two halves the wrong way around, and we will produce
incorrect results
The undefined behaviour is shown by the clang undefined-behaviour
sanitizer when running the loongarch64-virt functional test:
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:5: runtime
error: store to misaligned address 0x555559745d9c for type 'unsigned long',
which requires 8 byte alignment
0x555559745d9c: note: pointer points here
ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
#0 0x555556fb81c4 in set_bit
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:9
#1 0x555556fb81c4 in extioi_setirq
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_extioi.c:65:9
#2 0x555556fb6e90 in pch_pic_irq_handler
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_pch_pic.c:75:5
#3 0x555556710265 in serial_ioport_write
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/char/serial.c
Fix these problems by using set_bit32() and clear_bit32(),
which work with bit arrays stored as an array of uint32_t.
Cc: [email protected]
Fixes: cbff2db1e92f8759 ("hw/intc: Add LoongArch extioi interrupt
controller(EIOINTC)")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Bibo Mao <[email protected]>
Message-id: [email protected]
(cherry picked from commit 335be5bc44aa6800a9e3ba5859ea3833cfe5a7bc)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6979e4f558e20bc51d44dfe49d501d21d3d17a30
https://github.com/qemu/qemu/commit/6979e4f558e20bc51d44dfe49d501d21d3d17a30
Author: Ilya Leoshkevich <[email protected]>
Date: 2024-11-24 (Sun, 24 Nov 2024)
Changed paths:
M linux-user/strace.c
M linux-user/syscall.c
M linux-user/syscall_defs.h
Log Message:
-----------
linux-user: Fix strace output for s390x mmap()
print_mmap() assumes that mmap() receives arguments via memory if
mmap2() is present. s390x (as opposed to s390) does not fit this
pattern: it does not have mmap2(), but mmap() still receives arguments
via memory.
Fix by sharing the detection logic between syscall.c and strace.c.
Cc: [email protected]
Fixes: d971040c2d16 ("linux-user: Fix strace output for old_mmap")
Suggested-by: Richard Henderson <[email protected]>
Signed-off-by: Ilya Leoshkevich <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit d95fd9838b540e69da9b07538ec8ad6ab9eab260)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: compensate for chris architecture removal by v9.1.0-282-gbff4b02ca1f4
"linux-user: Remove support for CRIS target")
Commit: 726cf014d876f2ad6eb4c90dd358177c934b9a45
https://github.com/qemu/qemu/commit/726cf014d876f2ad6eb4c90dd358177c934b9a45
Author: Akihiko Odaki <[email protected]>
Date: 2024-11-25 (Mon, 25 Nov 2024)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
virtio-net: Fix size check in dhclient workaround
work_around_broken_dhclient() accesses IP and UDP headers to detect
relevant packets and to calculate checksums, but it didn't check if
the packet has size sufficient to accommodate them, causing out-of-bound
access hazards. Fix this by correcting the size requirement.
Fixes: 1d41b0c1ec66 ("Work around dhclient brokenness")
Cc: [email protected]
Signed-off-by: Akihiko Odaki <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit a8575f7fb2f213e6690b23160b04271d47fdfaa8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7ba3544b36dad2f7017dac5293f832c8605750a5
https://github.com/qemu/qemu/commit/7ba3544b36dad2f7017dac5293f832c8605750a5
Author: Kevin Wolf <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M hw/core/qdev-properties-system.c
Log Message:
-----------
qdev: Fix set_pci_devfn() to visit option only once
pci_devfn properties accept either a string or an integer as input. To
implement this, set_pci_devfn() first tries to visit the option as a
string, and if that fails, it visits it as an integer instead. While the
QemuOpts visitor happens to accept this, it is invalid according to the
visitor interface. QObject input visitors run into an assertion failure
when this is done.
QObject input visitors are used with the JSON syntax version of -device
on the command line:
$ ./qemu-system-x86_64 -enable-kvm -M q35 -device
pcie-pci-bridge,id=pci.1,bus=pcie.0 -blockdev null-co,node-name=disk -device '{
"driver": "virtio-blk-pci", "drive": "disk", "id": "virtio-disk0", "bus":
"pci.1", "addr": 1 }'
qemu-system-x86_64: ../qapi/qobject-input-visitor.c:143: QObject
*qobject_input_try_get_object(QObjectInputVisitor *, const char *, _Bool):
Assertion `removed' failed.
The proper way to accept both strings and integers is using the
alternate mechanism, which tells us the type of the input before it's
visited. With this information, we can directly visit it as the right
type.
This fixes set_pci_devfn() by using the alternate mechanism.
Cc: [email protected]
Reported-by: Peter Maydell <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Acked-by: Paolo Bonzini <[email protected]>
Reviewed-by: Markus Armbruster <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 5102f9df4a9a7adfbd902f9515c3f8f53dba288e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7f5f61c76e09308e380f59bec050b31445eaa432
https://github.com/qemu/qemu/commit/7f5f61c76e09308e380f59bec050b31445eaa432
Author: Jakub Jelen <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M block/ssh.c
Log Message:
-----------
ssh: Do not switch session to non-blocking mode
The libssh does not handle non-blocking mode in SFTP correctly. The
driver code already changes the mode to blocking for the SFTP
initialization, but for some reason changes to non-blocking mode.
This used to work accidentally until libssh in 0.11 branch merged
the patch to avoid infinite looping in case of network errors:
https://gitlab.com/libssh/libssh-mirror/-/merge_requests/498
Since then, the ssh driver in qemu fails to read files over SFTP
as the first SFTP messages exchanged after switching the session
to non-blocking mode return SSH_AGAIN, but that message is lost
int the SFTP internals and interpretted as SSH_ERROR, which is
returned to the caller:
https://gitlab.com/libssh/libssh-mirror/-/issues/280
This is indeed an issue in libssh that we should address in the
long term, but it will require more work on the internals. For
now, the SFTP is not supported in non-blocking mode.
Fixes: https://gitlab.com/libssh/libssh-mirror/-/issues/280
Signed-off-by: Jakub Jelen <[email protected]>
Signed-off-by: Richard W.M. Jones <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit fbdea3d6c13d5a75895c287a004c6f1a6bf6c164)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 916cb32dbfe4b1447eb4e2cd1210e0d0c2ecc290
https://github.com/qemu/qemu/commit/916cb32dbfe4b1447eb4e2cd1210e0d0c2ecc290
Author: Pierrick Bouvier <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M include/qemu/qemu-plugin.h
Log Message:
-----------
plugins: add missing export for qemu_plugin_num_vcpus
Fixes: 4a448b148ca ("plugins: add qemu_plugin_num_vcpus function")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Pierrick Bouvier <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit cfa3a6c54511374e9ccee26d9c38ac1698fc7af2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d1600147e385d6271622bf11b54539d9cb580fd4
https://github.com/qemu/qemu/commit/d1600147e385d6271622bf11b54539d9cb580fd4
Author: Peter Xu <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M migration/fd.c
Log Message:
-----------
migration: Allow pipes to keep working for fd migrations
Libvirt may still use pipes for old file migrations in fd: URI form,
especially when loading old images dumped from Libvirt's compression
algorithms.
In that case, Libvirt needs to compress / uncompress the images on its own
over the migration binary stream, and pipes are passed over to QEMU for
outgoing / incoming migrations in "fd:" URIs.
For future such use case, it should be suggested to use mapped-ram when
saving such VM image. However there can still be old images that was
compressed in such way, so libvirt needs to be able to load those images,
uncompress them and use the same pipe mechanism to pass that over to QEMU.
It means, even if new file migrations can be gradually moved over to
mapped-ram (after Libvirt start supporting it), Libvirt still needs the
uncompressor for the old images to be able to load like before.
Meanwhile since Libvirt currently exposes the compression capability to
guest images, it may needs its own lifecycle management to move that over
to mapped-ram, maybe can be done after mapped-ram saved the image, however
Dan and PeterK raised concern on temporary double disk space consumption.
I suppose for now the easiest is to enable pipes for both sides of "fd:"
migrations, until all things figured out from Libvirt side on how to move
on.
And for "channels" QMP interface support on "migrate" / "migrate-incoming"
commands, we'll also need to move away from pipe. But let's leave that for
later too.
So far, still allow pipes to happen like before on both save/load sides,
just like we would allow sockets to pass.
Cc: qemu-stable <[email protected]>
Cc: Fabiano Rosas <[email protected]>
Cc: Peter Krempa <[email protected]>
Cc: Daniel P. Berrangé <[email protected]>
Fixes: c55deb860c ("migration: Deprecate fd: for file migration")
Reviewed-by: Fabiano Rosas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 87ae45e602e2943d58509e470e3a1d4ba084ab2f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a40689e7b5f702c544128b317ef50c5209831d8b
https://github.com/qemu/qemu/commit/a40689e7b5f702c544128b317ef50c5209831d8b
Author: Akihiko Odaki <[email protected]>
Date: 2024-11-26 (Tue, 26 Nov 2024)
Changed paths:
M hw/net/virtio-net.c
M hw/virtio/virtio.c
M include/hw/virtio/virtio.h
Log Message:
-----------
virtio-net: Add queues before loading them
Call virtio_net_set_multiqueue() to add queues before loading their
states. Otherwise the loaded queues will not have handlers and elements
in them will not be processed.
Cc: [email protected]
Fixes: 8c49756825da ("virtio-net: Add only one queue pair when realizing")
Reported-by: Laurent Vivier <[email protected]>
Signed-off-by: Akihiko Odaki <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 9379ea9db3c0064fa2787db0794a23a30f7b2d2d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d6f305515ac55eb8dc585283665e46d431e4b667
https://github.com/qemu/qemu/commit/d6f305515ac55eb8dc585283665e46d431e4b667
Author: Harsh Prateek Bora <[email protected]>
Date: 2024-11-28 (Thu, 28 Nov 2024)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
ppc/spapr: fix drc index mismatch for partially enabled vcpus
In case when vcpus are explicitly enabled/disabled in a non-consecutive
order within a libvirt xml, it results in a drc index mismatch during
vcpu hotplug later because the existing logic uses vcpu id to derive the
corresponding drc index which is not correct. Use env->core_index to
derive a vcpu's drc index as appropriate to fix this issue.
For ex, for the given libvirt xml config:
<vcpus>
<vcpu id='0' enabled='yes' hotpluggable='no'/>
<vcpu id='1' enabled='yes' hotpluggable='yes'/>
<vcpu id='2' enabled='no' hotpluggable='yes'/>
<vcpu id='3' enabled='yes' hotpluggable='yes'/>
<vcpu id='4' enabled='no' hotpluggable='yes'/>
<vcpu id='5' enabled='yes' hotpluggable='yes'/>
<vcpu id='6' enabled='no' hotpluggable='yes'/>
<vcpu id='7' enabled='no' hotpluggable='yes'/>
</vcpus>
We see below error on guest console with "virsh setvcpus <domain> 5" :
pseries-hotplug-cpu: CPU with drc index 10000002 already exists
This patch fixes the issue by using correct drc index for explicitly
enabled vcpus during init.
Reported-by: Anushree Mathur <[email protected]>
Tested-by: Anushree Mathur <[email protected]>
Signed-off-by: Harsh Prateek Bora <[email protected]>
Reviewed-by: Nicholas Piggin <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit e8185fdc63e1db1efba695aae568fae8a075a815)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 18055fe359a2ecb962e0e64504e1222f20c01f64
https://github.com/qemu/qemu/commit/18055fe359a2ecb962e0e64504e1222f20c01f64
Author: Guenter Roeck <[email protected]>
Date: 2024-11-30 (Sat, 30 Nov 2024)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
scsi: megasas: Internal cdbs have 16-byte length
Host drivers do not necessarily set cdb_len in megasas io commands.
With commits 6d1511cea0 ("scsi: Reject commands if the CDB length
exceeds buf_len") and fe9d8927e2 ("scsi: Add buf_len parameter to
scsi_req_new()"), this results in failures to boot Linux from affected
SCSI drives because cdb_len is set to 0 by the host driver.
Set the cdb length to its actual size to solve the problem.
Signed-off-by: Guenter Roeck <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Tested-by: Fiona Ebner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 3abb67323aeecf06a27191076ab50424ec21f334)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: dba92fd3eaad48d39645addb9d342d0208525b3a
https://github.com/qemu/qemu/commit/dba92fd3eaad48d39645addb9d342d0208525b3a
Author: Christian Schoenebeck <[email protected]>
Date: 2024-11-30 (Sat, 30 Nov 2024)
Changed paths:
M tests/qtest/libqos/virtio-9p-client.c
Log Message:
-----------
tests/9p: fix Rreaddir response name
All 9p response types are prefixed with an "R", therefore fix
"READDIR" -> "RREADDIR" in function rmessage_name().
Fixes: 4829469fd9ff ("tests/virtio-9p: added readdir test")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<daad7af58b403aaa2487c566032beca36664b30e.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit abf0f092c1dd33b9ffa986c6924addc0a9c1d0b8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0d36c2cb62f5c64c380e38b443758914547862d4
https://github.com/qemu/qemu/commit/0d36c2cb62f5c64c380e38b443758914547862d4
Author: Christian Schoenebeck <[email protected]>
Date: 2024-11-30 (Sat, 30 Nov 2024)
Changed paths:
M tests/qtest/libqos/virtio-9p-client.c
Log Message:
-----------
tests/9p: add missing Rgetattr response name
'Tgetattr' 9p request and its 'Rgetattr' response types are already used
by test client, however this response type is yet missing in function
rmessage_name(), so add it.
Fixes: a6821b828404 ("tests/9pfs: compare QIDs in fs_walk_none() test")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<e183da80d390cfd7d55bdbce92f0ff6e3e5cdced.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit 4ec984965079b51a9afce339af75edea6de973a2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 74e160400ca5caf6be9a9e553904775e4eb5aaef
https://github.com/qemu/qemu/commit/74e160400ca5caf6be9a9e553904775e4eb5aaef
Author: Christian Schoenebeck <[email protected]>
Date: 2024-11-30 (Sat, 30 Nov 2024)
Changed paths:
M tests/qtest/virtio-9p-test.c
Log Message:
-----------
tests/9p: add 'use-after-unlink' test
After removing a file from the file system, we should still be able to
work with the file if we already had it open before removal.
As a first step we verify that it is possible to write to an unlinked
file, as this is what already works. This test is extended later on
after having fixed other use cases after unlink that are not working
yet.
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<3d6449d4df25bcdd3e807eff169f46f1385e5257.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit 462db8fb1d405391b83a0d3099fdb9bfb85c2d92)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: pick it to stable so the next commit in this place applies too)
Commit: 4dbe8c865cb9b80a8eda9e1e77b815a45ada6edf
https://github.com/qemu/qemu/commit/4dbe8c865cb9b80a8eda9e1e77b815a45ada6edf
Author: Christian Schoenebeck <[email protected]>
Date: 2024-11-30 (Sat, 30 Nov 2024)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
9pfs: remove obsolete comment in v9fs_getattr()
The comment claims that we'd only support basic Tgetattr fields. This is
no longer true, so remove this comment.
Fixes: e06a765efbe3 ("hw/9pfs: Add st_gen support in getattr reply")
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<fb364d12045217a4c6ccd0dd6368103ddb80698b.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit 3bc4db44430f53387d17145bb52b330a830a03fe)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: pick it for stable so the next commit applies cleanly)
Commit: 313f59d69288569c03881558bd915ca31c14573c
https://github.com/qemu/qemu/commit/313f59d69288569c03881558bd915ca31c14573c
Author: Christian Schoenebeck <[email protected]>
Date: 2024-11-30 (Sat, 30 Nov 2024)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
9pfs: fix 'Tgetattr' after unlink
With a valid file ID (FID) of an open file, it should be possible to send
a 'Tgettattr' 9p request and successfully receive a 'Rgetattr' response,
even if the file has been removed in the meantime. Currently this would
fail with ENOENT.
I.e. this fixes the following misbehaviour with a 9p Linux client:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename") = 0
fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory)
Expected results:
open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("/home/tst/filename") = 0
fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
This is because 9p server is always using a path name based lstat() call
which fails as soon as the file got removed. So to fix this, use fstat()
whenever we have an open file descriptor already.
Fixes: 00ede4c2529b ("virtio-9p: getattr server implementation...")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/103
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<4c41ad47f449a5cc8bfa9285743e029080d5f324.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit c81e7219e0736f80bfd3553676a19e2992cff41d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2bc5c92625454be025f85896f233c62ebb07efdb
https://github.com/qemu/qemu/commit/2bc5c92625454be025f85896f233c62ebb07efdb
Author: Christian Schoenebeck <[email protected]>
Date: 2024-11-30 (Sat, 30 Nov 2024)
Changed paths:
M tests/qtest/virtio-9p-test.c
Log Message:
-----------
tests/9p: also check 'Tgetattr' in 'use-after-unlink' test
This verifies expected behaviour of previous bug fix patch.
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id:
<7017658155c517b9665b75333a97c79aa2d4f3df.1732465720.git.qemu_...@crudebyte.com>
(cherry picked from commit eaab44ccc59b83d8dff60fca3361a9b98ec7fee6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2b2df86088203a7203fe0c3f4f2d292913804bc4
https://github.com/qemu/qemu/commit/2b2df86088203a7203fe0c3f4f2d292913804bc4
Author: Nicholas Piggin <[email protected]>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M target/ppc/excp_helper.c
Log Message:
-----------
target/ppc: Fix non-maskable interrupt while halted
The ppc (pnv and spapr) NMI injection code does not go through the
asynchronous interrupt path and set a bit in env->pending_interrupts
and raise an interrupt request that the cpu_exec() loop can see.
Instead it injects the exception directly into registers.
This can lead to cpu_exec() missing that the thread has work to do,
if a NMI is injected while it was idle.
Fix this by clearing halted when injecting the interrupt. Probably
NMI injection should be reworked to use the interrupt request interface,
but this seems to work as a minimal fix.
Fixes: 3431648272d3 ("spapr: Add support for new NMI interface")
Reviewed-by: Glenn Miles <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit fa416ae6157a933ad3f7106090684759baaaf3c9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2e19aaa96e03753b39fe2eb98684f52b52c7cce0
https://github.com/qemu/qemu/commit/2e19aaa96e03753b39fe2eb98684f52b52c7cce0
Author: Glenn Miles <[email protected]>
Date: 2024-12-02 (Mon, 02 Dec 2024)
Changed paths:
M hw/ppc/pnv_core.c
M hw/ppc/spapr_cpu_core.c
M target/ppc/cpu.h
Log Message:
-----------
target/ppc: Fix THREAD_SIBLING_FOREACH for multi-socket
The THREAD_SIBLING_FOREACH macro wasn't excluding threads from other
chips. Add chip_index field to the thread state and add a check for the
new field in the macro.
Fixes: b769d4c8f4c6 ("target/ppc: Add initial flags and helpers for SMT
support")
Signed-off-by: Glenn Miles <[email protected]>
[npiggin: set chip_index for spapr too]
Reviewed-by: Nicholas Piggin <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 2fc0a78a57731fda50d5b01e16fd68681900f709)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2745a72656e14e771d907fa5342e3e1cefc434a6
https://github.com/qemu/qemu/commit/2745a72656e14e771d907fa5342e3e1cefc434a6
Author: Klaus Jensen <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: fix msix_uninit with exclusive bar
Commit fa905f65c554 introduced a machine compatibility parameter to
enable an exclusive bar for msix. It failed to account for this when
cleaning up. Make sure that if an exclusive bar is enabled, we use the
proper cleanup routine.
Cc: [email protected]
Fixes: fa905f65c554 ("hw/nvme: add machine compatibility parameter to enable
msix exclusive bar")
Reviewed-by: Jesper Wendel Devantier <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>
(cherry picked from commit 9162f101257639cc4c7e20f72f77268b1256dd79)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 291a00967d9731654b841f0a32c86b02beb41fbb
https://github.com/qemu/qemu/commit/291a00967d9731654b841f0a32c86b02beb41fbb
Author: Klaus Jensen <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: take a reference on the subsystem on vf realization
Make sure we grab a reference on the subsystem when a VF is realized.
Otherwise, the subsytem will be unrealized automatically when the VFs
are unregistered and unreffed.
This fixes a latent bug but was not exposed until commit 08f632848008
("pcie: Release references of virtual functions"). This was then fixed
(or rather, hidden) by commit c613ad25125b ("pcie_sriov: Do not manually
unrealize"), but that was then reverted (due to other issues) in commit
b0fdaee5d1ed, exposing the bug yet again.
Cc: [email protected]
Fixes: 08f632848008 ("pcie: Release references of virtual functions")
Reviewed-by: Jesper Wendel Devantier <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>
(cherry picked from commit 6651f8f2e5051f6750c2534ab3151339b3c476a2)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 107bc19e5d2c02769b7fe41f4f6768d0e837a29f
https://github.com/qemu/qemu/commit/107bc19e5d2c02769b7fe41f4f6768d0e837a29f
Author: Ahmad Fatoum <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M hw/openrisc/openrisc_sim.c
Log Message:
-----------
hw/openrisc/openrisc_sim: keep serial@90000000 as default
We used to only have a single UART on the platform and it was located at
address 0x90000000. When the number of UARTs was increased to 4, the
first UART remained at it's location, but instead of being the first one
to be registered, it became the last.
This caused QEMU to pick 0x90000300 as the default UART, which broke
software that hardcoded the address of 0x90000000 and expected it's
output to be visible when the user configured only a single console.
This caused regressions[1] in the barebox test suite when updating to a
newer QEMU. As there seems to be no good reason to register the UARTs in
inverse order, let's register them by ascending address, so existing
software can remain oblivious to the additional UART ports.
Changing the order of uart registration alone breaks Linux which
was choosing the UART at 0x90000300 as the default for ttyS0. To fix
Linux we fix three things in the device tree:
1. Define stdout-path only one time for the first registered UART
instead of incorrectly defining for each UART.
2. Change the UART alias name from 'uart0' to 'serial0' as almost all
Linux tty drivers look for an alias starting with "serial".
3. Add the UART nodes so they appear in the final DTB in the
order starting with the lowest address and working upwards.
In summary these changes mean that the QEMU default UART (serial_hd(0))
is now setup where:
* serial_hd(0) is the lowest-address UART
* serial_hd(0) is listed first in the DTB
* serial_hd(0) is the /chosen/stdout-path one
* the /aliases/serial0 alias points at serial_hd(0)
[1]:
https://lore.barebox.org/barebox/[email protected]/T/#m5da26e8a799033301489a938b5d5667b81cef6ad
Fixes: 777784bda468 ("hw/openrisc: support 4 serial ports in or1ksim")
Cc: [email protected]
Signed-off-by: Ahmad Fatoum <[email protected]>
[stafford: Change to serial0 alias and update change message, reverse
uart registration order]
Signed-off-by: Stafford Horne <[email protected]>
Reviewed-by: Peter Maydell <[email protected]>
(cherry picked from commit 26dcf2be7e153defa289d20317707af034aca692)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: daccb6cf672f230489b5c9ece1af3c2b0b423f8a
https://github.com/qemu/qemu/commit/daccb6cf672f230489b5c9ece1af3c2b0b423f8a
Author: Peter Maydell <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M target/riscv/cpu_helper.c
Log Message:
-----------
target/riscv: Avoid bad shift in riscv_cpu_do_interrupt()
In riscv_cpu_do_interrupt() we use the 'cause' value we got out of
cs->exception as a shift value. However this value can be larger
than 31, which means that "1 << cause" is undefined behaviour,
because we do the shift on an 'int' type.
This causes the undefined behaviour sanitizer to complain
on one of the check-tcg tests:
$ UBSAN_OPTIONS=print_stacktrace=1:abort_on_error=1:halt_on_error=1
./build/clang/qemu-system-riscv64 -M virt -semihosting -display none -device
loader,file=build/clang/tests/tcg/riscv64-softmmu/issue1060
../../target/riscv/cpu_helper.c:1805:38: runtime error: shift exponent 63 is
too large for 32-bit type 'int'
#0 0x55f2dc026703 in riscv_cpu_do_interrupt
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../target/riscv/cpu_helper.c:1805:38
#1 0x55f2dc3d170e in cpu_handle_exception
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../accel/tcg/cpu-exec.c:752:9
In this case cause is RISCV_EXCP_SEMIHOST, which is 0x3f.
Use 1ULL instead to ensure that the shift is in range.
Signed-off-by: Peter Maydell <[email protected]>
Fixes: 1697837ed9 ("target/riscv: Add M-mode virtual interrupt and IRQ
filtering support.")
Fixes: 40336d5b1d ("target/riscv: Add HS-mode virtual interrupt and IRQ
filtering support.")
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 5311599cdc48337f2f27b1b51a80d46d75b05ed0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9e1cacffdb3d460e9f95c5d1fdb4d14a5487a1be
https://github.com/qemu/qemu/commit/9e1cacffdb3d460e9f95c5d1fdb4d14a5487a1be
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-13 (Fri, 13 Dec 2024)
Changed paths:
M hw/9pfs/9p-util.h
Log Message:
-----------
9pfs: fix regression regarding CVE-2023-2861
The released fix for this CVE:
f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
caused a regression with security_model=passthrough. When handling a
'Tmknod' request there was a side effect that 'Tmknod' request could fail
as 9p server was trying to adjust permissions:
#6 close_if_special_file (fd=30) at ../hw/9pfs/9p-util.h:140
#7 openat_file (mode=<optimized out>, flags=2228224,
name=<optimized out>, dirfd=<optimized out>) at
../hw/9pfs/9p-util.h:181
#8 fchmodat_nofollow (dirfd=dirfd@entry=31,
name=name@entry=0x5555577ea6e0 "mysocket", mode=493) at
../hw/9pfs/9p-local.c:360
#9 local_set_cred_passthrough (credp=0x7ffbbc4ace10, name=0x5555577ea6e0
"mysocket", dirfd=31, fs_ctx=0x55555811f528) at
../hw/9pfs/9p-local.c:457
#10 local_mknod (fs_ctx=0x55555811f528, dir_path=<optimized out>,
name=0x5555577ea6e0 "mysocket", credp=0x7ffbbc4ace10) at
../hw/9pfs/9p-local.c:702
#11 v9fs_co_mknod (pdu=pdu@entry=0x555558121140,
fidp=fidp@entry=0x5555574c46c0, name=name@entry=0x7ffbbc4aced0,
uid=1000, gid=1000, dev=<optimized out>, mode=49645,
stbuf=0x7ffbbc4acef0) at ../hw/9pfs/cofs.c:205
#12 v9fs_mknod (opaque=0x555558121140) at ../hw/9pfs/9p.c:3711
That's because server was opening the special file to adjust permissions,
however it was using O_PATH and it would have not returned the file
descriptor to guest. So the call to close_if_special_file() on that branch
was incorrect.
Let's lift the restriction introduced by f6b0de53fb8 such that it would
allow to open special files on host if O_PATH flag is supplied, not only
for 9p server's own operations as described above, but also for any client
'Topen' request.
It is safe to allow opening special files with O_PATH on host, because
O_PATH only allows path based operations on the resulting file descriptor
and prevents I/O such as read() and write() on that file descriptor.
Fixes: f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2337
Reported-by: Dirk Herrendorfer <[email protected]>
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Tested-by: Dirk Herrendorfer <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit d06a9d843fb65351e0e4dc42ba0c404f01ea92b3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: edda3647371c66dcb2922840a684a426b788b983
https://github.com/qemu/qemu/commit/edda3647371c66dcb2922840a684a426b788b983
Author: Richard Henderson <[email protected]>
Date: 2024-12-13 (Fri, 13 Dec 2024)
Changed paths:
M accel/tcg/plugin-gen.c
M include/tcg/tcg-temp-internal.h
M tcg/tcg.c
Log Message:
-----------
tcg: Reset free_temps before tcg_optimize
When allocating new temps during tcg_optmize, do not re-use
any EBB temps that were used within the TB. We do not have
any idea what span of the TB in which the temp was live.
Introduce tcg_temp_ebb_reset_freed and use before tcg_optimize,
as well as replacing the equivalent in plugin_gen_inject and
tcg_func_start.
Cc: [email protected]
Fixes: fb04ab7ddd8 ("tcg/optimize: Lower TCG_COND_TST{EQ,NE} if unsupported")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2711
Reported-by: wannacu <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 04e006ab36a8565b92d4e21dd346367fbade7d74)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 86f0cfa0efd13eae38d78eee953f24017f5cdb89
https://github.com/qemu/qemu/commit/86f0cfa0efd13eae38d78eee953f24017f5cdb89
Author: Roman Artemev <[email protected]>
Date: 2024-12-13 (Fri, 13 Dec 2024)
Changed paths:
M tcg/riscv/tcg-target.c.inc
Log Message:
-----------
tcg/riscv: Fix StoreStore barrier generation
On RISC-V to StoreStore barrier corresponds
`fence w, w` not `fence r, r`
Cc: [email protected]
Fixes: efbea94c76b ("tcg/riscv: Add slowpath load and store instructions")
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Denis Tomashev <[email protected]>
Signed-off-by: Roman Artemev <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit b438362a142527b97b638b7f0f35ebe11911a8d5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c8269bdd6817a359e5a3f1e653a01010992ae7a7
https://github.com/qemu/qemu/commit/c8269bdd6817a359e5a3f1e653a01010992ae7a7
Author: Gerd Hoffmann <[email protected]>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
M hw/i386/x86-common.c
Log Message:
-----------
x86/loader: only patch linux kernels
If the binary loaded via -kernel is *not* a linux kernel (in which
case protocol == 0), do not patch the linux kernel header fields.
It's (a) pointless and (b) might break binaries by random patching
and (c) changes the binary hash which in turn breaks secure boot
verification.
Background: OVMF happily loads and runs not only linux kernels but
any efi binary via direct kernel boot.
Note: Breaking the secure boot verification is a problem for linux
kernels too, but fixed that is left for another day ...
Signed-off-by: Gerd Hoffmann <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 57e2cc9abf5da38f600354fe920ff20e719607b4)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1dadf0862897d1d56cb78513b83ca2fa77563b98
https://github.com/qemu/qemu/commit/1dadf0862897d1d56cb78513b83ca2fa77563b98
Author: Gerd Hoffmann <[email protected]>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
M roms/Makefile
Log Message:
-----------
roms: re-add edk2-basetools target
Needed to build ipxe nic roms.
Reported-by: Liu Jaloo <[email protected]>
Fixes: 22e11539e167 ("edk2: replace build scripts")
Signed-off-by: Gerd Hoffmann <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 0f5715e4b5706b31b3550d8e6b88871e029c7823)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f0e661a3401bfd378c94f9a9d0bd03928c9dbf78
https://github.com/qemu/qemu/commit/f0e661a3401bfd378c94f9a9d0bd03928c9dbf78
Author: Michael Tokarev <[email protected]>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
A pc-bios/descriptors/60-edk2-riscv64.json
M pc-bios/descriptors/meson.build
Log Message:
-----------
pc-bios: add missing riscv64 descriptor
Without descriptor libvirt cannot discover the EDK II binaries via
the qemu:///system connection.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Gerd Hoffmann <[email protected]>
(cherry picked from commit 74dc38d0c6c15fd57a5dee94125d13ac5b00491d)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: context fix in pc-bios/descriptors/meson.build due to missing
v9.1.0-337-gb883fb93db "roms: Support compile the efi bios for loongarch")
Commit: d15fb196e369fbfba06556314b59e4ef1aa06e01
https://github.com/qemu/qemu/commit/d15fb196e369fbfba06556314b59e4ef1aa06e01
Author: Peter Maydell <[email protected]>
Date: 2024-12-20 (Fri, 20 Dec 2024)
Changed paths:
M hw/intc/arm_gicv3_its.c
Log Message:
-----------
hw/intc/arm_gicv3_its: Zero initialize local DTEntry etc structs
In the GICv3 ITS model, we have a common coding pattern which has a
local C struct like "DTEntry dte", which is a C representation of an
in-guest-memory data structure, and we call a function such as
get_dte() to read guest memory and fill in the C struct. These
functions to read in the struct sometimes have cases where they will
leave early and not fill in the whole struct (for instance get_dte()
will set "dte->valid = false" and nothing else for the case where it
is passed an entry_addr implying that there is no L2 table entry for
the DTE). This then causes potential use of uninitialized memory
later, for instance when we call a trace event which prints all the
fields of the struct. Sufficiently advanced compilers may produce
-Wmaybe-uninitialized warnings about this, especially if LTO is
enabled.
Rather than trying to carefully separate out these trace events into
"only the 'valid' field is initialized" and "all fields can be
printed", zero-init all the structs when we define them. None of
these structs are large (the biggest is 24 bytes) and having
consistent behaviour is less likely to be buggy.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2718
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 9678b9c505725732353baefedb88b53c2eb8a184)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: bbdcf1dcc0171078def9ecba4f2a5607d40a9533
https://github.com/qemu/qemu/commit/bbdcf1dcc0171078def9ecba4f2a5607d40a9533
Author: Thomas Huth <[email protected]>
Date: 2024-12-20 (Fri, 20 Dec 2024)
Changed paths:
M meson.build
Log Message:
-----------
meson.build: Disallow libnfs v6 to fix the broken macOS build
The macOS builds in our CI (and possibly other very recent distros)
are currently broken since the update to libnfs version 6 there.
That version apparently comes with a big API breakage. v5.0.3 was
the final release of the old API (see the libnfs commit here:
https://github.com/sahlberg/libnfs/commit/4379837 ).
Disallow version 6.x for now to get the broken CI job working
again. Once somebody had enough time to adapt our code in
block/nfs.c, we can revert this change again.
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e2d98f257138b83b6a492d1da5847a7fe0930d10)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 76fc629fd9318798b8bddb11b5521c2df9a6e6d3
https://github.com/qemu/qemu/commit/76fc629fd9318798b8bddb11b5521c2df9a6e6d3
Author: Albert Esteve <[email protected]>
Date: 2024-12-20 (Fri, 20 Dec 2024)
Changed paths:
M hw/virtio/vhost-user.c
Log Message:
-----------
vhost-user: fix shared object return values
VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
in the spec that they return 0 for successful
operations, non-zero otherwise. However,
implementation relies on the return types
of the virtio-dmabuf library, with opposite
semantics (true if everything is correct,
false otherwise). Therefore, current
implementation violates the specification.
Revert the logic so that the implementation
of the vhost-user handling methods matches
the specification.
Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
Reviewed-by: Stefano Garzarella <[email protected]>
Signed-off-by: Albert Esteve <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit eea5aeef84e1b74f515b474d3a86377701f93750)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 56b415017c97559cd999960677942b35b07fed0f
https://github.com/qemu/qemu/commit/56b415017c97559cd999960677942b35b07fed0f
Author: Maciej S. Szmigiero <[email protected]>
Date: 2024-12-22 (Sun, 22 Dec 2024)
Changed paths:
M accel/kvm/kvm-all.c
M configs/targets/i386-softmmu.mak
M configs/targets/x86_64-softmmu.mak
M include/sysemu/kvm.h
M target/i386/kvm/kvm.c
Log Message:
-----------
target/i386: Reset TSCs of parked vCPUs too on VM reset
Since commit 5286c3662294 ("target/i386: properly reset TSC on reset")
QEMU writes the special value of "1" to each online vCPU TSC on VM reset
to reset it.
However parked vCPUs don't get that handling and due to that their TSCs
get desynchronized when the VM gets reset.
This in turn causes KVM to turn off PVCLOCK_TSC_STABLE_BIT in its exported
PV clock.
Note that KVM has no understanding of vCPU being currently parked.
Without PVCLOCK_TSC_STABLE_BIT the sched clock is marked unstable in
the guest's kvm_sched_clock_init().
This causes a performance regressions to show in some tests.
Fix this issue by writing the special value of "1" also to TSCs of parked
vCPUs on VM reset.
Reproducing the issue:
1) Boot a VM with "-smp 2,maxcpus=3" or similar
2) device_add
host-x86_64-cpu,id=vcpu,node-id=0,socket-id=0,core-id=2,thread-id=0
3) Wait a few seconds
4) device_del vcpu
5) Inside the VM run:
# echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable
Observe the sched_clock_stable() value is 1.
6) Reboot the VM
7) Once the VM boots once again run inside it:
# echo "t" >/proc/sysrq-trigger; dmesg | grep sched_clock_stable
Observe the sched_clock_stable() value is now 0.
Fixes: 5286c3662294 ("target/i386: properly reset TSC on reset")
Signed-off-by: Maciej S. Szmigiero <[email protected]>
Link:
https://lore.kernel.org/r/5a605a88e9a231386dc803c60f5fed9b48108139.1734014926.git.maciej.szmigi...@oracle.com
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 3f2a05b31ee9ce2ddb6c75a9bc3f5e7f7af9a76f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f5ee58666d66e5f4c62c56a48909e46ed66af63d
https://github.com/qemu/qemu/commit/f5ee58666d66e5f4c62c56a48909e46ed66af63d
Author: Yong-Xuan Wang <[email protected]>
Date: 2024-12-22 (Sun, 22 Dec 2024)
Changed paths:
M hw/intc/riscv_aplic.c
Log Message:
-----------
hw/intc/riscv_aplic: Fix APLIC in_clrip and clripnum write emulation
In the section "4.7 Precise effects on interrupt-pending bits"
of the RISC-V AIA specification defines that:
"If the source mode is Level1 or Level0 and the interrupt domain
is configured in MSI delivery mode (domaincfg.DM = 1):
The pending bit is cleared whenever the rectified input value is
low, when the interrupt is forwarded by MSI, or by a relevant
write to an in_clrip register or to clripnum."
Update the riscv_aplic_set_pending() to match the spec.
Fixes: bf31cf06eb ("hw/intc/riscv_aplic: Fix setipnum_le write emulation for
APLIC MSI-mode")
Signed-off-by: Yong-Xuan Wang <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 0d0141fadc9063e527865ee420b2baf34e306093)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0c5ce2f91c180d1f9d2c44c9bc7403473bdef0e1
https://github.com/qemu/qemu/commit/0c5ce2f91c180d1f9d2c44c9bc7403473bdef0e1
Author: David Hildenbrand <[email protected]>
Date: 2024-12-24 (Tue, 24 Dec 2024)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x/s390-virtio-ccw: don't crash on weird RAM sizes
KVM is not happy when starting a VM with weird RAM sizes:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION
failed, slot=0, start=0x0, size=0x244000: Invalid argument
kvm_set_phys_mem: error registering slot: Invalid argument
Aborted (core dumped)
Let's handle that in a better way by rejecting such weird RAM sizes
right from the start:
# qemu-system-s390x --enable-kvm --nographic -m 1234K
qemu-system-s390x: ram size must be multiples of 1 MiB
Message-ID: <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Eric Farman <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Acked-by: Janosch Frank <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
(cherry picked from commit 14e568ab4836347481af2e334009c385f456a734)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 97983a9cc222ff73e7ab1e9bc656700b937f4b4d
https://github.com/qemu/qemu/commit/97983a9cc222ff73e7ab1e9bc656700b937f4b4d
Author: Alex Bennée <[email protected]>
Date: 2024-12-28 (Sat, 28 Dec 2024)
Changed paths:
M configs/targets/aarch64_be-linux-user.mak
Log Message:
-----------
config/targets: update aarch64_be-linux-user gdb XML list
Attempting to run the binary asserts when it can't find the XML entry.
We can fix it so we don't although I suspect other stuff is broken.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2580
Reviewed-by: Pierrick Bouvier <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 591e848aca7af3b4d25af03ed5bd266c479054bf)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4610a7d0a5f1ce7ba69658296000c0226c1e8c74
https://github.com/qemu/qemu/commit/4610a7d0a5f1ce7ba69658296000c0226c1e8c74
Author: Bibo Mao <[email protected]>
Date: 2024-12-29 (Sun, 29 Dec 2024)
Changed paths:
M target/loongarch/tcg/insn_trans/trans_vec.c.inc
Log Message:
-----------
target/loongarch: Use actual operand size with vbsrl check
Hardcoded 32 bytes is used for vbsrl emulation check, there is
problem when options lsx=on,lasx=off is used for vbsrl.v instruction
in TCG mode. It injects LASX exception rather LSX exception.
Here actual operand size is used.
Cc: [email protected]
Fixes: df97f338076 ("target/loongarch: Implement xvreplve xvinsve0 xvpickve")
Signed-off-by: Bibo Mao <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit d41989e7548397b469ec9c7be4cee699321a317e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 82e06839c4aec1d5420f8d36922a41cc73927b69
https://github.com/qemu/qemu/commit/82e06839c4aec1d5420f8d36922a41cc73927b69
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2024-12-29 (Sun, 29 Dec 2024)
Changed paths:
M docs/about/removed-features.rst
Log Message:
-----------
docs: Correct release of TCG trace-events removal
TCG trace-events were deprecated before the v6.2 release,
and removed for v7.0.
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit b4859e8f33a7d9c793a60395f792c10190cb4f78)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e85081d81f5bbcd5d598adc7495445014936a928
https://github.com/qemu/qemu/commit/e85081d81f5bbcd5d598adc7495445014936a928
Author: Han Han <[email protected]>
Date: 2024-12-29 (Sun, 29 Dec 2024)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386/cpu: Fix notes for CPU models
Fixes: 644e3c5d812 ("missing vmx features for Skylake-Server and
Cascadelake-Server")
Signed-off-by: Han Han <[email protected]>
Reviewed-by: Chenyi Qiang <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 93dcc9390e5ad0696ae7e9b7b3a5b08c2d1b6de6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6b45ab51736833f1fe586879a46819e5cfbc4ae7
https://github.com/qemu/qemu/commit/6b45ab51736833f1fe586879a46819e5cfbc4ae7
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-13 (Mon, 13 Jan 2025)
Changed paths:
M scripts/analyze-migration.py
Log Message:
-----------
migration: Add more error handling to analyze-migration.py
The analyze-migration script was seen failing in s390x in misterious
ways. It seems we're reaching the VMSDFieldStruct constructor without
any fields, which would indicate an empty .subsection entry, a
VMSTATE_STRUCT with no fields or a vmsd with no fields. We don't have
any of those, at least not without the unmigratable flag set, so this
should never happen.
Add some debug statements so that we can see what's going on the next
time the issue happens.
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 86bee9e0c761a3d0e67c43b44001fd752f894cb0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: aacde7dfb7acf289a2a521e3754ab3d29806823f
https://github.com/qemu/qemu/commit/aacde7dfb7acf289a2a521e3754ab3d29806823f
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M migration/vmstate.c
Log Message:
-----------
migration: Remove unused argument in vmsd_desc_field_end
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 2aead53d39b828f8d9d0769ffa3579dadd64d846)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1e223152b64a57863a5480d8a7c2c832146022f2
https://github.com/qemu/qemu/commit/1e223152b64a57863a5480d8a7c2c832146022f2
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M scripts/analyze-migration.py
Log Message:
-----------
migration: Fix parsing of s390 stream
The parsing for the S390StorageAttributes section is currently leaving
an unconsumed token that is later interpreted by the generic code as
QEMU_VM_EOF, cutting the parsing short.
The migration will issue a STATTR_FLAG_DONE between iterations, which
the script consumes correctly, but there's a final STATTR_FLAG_EOS at
.save_complete that the script is ignoring. Since the EOS flag is a
u64 0x1ULL and the stream is big endian, on little endian hosts a byte
read from it will be 0x0, the same as QEMU_VM_EOF.
Fixes: 81c2c9dd5d ("tests/qtest/migration-test: Fix analyze-migration.py for
s390x")
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 69d1f784569fdb950f2923c3b6d00d7c1b71acc1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7d2122b94acfe26b05691c7d5fe2376ebf558d8d
https://github.com/qemu/qemu/commit/7d2122b94acfe26b05691c7d5fe2376ebf558d8d
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x: Fix CSS migration
Commit a55ae46683 ("s390: move css_migration_enabled from machine to
css.c") disabled CSS migration globally instead of doing it
per-instance.
CC: Paolo Bonzini <[email protected]>
CC: [email protected] #9.1
Fixes: a55ae46683 ("s390: move css_migration_enabled from machine to css.c")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2704
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit c76ee1f6255c3988a9447d363bb17072f1ec84e1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 575ed2e688dc434d13608140d80ae2b7d0da62c7
https://github.com/qemu/qemu/commit/575ed2e688dc434d13608140d80ae2b7d0da62c7
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M migration/vmstate-types.c
M scripts/analyze-migration.py
Log Message:
-----------
migration: Rename vmstate_info_nullptr
Rename vmstate_info_nullptr from "uint64_t" to "nullptr". This vmstate
actually reads and writes just a byte, so the proper name would be
uint8. However, since this is a marker for a NULL pointer, it's
convenient to have a more explicit name that can be identified by the
consumers of the JSON part of the stream.
Change the name to "nullptr" and add support for it in the
analyze-migration.py script. Arbitrarily use the name of the type as
the value of the field to avoid the script showing 0x30 or '0', which
could be confusing for readers.
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit f52965bf0eeee28e89933264f1a9dbdcdaa76a7e)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 15efc4a0ddaea3387b45525f4dabd100d5d82e0f
https://github.com/qemu/qemu/commit/15efc4a0ddaea3387b45525f4dabd100d5d82e0f
Author: Peter Xu <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M migration/vmstate.c
Log Message:
-----------
migration: Dump correct JSON format for nullptr replacement
QEMU plays a trick with null pointers inside an array of pointers in a VMSD
field. See 07d4e69147 ("migration/vmstate: fix array of ptr with
nullptrs") for more details on why. The idea makes sense in general, but
it may overlooked the JSON writer where it could write nothing in a
"struct" in the JSON hints section.
We hit some analyze-migration.py issues on s390 recently, showing that some
of the struct field contains nothing, like:
{"name": "css", "array_len": 256, "type": "struct", "struct": {}, "size": 1}
As described in details by Fabiano:
https://lore.kernel.org/r/[email protected]
It could be that we hit some null pointers there, and JSON was gone when
they're null pointers.
To fix it, instead of hacking around only at VMStateInfo level, do that
from VMStateField level, so that JSON writer can also be involved. In this
case, JSON writer will replace the pointer array (which used to be a
"struct") to be the real representation of the nullptr field.
Signed-off-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 9867c3a7ced12dd7519155c047eb2c0098a11c5f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 58e5249e5bc845658b070cd8c97f04a98d8bac77
https://github.com/qemu/qemu/commit/58e5249e5bc845658b070cd8c97f04a98d8bac77
Author: Fabiano Rosas <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M migration/vmstate.c
M scripts/analyze-migration.py
Log Message:
-----------
migration: Fix arrays of pointers in JSON writer
Currently, if an array of pointers contains a NULL pointer, that
pointer will be encoded as '0' in the stream. Since the JSON writer
doesn't define a "pointer" type, that '0' will now be an uint8, which
is different from the original type being pointed to, e.g. struct.
(we're further calling uint8 "nullptr", but that's irrelevant to the
issue)
That mixed-type array shouldn't be compressed, otherwise data is lost
as the code currently makes the whole array have the type of the first
element:
css = {NULL, NULL, ..., 0x5555568a7940, NULL};
{"name": "s390_css", "instance_id": 0, "vmsd_name": "s390_css",
"version": 1, "fields": [
...,
{"name": "css", "array_len": 256, "type": "nullptr", "size": 1},
...,
]}
In the above, the valid pointer at position 254 got lost among the
compressed array of nullptr.
While we could disable the array compression when a NULL pointer is
found, the JSON part of the stream still makes part of downtime, so we
should avoid writing unecessary bytes to it.
Keep the array compression in place, but if NULL and non-NULL pointers
are mixed break the array into several type-contiguous pieces :
css = {NULL, NULL, ..., 0x5555568a7940, NULL};
{"name": "s390_css", "instance_id": 0, "vmsd_name": "s390_css",
"version": 1, "fields": [
...,
{"name": "css", "array_len": 254, "type": "nullptr", "size": 1},
{"name": "css", "type": "struct", "struct": {"vmsd_name": "s390_css_img",
... }, "size": 768},
{"name": "css", "type": "nullptr", "size": 1},
...,
]}
Now each type-discontiguous region will become a new JSON entry. The
reader should interpret this as a concatenation of values, all part of
the same field.
Parsing the JSON with analyze-script.py now shows the proper data
being pointed to at the places where the pointer is valid and
"nullptr" where there's NULL:
"s390_css (14)": {
...
"css": [
"nullptr",
"nullptr",
...
"nullptr",
{
"chpids": [
{
"in_use": "0x00",
"type": "0x00",
"is_virtual": "0x00"
},
...
]
},
"nullptr",
}
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 35049eb0d2fc72bb8c563196ec75b4d6c13fce02)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b604a42faa14c26810880af553f0d95f4abbd1b6
https://github.com/qemu/qemu/commit/b604a42faa14c26810880af553f0d95f4abbd1b6
Author: Yuan Liu <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M migration/multifd.c
Log Message:
-----------
multifd: bugfix for migration using compression methods
When compression is enabled on the migration channel and
the pages processed are all zero pages, these pages will
not be sent and updated on the target side, resulting in
incorrect memory data on the source and target sides.
The root cause is that all compression methods call
multifd_send_prepare_common to determine whether to compress
dirty pages, but multifd_send_prepare_common does not update
the IOV of MultiFDPacket_t when all dirty pages are zero pages.
The solution is to always update the IOV of MultiFDPacket_t
regardless of whether the dirty pages are all zero pages.
Fixes: 303e6f54f9 ("migration/multifd: Implement zero page transmission on the
multifd thread.")
Cc: [email protected] #9.0+
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit cdc3970f8597ebdc1a4c2090cfb4d11e297329ed)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: in 9.1 this code is in migration/multifd.c, not in
migration/multifd-nocomp.c)
Commit: 49da21ed5a7146cc1507322f04a789bef6d4a7d6
https://github.com/qemu/qemu/commit/49da21ed5a7146cc1507322f04a789bef6d4a7d6
Author: Yuan Liu <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M migration/multifd-qpl.c
Log Message:
-----------
multifd: bugfix for incorrect migration data with QPL compression
When QPL compression is enabled on the migration channel and the same
dirty page changes from a normal page to a zero page in the iterative
memory copy, the dirty page will not be updated to a zero page again
on the target side, resulting in incorrect memory data on the source
and target sides.
The root cause is that the target side does not record the normal pages
to the receivedmap.
The solution is to add ramblock_recv_bitmap_set_offset in target side
to record the normal pages.
Signed-off-by: Yuan Liu <[email protected]>
Reviewed-by: Jason Zeng <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 2588a5f99b0c3493b4690e3ff01ed36f80e830cc)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 07893634cbb40fcd38c37f7d74c4e4cab429769c
https://github.com/qemu/qemu/commit/07893634cbb40fcd38c37f7d74c4e4cab429769c
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M tests/qtest/boot-serial-test.c
Log Message:
-----------
tests/qtest/boot-serial-test: Correct HPPA machine name
Commit 7df6f751176 ("hw/hppa: Split out machine creation")
renamed the 'hppa' machine as 'B160L', but forgot to update
the boot serial test, which ended being skipped.
Cc: [email protected]
Fixes: 7df6f751176 ("hw/hppa: Split out machine creation")
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit a87077316ed2f1c1c8ba8faf05feed9dbf0f2fee)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 34a2b679c552d3c14573f01e6a5ef3a1d021dd22
https://github.com/qemu/qemu/commit/34a2b679c552d3c14573f01e6a5ef3a1d021dd22
Author: Gabriel Barrantes <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M backends/cryptodev-vhost-user.c
Log Message:
-----------
backends/cryptodev-vhost-user: Fix local_error leaks
Do not propagate error to the upper, directly output the error
to avoid leaks.
Fixes: 2fda101de07 ("virtio-crypto: Support asynchronous mode")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2714
Signed-off-by: Gabriel Barrantes <[email protected]>
Reviewed-by: zhenwei pi <[email protected]>
Message-Id:
<dm8pr13mb50781054a4fdace6f4fb6469b3...@dm8pr13mb5078.namprd13.prod.outlook.com>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 78b0c15a563ac4be5afb0375602ca0a3adc6c442)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 98f7a50d4c86e4ef197e51b20da325b141c5e769
https://github.com/qemu/qemu/commit/98f7a50d4c86e4ef197e51b20da325b141c5e769
Author: Phil Dennis-Jordan <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M hw/usb/hcd-xhci-pci.c
Log Message:
-----------
hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec
QEMU would crash with a failed assertion if the XHCI controller
attempted to raise the interrupt on an interrupter corresponding
to a MSI vector with a higher index than the highest configured
for the device by the guest driver.
This behaviour is correct on the MSI/PCI side: per PCI 3.0 spec,
devices must ensure they do not send MSI notifications for
vectors beyond the range of those allocated by the system/driver
software. Unlike MSI-X, there is no generic way for handling
aliasing in the case of fewer allocated vectors than requested,
so the specifics are up to device implementors. (Section
6.8.3.4. "Sending Messages")
It turns out the XHCI spec (Implementation Note in section 4.17,
"Interrupters") requires that the host controller signal the MSI
vector with the number computed by taking the interrupter number
modulo the number of enabled MSI vectors.
This change introduces that modulo calculation, fixing the
failed assertion. This makes the device work correctly in MSI mode
with macOS's XHCI driver, which only allocates a single vector.
Signed-off-by: Phil Dennis-Jordan <[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 bb5b7fced6b5d3334ab20702fc846e47bb1fb731)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9e0ece41fca502bba9b0dafd8f6549c84f7faeab
https://github.com/qemu/qemu/commit/9e0ece41fca502bba9b0dafd8f6549c84f7faeab
Author: Sebastian Ott <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M hw/pci/pcie.c
Log Message:
-----------
pci: ensure valid link status bits for downstream ports
PCI hotplug for downstream endpoints on arm fails because Linux'
PCIe hotplug driver doesn't like the QEMU provided LNKSTA:
pcieport 0000:08:01.0: pciehp: Slot(2): Card present
pcieport 0000:08:01.0: pciehp: Slot(2): Link Up
pcieport 0000:08:01.0: pciehp: Slot(2): Cannot train link: status 0x2000
There's 2 cases where LNKSTA isn't setup properly:
* the downstream device has no express capability
* max link width of the bridge is 0
Move the sanity checks added via 88c869198aa63
("pci: Sanity test minimum downstream LNKSTA") outside of the
branch to make sure downstream ports always have a valid LNKSTA.
Signed-off-by: Sebastian Ott <[email protected]>
Tested-by: Zhenyu Zhang <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Alex Williamson <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 694632fd44987cc4618612a38ad151047524a590)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: d00c5d29edb965e678ba6cd54ffe41b3fe8422d2
https://github.com/qemu/qemu/commit/d00c5d29edb965e678ba6cd54ffe41b3fe8422d2
Author: Nicholas Piggin <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M hw/pci/msix.c
Log Message:
-----------
pci/msix: Fix msix pba read vector poll end calculation
The end vector calculation has a bug that results in polling fewer
than required vectors when reading at a non-zero offset in PBA memory.
Fixes: bbef882cc193 ("msi: add API to get notified about pending bit poll")
Signed-off-by: Nicholas Piggin <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 42e2a7a0ab23784e44fcb18369e06067abc89305)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a988265bb85f850aa3ebe09f94248576e4f3e380
https://github.com/qemu/qemu/commit/a988265bb85f850aa3ebe09f94248576e4f3e380
Author: Igor Mammedov <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests: acpi: whitelist expected blobs
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 1ad32644fe4c9fb25086be15a66dde1d55d3410f)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: remove q35/DSDT.acpihmat-generic-x which is not present in 9.1)
Commit: a4f807dfabf5affc9b7fe820a8d04d99dfefc2d5
https://github.com/qemu/qemu/commit/a4f807dfabf5affc9b7fe820a8d04d99dfefc2d5
Author: Igor Mammedov <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M hw/i386/acpi-build.c
Log Message:
-----------
pci: acpi: Windows 'PCI Label Id' bug workaround
Current versions of Windows call _DSM(func=7) regardless
of whether it is supported or not. It leads to NICs having bogus
'PCI Label Id = 0', where none should be set at all.
Also presence of 'PCI Label Id' triggers another Windows bug
on localized versions that leads to hangs. The later bug is fixed
in latest updates for 'Windows Server' but not in consumer
versions of Windows (and there is no plans to fix it
as far as I'm aware).
Given it's easy, implement Microsoft suggested workaround
(return invalid Package) so that affected Windows versions
could boot on QEMU.
This would effectvely remove bogus 'PCI Label Id's on NICs,
but MS teem confirmed that flipping 'PCI Label Id' should not
change 'Network Connection' ennumeration, so it should be safe
for QEMU to change _DSM without any compat code.
Smoke tested with WinXP and WS2022
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/774
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 0b053391985abcc40b16ac8fc4a7f6588d1d95c1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 30faa99558e4b12af174c5d35a96859ff1aa0232
https://github.com/qemu/qemu/commit/30faa99558e4b12af174c5d35a96859ff1aa0232
Author: Igor Mammedov <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M tests/data/acpi/x86/pc/DSDT
M tests/data/acpi/x86/pc/DSDT.acpierst
M tests/data/acpi/x86/pc/DSDT.acpihmat
M tests/data/acpi/x86/pc/DSDT.bridge
M tests/data/acpi/x86/pc/DSDT.cphp
M tests/data/acpi/x86/pc/DSDT.dimmpxm
M tests/data/acpi/x86/pc/DSDT.hpbridge
M tests/data/acpi/x86/pc/DSDT.ipmikcs
M tests/data/acpi/x86/pc/DSDT.memhp
M tests/data/acpi/x86/pc/DSDT.nohpet
M tests/data/acpi/x86/pc/DSDT.numamem
M tests/data/acpi/x86/pc/DSDT.roothp
M tests/data/acpi/x86/q35/DSDT
M tests/data/acpi/x86/q35/DSDT.acpierst
M tests/data/acpi/x86/q35/DSDT.acpihmat
M tests/data/acpi/x86/q35/DSDT.acpihmat-noinitiator
M tests/data/acpi/x86/q35/DSDT.applesmc
M tests/data/acpi/x86/q35/DSDT.bridge
M tests/data/acpi/x86/q35/DSDT.core-count
M tests/data/acpi/x86/q35/DSDT.core-count2
M tests/data/acpi/x86/q35/DSDT.cphp
M tests/data/acpi/x86/q35/DSDT.cxl
M tests/data/acpi/x86/q35/DSDT.dimmpxm
M tests/data/acpi/x86/q35/DSDT.ipmibt
M tests/data/acpi/x86/q35/DSDT.ipmismbus
M tests/data/acpi/x86/q35/DSDT.ivrs
M tests/data/acpi/x86/q35/DSDT.memhp
M tests/data/acpi/x86/q35/DSDT.mmio64
M tests/data/acpi/x86/q35/DSDT.multi-bridge
M tests/data/acpi/x86/q35/DSDT.nohpet
M tests/data/acpi/x86/q35/DSDT.numamem
M tests/data/acpi/x86/q35/DSDT.pvpanic-isa
M tests/data/acpi/x86/q35/DSDT.thread-count
M tests/data/acpi/x86/q35/DSDT.thread-count2
M tests/data/acpi/x86/q35/DSDT.tis.tpm12
M tests/data/acpi/x86/q35/DSDT.tis.tpm2
M tests/data/acpi/x86/q35/DSDT.type4-count
M tests/data/acpi/x86/q35/DSDT.viot
M tests/data/acpi/x86/q35/DSDT.xapic
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests: acpi: update expected blobs
_DSM function 7 AML should have followig change:
If ((Arg2 == 0x07))
{
- Local0 = Package (0x02)
- {
- Zero,
- ""
- }
Local2 = AIDX (DerefOf (Arg4 [Zero]), DerefOf (Arg4 [One]
))
- Local0 [Zero] = Local2
+ Local0 = Package (0x02) {}
+ If (!((Local2 == Zero) || (Local2 == 0xFFFFFFFF)))
+ {
+ Local0 [Zero] = Local2
+ Local0 [One] = ""
+ }
+
Return (Local0)
}
}
Signed-off-by: Igor Mammedov <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 9fb1c9a1bb26e111ee5fa5538070cd684de14c08)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: rebuild acpi tables for 9.1)
Commit: 7594c49b95453c085d4da3903e6ffb79bae07c50
https://github.com/qemu/qemu/commit/7594c49b95453c085d4da3903e6ffb79bae07c50
Author: Li Zhijian <[email protected]>
Date: 2025-01-18 (Sat, 18 Jan 2025)
Changed paths:
M hw/mem/cxl_type3.c
Log Message:
-----------
hw/cxl: Fix msix_notify: Assertion `vector < dev->msix_entries_nr`
This assertion always happens when we sanitize the CXL memory device.
$ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize
It is incorrect to register an MSIX number beyond the device's capability.
Increase the device's MSIX number to cover the mailbox msix number(9).
Fixes: 43efb0bfad2b ("hw/cxl/mbox: Wire up interrupts for background
completion")
Signed-off-by: Li Zhijian <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 1ce979e7269a34d19ea1a65808df014d8b2acbf6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 09537fbd34736f39b49bce805e04dc6f12d7ce89
https://github.com/qemu/qemu/commit/09537fbd34736f39b49bce805e04dc6f12d7ce89
Author: Peter Maydell <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: arm_reset_sve_state() should set FPSR, not FPCR
The pseudocode ResetSVEState() does:
FPSR = ZeroExtend(0x0800009f<31:0>, 64);
but QEMU's arm_reset_sve_state() called vfp_set_fpcr() by accident.
Before the advent of FEAT_AFP, this was only setting a collection of
RES0 bits, which vfp_set_fpsr() would then ignore, so the only effect
was that we didn't actually set the FPSR the way we are supposed to
do. Once FEAT_AFP is implemented, setting the bottom bits of FPSR
will change the floating point behaviour.
Call vfp_set_fpsr(), as we ought to.
(Note for stable backports: commit 7f2a01e7368f9 moved this function
from sme_helper.c to helper.c, but it had the same bug before the
move too.)
Cc: [email protected]
Fixes: f84734b87461 ("target/arm: Implement SMSTART, SMSTOP")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 1edc3d43f20df0d04f8d00b906ba19fed37512a5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3b0234c9503628f59384d08f7591474b98a7780d
https://github.com/qemu/qemu/commit/3b0234c9503628f59384d08f7591474b98a7780d
Author: Hongren Zheng <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M hw/usb/canokey.c
M hw/usb/canokey.h
Log Message:
-----------
hw/usb/canokey: Fix buffer overflow for OUT packet
When USBPacket in OUT direction has larger payload
than the ep_out_buffer (of size 512), a buffer overflow
would occur.
It could be fixed by limiting the size of usb_packet_copy
to be at most buffer size. Further optimization gets rid
of the ep_out_buffer and directly uses ep_out as the target
buffer.
This is reported by a security researcher who artificially
constructed an OUT packet of size 2047. The report has gone
through the QEMU security process, and as this device is for
testing purpose and no deployment of it in virtualization
environment is observed, it is triaged not to be a security bug.
Cc: [email protected]
Fixes: d7d34918551dc48 ("hw/usb: Add CanoKey Implementation")
Reported-by: Juan Jose Lopez Jaimez <[email protected]>
Signed-off-by: Hongren Zheng <[email protected]>
Message-id: Z4TfMOrZz6IQYl_h@Sun
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 664280abddcb3cacc9c6204706bb739fcc1316f7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 21406429cbea86dca58fdaf0e3f10cf3fab99397
https://github.com/qemu/qemu/commit/21406429cbea86dca58fdaf0e3f10cf3fab99397
Author: Steve Sistare <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M system/physmem.c
Log Message:
-----------
physmem: fix qemu_ram_alloc_from_fd size calculation
qemu_ram_alloc_from_fd allocates space if file_size == 0. If non-zero,
it uses the existing space and verifies it is large enough, but the
verification was broken when the offset parameter was introduced. As
a result, a file smaller than offset passes the verification and causes
errors later. Fix that, and update the error message to include offset.
Peter provides this concise reproducer:
$ touch ramfile
$ truncate -s 64M ramfile
$ ./qemu-system-x86_64 -object
memory-backend-file,mem-path=./ramfile,offset=128M,size=128M,id=mem1,prealloc=on
qemu-system-x86_64: qemu_prealloc_mem: preallocating memory failed: Bad
address
With the fix, the error message is:
qemu-system-x86_64: mem1 backing store size 0x4000000 is too small for 'size'
option 0x8000000 plus 'offset' option 0x8000000
Cc: [email protected]
Fixes: 4b870dc4d0c0 ("hostmem-file: add offset option")
Signed-off-by: Steve Sistare <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 719168fba7c3215cc996dcfd32a6e5e9c7b8eee0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 89cc037912c4802bde844420f8c4cc6db7ef61c9
https://github.com/qemu/qemu/commit/89cc037912c4802bde844420f8c4cc6db7ef61c9
Author: Ilya Leoshkevich <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M target/s390x/tcg/mem_helper.c
Log Message:
-----------
target/s390x: Fix MVC not always invalidating translation blocks
Node.js crashes in qemu-system-s390x with random SIGSEGVs / SIGILLs.
The v8 JIT used by Node.js can garbage collect and overwrite unused
code. Overwriting is performed by WritableJitAllocation::CopyCode(),
which ultimately calls memcpy(). For certain sizes, memcpy() uses the
MVC instruction.
QEMU implements MVC and other similar instructions using helpers. While
TCG store ops invalidate affected translation blocks automatically,
helpers must do this manually by calling probe_access_flags(). The MVC
helper does this using the access_prepare() -> access_prepare_nf() ->
s390_probe_access() -> probe_access_flags() call chain.
At the last step of this chain, the store size is replaced with 0. This
causes the probe_access_flags() -> notdirty_write() ->
tb_invalidate_phys_range_fast() chain to miss some translation blocks.
When this happens, QEMU executes a mix of old and new code. This
quickly leads to either a SIGSEGV or a SIGILL in case the old code
ends in the middle of a new instruction.
Fix by passing the true size.
Reported-by: Berthold Gunreben <[email protected]>
Cc: Sarah Kriesch <[email protected]>
Cc: [email protected]
Closes: https://bugzilla.opensuse.org/show_bug.cgi?id=1235709
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Fixes: e2faabee78ff ("accel/tcg: Forward probe size on to notdirty_write")
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e43ced8be18dda77c229ab09f85136a4d600d40d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 01d03bafcd0f6a66e1abb59696afd2fb3ee81d27
https://github.com/qemu/qemu/commit/01d03bafcd0f6a66e1abb59696afd2fb3ee81d27
Author: Laurent Vivier <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M net/net.c
Log Message:
-----------
net: Fix announce_self
b9ad513e1876 ("net: Remove receive_raw()") adds an iovec entry
in qemu_deliver_packet_iov() to add the virtio-net header
in the data when QEMU_NET_PACKET_FLAG_RAW is set but forgets
to increase the number of iovec entries in the array, so
receive_iov() will only send the first entry (the virtio-net
entry, full of 0) and no data. The packet will be discarded.
The only user of QEMU_NET_PACKET_FLAG_RAW is announce_self.
We can see the problem with tcpdump:
- QEMU parameters:
.. -monitor stdio \
-netdev bridge,id=netdev0,br=virbr0 \
-device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 \
- HMP command:
(qemu) announce_self
- TCP dump:
$ sudo tcpdump -nxi virbr0
without the fix:
<nothing>
with the fix:
ARP, Reverse Request who-is 9a:2b:2c:2d:2e:2f tell 9a:2b:2c:2d:2e:2f, length
46
0x0000: 0001 0800 0604 0003 9a2b 2c2d 2e2f 0000
0x0010: 0000 9a2b 2c2d 2e2f 0000 0000 0000 0000
0x0020: 0000 0000 0000 0000 0000 0000 0000
Reported-by: Xiaohui Li <[email protected]>
Bug: https://issues.redhat.com/browse/RHEL-73891
Fixes: b9ad513e1876 ("net: Remove receive_raw()")
Cc: [email protected]
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 84dfdcbff33fff185528501be408c25c44499f32)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4cbe76b9523d354b6594b9e77981a6c6815cdce8
https://github.com/qemu/qemu/commit/4cbe76b9523d354b6594b9e77981a6c6815cdce8
Author: Laurent Vivier <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M net/dump.c
Log Message:
-----------
net/dump: Correctly compute Ethernet packet offset
When a packet is sent with QEMU_NET_PACKET_FLAG_RAW by QEMU it
never includes virtio-net header even if qemu_get_vnet_hdr_len()
is not 0, and filter-dump is not managing this case.
The only user of QEMU_NET_PACKET_FLAG_RAW is announce_self,
we can show the problem using it and tcpddump:
- QEMU parameters:
.. -monitor stdio \
-netdev bridge,id=netdev0,br=virbr0 \
-device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 \
-object filter-dump,netdev=netdev0,file=log.pcap,id=pcap0
- HMP command:
(qemu) announce_self
- TCP dump:
$ tcpdump -nxr log.pcap
without the fix:
08:00:06:04:00:03 > 2e:2f:80:35:00:01, ethertype Unknown (0x9a2b), length
50:
0x0000: 2c2d 2e2f 0000 0000 9a2b 2c2d 2e2f 0000
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000
0x0020: 0000 0000
with the fix:
ARP, Reverse Request who-is 9a:2b:2c:2d:2e:2f tell 9a:2b:2c:2d:2e:2f,
length 46
0x0000: 0001 0800 0604 0003 9a2b 2c2d 2e2f 0000
0x0010: 0000 9a2b 2c2d 2e2f 0000 0000 0000 0000
0x0020: 0000 0000 0000 0000 0000 0000 0000
Fixes: 481c52320a26 ("net: Strip virtio-net header when dumping")
Cc: [email protected]
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit c6a1b591a68b4d7230d6c3f56965e18080d737e5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 104c686f46803f89140006f34d89df2995e32a60
https://github.com/qemu/qemu/commit/104c686f46803f89140006f34d89df2995e32a60
Author: Dominik 'Disconnect3d' Czarnota <[email protected]>
Date: 2025-02-01 (Sat, 01 Feb 2025)
Changed paths:
M gdbstub/user-target.c
Log Message:
-----------
gdbstub/user-target: fix gdbserver int format (%d -> %x)
This commit fixes an incorrect format string for formatting integers
provided to GDB when debugging a target run in QEMU user mode.
The correct format is hexadecimal for both success and errno values,
some of which can be seen here [0].
[0]
https://github.com/bminor/binutils-gdb/blob/e65a355022d0dc6b5707310876a72b5693ec0aa5/gdbserver/hostio.cc#L196-L213
Signed-off-by: Dominik 'Disconnect3d' Czarnota <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Fixes: e282010b2e1e ("gdbstub: Add support for info proc mappings")
Cc: [email protected]
Reviewed-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 8b647bd352505234cab2acd2422aba183a1aa1fd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 18e7fef77e1b1e146c5e61ce4324c78788408c6a
https://github.com/qemu/qemu/commit/18e7fef77e1b1e146c5e61ce4324c78788408c6a
Author: Michael Tokarev <[email protected]>
Date: 2025-02-08 (Sat, 08 Feb 2025)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 9.1.3 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/508081a49b0d...18e7fef77e1b
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
