Branch: refs/heads/staging-8.2
Home: https://github.com/qemu/qemu
Commit: 59a2e1df5ffcc81f2d27069a0db8268ed4c061f9
https://github.com/qemu/qemu/commit/59a2e1df5ffcc81f2d27069a0db8268ed4c061f9
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: 322b690222a67d7809e70fa3ad336b959a102ea2
https://github.com/qemu/qemu/commit/322b690222a67d7809e70fa3ad336b959a102ea2
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: 981a9ddeb383369fb1e0e8c18b4ffdcca6db5847
https://github.com/qemu/qemu/commit/981a9ddeb383369fb1e0e8c18b4ffdcca6db5847
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: 16da961911b2402eb1c87695a9bd0498bf7b0d63
https://github.com/qemu/qemu/commit/16da961911b2402eb1c87695a9bd0498bf7b0d63
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: aac6bdec4cb37ac1f0c12d769589ab14c8a5bbad
https://github.com/qemu/qemu/commit/aac6bdec4cb37ac1f0c12d769589ab14c8a5bbad
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: 4935a39697c4906f5859a71e715f289e70cc550e
https://github.com/qemu/qemu/commit/4935a39697c4906f5859a71e715f289e70cc550e
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: 6d52a53e7bd886e7852a6be9694901a23752c88f
https://github.com/qemu/qemu/commit/6d52a53e7bd886e7852a6be9694901a23752c88f
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: d4a96c7e93b1307bbe7a5ce3c9f6f5f9a17be9d3
https://github.com/qemu/qemu/commit/d4a96c7e93b1307bbe7a5ce3c9f6f5f9a17be9d3
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: 481d671bfb42e4fdc7a00ca6838d09e3ea574045
https://github.com/qemu/qemu/commit/481d671bfb42e4fdc7a00ca6838d09e3ea574045
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: 5ad7009d843bd1d4e3283b7f86af4494931af470
https://github.com/qemu/qemu/commit/5ad7009d843bd1d4e3283b7f86af4494931af470
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: 48f582eec4ef42c7c6d6f5fda3ac08f4425b855d
https://github.com/qemu/qemu/commit/48f582eec4ef42c7c6d6f5fda3ac08f4425b855d
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: 8ba9c36f280e288fee9e1d9f96dd94c6085b375a
https://github.com/qemu/qemu/commit/8ba9c36f280e288fee9e1d9f96dd94c6085b375a
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: context fix, pick it to stable so the next patch in this place applies)
Commit: 321d19fb057ee2a41945767eb5bba5d8101ef9b2
https://github.com/qemu/qemu/commit/321d19fb057ee2a41945767eb5bba5d8101ef9b2
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 to stable so the next commit applies cleanly)
Commit: 37adcdb95c4e79d7e279d236f1de6a610994471d
https://github.com/qemu/qemu/commit/37adcdb95c4e79d7e279d236f1de6a610994471d
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: 3cab43e6f635987710ab09e5e6f7af655967a408
https://github.com/qemu/qemu/commit/3cab43e6f635987710ab09e5e6f7af655967a408
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: 085ce73103c8e2450e72281bd792dfc39ff963d0
https://github.com/qemu/qemu/commit/085ce73103c8e2450e72281bd792dfc39ff963d0
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: f24b95577546522cc0d7be1a337bbfae34deea54
https://github.com/qemu/qemu/commit/f24b95577546522cc0d7be1a337bbfae34deea54
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: fd1aac2e927a24184e5e177b2410db49655da9a9
https://github.com/qemu/qemu/commit/fd1aac2e927a24184e5e177b2410db49655da9a9
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: 5c138a693439a2cf55d824493f9cf6bb6a6df553
https://github.com/qemu/qemu/commit/5c138a693439a2cf55d824493f9cf6bb6a6df553
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: d0ffe1b6491111572f7cedda19194cc45e5c0fac
https://github.com/qemu/qemu/commit/d0ffe1b6491111572f7cedda19194cc45e5c0fac
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: 43df3c9f418ea5b16595801c262220341bcd8b27
https://github.com/qemu/qemu/commit/43df3c9f418ea5b16595801c262220341bcd8b27
Author: Thomas Huth <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M .gitlab-ci.d/cirrus.yml
R .gitlab-ci.d/cirrus/freebsd-13.vars
A .gitlab-ci.d/cirrus/freebsd-14.vars
M tests/lcitool/refresh
M tests/vm/freebsd
Log Message:
-----------
Update FreeBSD CI jobs FreeBSD 14.1
The current FreeBSD CI jobs are failing installation since the
"opencv" package is now missing there. Updating to 14.1 fixes
the issue.
Message-Id: <[email protected]>
Reviewed-by: Li-Wen Hsu <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit b4358ed4fd29c21c69e492d814f0926c58caa10f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: afd40f9ff768c4e2b933b2bf6817e5efacb80555
https://github.com/qemu/qemu/commit/afd40f9ff768c4e2b933b2bf6817e5efacb80555
Author: Thomas Huth <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M .gitlab-ci.d/cirrus.yml
R .gitlab-ci.d/cirrus/kvm-build.yml
Log Message:
-----------
.gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs
During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.
Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit cc6cb422e09592158586279fddeef107df05ecbb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a1d4a5448a32fb123e51bc62086c75bc10c13863
https://github.com/qemu/qemu/commit/a1d4a5448a32fb123e51bc62086c75bc10c13863
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2024-12-03 (Tue, 03 Dec 2024)
Changed paths:
M .gitlab-ci.d/cirrus.yml
R .gitlab-ci.d/cirrus/macos-13.vars
M tests/lcitool/refresh
Log Message:
-----------
.gitlab-ci.d/cirrus: Drop support for macOS 13 (Ventura)
macOS 15 "Sequoia" was released on September 16, 2024 [1].
According to QEMU's support policy, we stop supporting
the previous major release two years after the the new
major release has been published. Time to remove support
for macOS 13 (Ventura, released on October 2022, [2]).
Promote the macOS 14 job, which was only built manually,
to be run by default.
[1] https://www.apple.com/newsroom/2024/09/macos-sequoia-is-available-today/
[2] https://www.apple.com/newsroom/2022/10/macos-ventura-is-now-available/
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit de11da6448ca4278197fb2923af06c50e2385259)
[thuth: Pick some changes from 9094f7c934, too]
Signed-off-by: Thomas Huth <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/f30c55b42099...a1d4a5448a32
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
