Branch: refs/heads/stable-7.2
Home: https://github.com/qemu/qemu
Commit: fc4ca539d06f07848c2d31d4295045a291ae4c0e
https://github.com/qemu/qemu/commit/fc4ca539d06f07848c2d31d4295045a291ae4c0e
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: 4de86d2b3073f33c535a91fe6ab3de5f12abc407
https://github.com/qemu/qemu/commit/4de86d2b3073f33c535a91fe6ab3de5f12abc407
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: 02774b586149afe97527c8619fa741845ec12a06
https://github.com/qemu/qemu/commit/02774b586149afe97527c8619fa741845ec12a06
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]>
(Mjt: drop hunk in hw/intc/loongarch_extioi.c:extioi_update_sw_coremap()
due to missing v8.2.0-548-g428a6ef4396a "hw/intc/loongarch_extioi: Add vmstate
post_load support")
Commit: f33f326fbd41209fabaab2900fa23b95d2451184
https://github.com/qemu/qemu/commit/f33f326fbd41209fabaab2900fa23b95d2451184
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2024-11-25 (Mon, 25 Nov 2024)
Changed paths:
R .cirrus.yml
M MAINTAINERS
Log Message:
-----------
cirrus-ci: Remove MSYS2 jobs duplicated with gitlab-ci
- Various developers are reluctant to git Cirrus-CI the permissions
requested to access their GitHub account.
- When we use the cirrus-run script to trigger Cirrus-CI job from
GitLab-CI, the GitLab-CI job is restricted to a 1h timeout
(often not enough).
- Although Cirrus-CI VMs are more powerful than GitLab-CI ones,
its free plan is limited in 2 concurrent jobs.
- The GitLab-CI MSYS2 jobs are a 1:1 mapping with the Cirrus-CI ones
(modulo the environment caching).
Reduce the maintenance burden by removing the Cirrus-CI config file,
keeping the GitLab-CI jobs.
Update Yonggang Luo's maintenance file list to the new file, which
use the same environment shell.
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit da80f11efeea451eaa00e347f722d867ed9ac5be)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: ignore previous changes in .cirrus.yml since it is being removed anyway)
Commit: acb39d8e6e4a9b76d991d0be9d9d9a9e43644902
https://github.com/qemu/qemu/commit/acb39d8e6e4a9b76d991d0be9d9d9a9e43644902
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: ea1f958b4e54acbc26a25fd4b5d14daadda99f7d
https://github.com/qemu/qemu/commit/ea1f958b4e54acbc26a25fd4b5d14daadda99f7d
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: 686ece6ad46e98a98e13110e17c47c1fa5d3ac57
https://github.com/qemu/qemu/commit/686ece6ad46e98a98e13110e17c47c1fa5d3ac57
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: ef780ee7658297c4e2b85a63a00ea524bd81c014
https://github.com/qemu/qemu/commit/ef780ee7658297c4e2b85a63a00ea524bd81c014
Author: Guenter Roeck <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 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: 039fdd09b43bd245d852ad4c261827c20f7f99b7
https://github.com/qemu/qemu/commit/039fdd09b43bd245d852ad4c261827c20f7f99b7
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 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: 9e6f0a2334c3519316143370fc71ab34187cb980
https://github.com/qemu/qemu/commit/9e6f0a2334c3519316143370fc71ab34187cb980
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 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: 9229de86197b1986a69bf94aa256b08612e0aabd
https://github.com/qemu/qemu/commit/9229de86197b1986a69bf94aa256b08612e0aabd
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 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: context fix, pick it to stable so the next patch in this place applies)
Commit: 5f79bf8d627b0a4d9899be0a92ee9fdeab986710
https://github.com/qemu/qemu/commit/5f79bf8d627b0a4d9899be0a92ee9fdeab986710
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 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]>
Commit: 509bce38cb24778cb0480ad0822d813320b459f1
https://github.com/qemu/qemu/commit/509bce38cb24778cb0480ad0822d813320b459f1
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 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: 873d2616c630e6da40ab1efb73a6615b0c0b06dc
https://github.com/qemu/qemu/commit/873d2616c630e6da40ab1efb73a6615b0c0b06dc
Author: Christian Schoenebeck <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 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: 752dfc41e0d7690e079cd2a38e9b7dbb5ecd07f4
https://github.com/qemu/qemu/commit/752dfc41e0d7690e079cd2a38e9b7dbb5ecd07f4
Author: Nicholas Piggin <[email protected]>
Date: 2024-12-03 (Tue, 03 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: d0da52dbaa1f2171298bfe8d80ad5ba7715c3767
https://github.com/qemu/qemu/commit/d0da52dbaa1f2171298bfe8d80ad5ba7715c3767
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: a6e1da0f5b2418b91e6b5e332f5ca9c778f7cefc
https://github.com/qemu/qemu/commit/a6e1da0f5b2418b91e6b5e332f5ca9c778f7cefc
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: 2831b489f32dce8bc2190c56ac48c4c2ae67d5a6
https://github.com/qemu/qemu/commit/2831b489f32dce8bc2190c56ac48c4c2ae67d5a6
Author: Alexander Bulekov <[email protected]>
Date: 2024-12-16 (Mon, 16 Dec 2024)
Changed paths:
M tests/qtest/fuzz/generic_fuzz_configs.h
Log Message:
-----------
fuzz: specify audiodev for usb-audio
Fixes test-failure on Fedora 40 CI.
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Alexander Bulekov <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e7fca81e170530104c36bd8f3e1d7e7c11011481)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 708bb73093a202ca75d1b831517bf000e40015ee
https://github.com/qemu/qemu/commit/708bb73093a202ca75d1b831517bf000e40015ee
Author: Gerd Hoffmann <[email protected]>
Date: 2024-12-17 (Tue, 17 Dec 2024)
Changed paths:
M hw/i386/x86.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]>
(Mjt: it is in hw/i386/x86.c not hw/i386/x86-common.c in 7.2.x)
Commit: fd48613a0a44bad3a8a077ab1a10d352da72f458
https://github.com/qemu/qemu/commit/fd48613a0a44bad3a8a077ab1a10d352da72f458
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: 9fbebd5ea4c88ae4a0b60f24af6c53563d4396f9
https://github.com/qemu/qemu/commit/9fbebd5ea4c88ae4a0b60f24af6c53563d4396f9
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]>
(Mjt: context fixup)
Commit: b5d3dedfc387697ef570a4a04330a05c44adef78
https://github.com/qemu/qemu/commit/b5d3dedfc387697ef570a4a04330a05c44adef78
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: e2c4f6d292dc7a426da0db042e28706afb283ab5
https://github.com/qemu/qemu/commit/e2c4f6d292dc7a426da0db042e28706afb283ab5
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: 677b29c943779d7a9c70279d282d1b1388999de7
https://github.com/qemu/qemu/commit/677b29c943779d7a9c70279d282d1b1388999de7
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: 42422a98b2205341a0432db2db64579b79427225
https://github.com/qemu/qemu/commit/42422a98b2205341a0432db2db64579b79427225
Author: Gabriel Barrantes <[email protected]>
Date: 2025-01-17 (Fri, 17 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: e0c3f8f82f9fae8ce6234a70b4843b35c0328a45
https://github.com/qemu/qemu/commit/e0c3f8f82f9fae8ce6234a70b4843b35c0328a45
Author: Phil Dennis-Jordan <[email protected]>
Date: 2025-01-17 (Fri, 17 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: 6d1a80edaa1e5ea18cc770de56f34dc33448f4c4
https://github.com/qemu/qemu/commit/6d1a80edaa1e5ea18cc770de56f34dc33448f4c4
Author: Sebastian Ott <[email protected]>
Date: 2025-01-17 (Fri, 17 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: eddb763e3bbc68e7bb28226433b82efde551e97f
https://github.com/qemu/qemu/commit/eddb763e3bbc68e7bb28226433b82efde551e97f
Author: Nicholas Piggin <[email protected]>
Date: 2025-01-17 (Fri, 17 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: 7171f0164cf8c8d6a4eb62dbb47b2698329f36c4
https://github.com/qemu/qemu/commit/7171f0164cf8c8d6a4eb62dbb47b2698329f36c4
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 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: drop x86/ subdir and drop a few files not relevant for 7.2)
Commit: 89caa45bf3cf4ac161184806cf6d0399f267bc6d
https://github.com/qemu/qemu/commit/89caa45bf3cf4ac161184806cf6d0399f267bc6d
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 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: 19bee15f892ffab3a2dd0c4e0cd331292e0433d5
https://github.com/qemu/qemu/commit/19bee15f892ffab3a2dd0c4e0cd331292e0433d5
Author: Igor Mammedov <[email protected]>
Date: 2025-01-17 (Fri, 17 Jan 2025)
Changed paths:
M tests/data/acpi/pc/DSDT
M tests/data/acpi/pc/DSDT.acpierst
M tests/data/acpi/pc/DSDT.acpihmat
M tests/data/acpi/pc/DSDT.bridge
M tests/data/acpi/pc/DSDT.cphp
M tests/data/acpi/pc/DSDT.dimmpxm
M tests/data/acpi/pc/DSDT.hpbridge
M tests/data/acpi/pc/DSDT.ipmikcs
M tests/data/acpi/pc/DSDT.memhp
M tests/data/acpi/pc/DSDT.nohpet
M tests/data/acpi/pc/DSDT.numamem
M tests/data/acpi/pc/DSDT.roothp
M tests/data/acpi/q35/DSDT
M tests/data/acpi/q35/DSDT.acpierst
M tests/data/acpi/q35/DSDT.acpihmat
M tests/data/acpi/q35/DSDT.acpihmat-noinitiator
M tests/data/acpi/q35/DSDT.applesmc
M tests/data/acpi/q35/DSDT.bridge
M tests/data/acpi/q35/DSDT.core-count2
M tests/data/acpi/q35/DSDT.cphp
M tests/data/acpi/q35/DSDT.cxl
M tests/data/acpi/q35/DSDT.dimmpxm
M tests/data/acpi/q35/DSDT.ipmibt
M tests/data/acpi/q35/DSDT.ipmismbus
M tests/data/acpi/q35/DSDT.ivrs
M tests/data/acpi/q35/DSDT.memhp
M tests/data/acpi/q35/DSDT.mmio64
M tests/data/acpi/q35/DSDT.multi-bridge
M tests/data/acpi/q35/DSDT.nohpet
M tests/data/acpi/q35/DSDT.numamem
M tests/data/acpi/q35/DSDT.pvpanic-isa
M tests/data/acpi/q35/DSDT.tis.tpm12
M tests/data/acpi/q35/DSDT.tis.tpm2
M tests/data/acpi/q35/DSDT.viot
M tests/data/acpi/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]>
Commit: 3559e90146d87980a4ea554dd781cf81242bbe80
https://github.com/qemu/qemu/commit/3559e90146d87980a4ea554dd781cf81242bbe80
Author: Peter Maydell <[email protected]>
Date: 2025-01-29 (Wed, 29 Jan 2025)
Changed paths:
M target/arm/sme_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]>
(it is in sme_helper.c in 7.2, not in helper.c)
Commit: 026168232681037ad2168210ffcbf6f74d0e7365
https://github.com/qemu/qemu/commit/026168232681037ad2168210ffcbf6f74d0e7365
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: 044e1dd76bf5210f525f4b12b05d7261cce73937
https://github.com/qemu/qemu/commit/044e1dd76bf5210f525f4b12b05d7261cce73937
Author: Michael Tokarev <[email protected]>
Date: 2025-02-08 (Sat, 08 Feb 2025)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 7.2.16 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/8ac75726fc0b...044e1dd76bf5
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
