Branch: refs/heads/staging-9.1
Home: https://github.com/qemu/qemu
Commit: f7ff24a6e9259726db08e36cdc28645c0a3b1a70
https://github.com/qemu/qemu/commit/f7ff24a6e9259726db08e36cdc28645c0a3b1a70
Author: Alexander Graf <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M target/i386/cpu.h
M target/i386/tcg/seg_helper.c
M target/i386/tcg/sysemu/excp_helper.c
Log Message:
-----------
target/i386: Fix legacy page table walk
Commit b56617bbcb4 ("target/i386: Walk NPT in guest real mode") added
logic to run the page table walker even in real mode if we are in NPT
mode. That function then determined whether real mode or paging is
active based on whether the pg_mode variable was 0.
Unfortunately pg_mode is 0 in two situations:
1) Paging is disabled (real mode)
2) Paging is in 2-level paging mode (32bit without PAE)
That means the walker now assumed that 2-level paging mode was real
mode, breaking NetBSD as well as Windows XP.
To fix that, this patch adds a new PG flag to pg_mode which indicates
whether paging is active at all and uses that to determine whether we
are in real mode or not.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2654
Fixes: b56617bbcb4 ("target/i386: Walk NPT in guest real mode")
Fixes: 01bfc2e2959 (commit b56617bbcb4 in stable-9.1.x series)
Signed-off-by: Alexander Graf <[email protected]>
Reported-by: Mark Cave-Ayland <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 8fa11a4df344f58375eb26b3b65004345f21ef37)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 494d6b81fe7a268656b4e0de87259b895fdb97d2
https://github.com/qemu/qemu/commit/494d6b81fe7a268656b4e0de87259b895fdb97d2
Author: Peter Maydell <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M hw/i386/pc.c
Log Message:
-----------
hw/i386/pc: Don't try to init PCI NICs if there is no PCI bus
The 'isapc' machine type has no PCI bus, but pc_nic_init() still
calls pci_init_nic_devices() passing it a NULL bus pointer. This
causes the clang sanitizer to complain:
$ ./build/clang/qemu-system-i386 -M isapc
../../hw/pci/pci.c:1866:39: runtime error: member access within null pointer of
type 'PCIBus' (aka 'struct PCIBus')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
../../hw/pci/pci.c:1866:39 in
This is because pci_init_nic_devices() does
&bus->qbus
which is undefined behaviour on a NULL pointer even though we're not
actually dereferencing the pointer. (We don't actually crash as
a result, so if you aren't running a sanitizer build then there
are no user-visible effects.)
Make pc_nic_init() avoid trying to initialize PCI NICs on a non-PCI
system.
Cc: [email protected]
Fixes: 8d39f9ba14d64 ("hw/i386/pc: use qemu_get_nic_info() and
pci_init_nic_devices()")
Signed-off-by: Peter Maydell <[email protected]>
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit bd0e501e1a4813fa36a4cf9842aaf430323a03c3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9699e9f06dc58043a97934db9b9e17f687d6a517
https://github.com/qemu/qemu/commit/9699e9f06dc58043a97934db9b9e17f687d6a517
Author: Helge Deller <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: Fix setreuid and setregid to use direct syscalls
The commit fd6f7798ac30 ("linux-user: Use direct syscalls for setuid(),
etc") added direct syscall wrappers for setuid(), setgid(), etc since the
system calls have different semantics than the libc functions.
Add and use the corresponding wrappers for setreuid and setregid which
were missed in that commit.
This fixes the build of the debian package of the uid_wrapper library
(https://cwrap.org/uid_wrapper.html) when running linux-user.
Cc: [email protected]
Signed-off-by: Helge Deller <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Ilya Leoshkevich <[email protected]>
Message-ID: <Zyo2jMKqq8hG8Pkz@p100>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 8491026a08b417b2d4070f7c373dcb43134c5312)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a820a85ac83180ed597a01d05450b6f656a8c206
https://github.com/qemu/qemu/commit/a820a85ac83180ed597a01d05450b6f656a8c206
Author: Richard Henderson <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M target/arm/tcg/sve_helper.c
Log Message:
-----------
target/arm: Drop user-only special case in sve_stN_r
This path is reachable with plugins enabled, and provoked
with run-plugin-catch-syscalls-with-libinline.so.
Cc: [email protected]
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit f27550804688da43c6e0d87b2f9e143adbf76271)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6e813172b1bd48f94e0a1c717fe3c2b4a701f892
https://github.com/qemu/qemu/commit/6e813172b1bd48f94e0a1c717fe3c2b4a701f892
Author: Richard Henderson <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M accel/tcg/user-exec.c
Log Message:
-----------
accel/tcg: Fix user-only probe_access_internal plugin check
The acc_flag check for write should have been against PAGE_WRITE_ORG,
not PAGE_WRITE. But it is better to combine two acc_flag checks
to a single check against access_type. This matches the system code
in cputlb.c.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2647
Signed-off-by: Richard Henderson <[email protected]>
Message-Id: [email protected]
Reviewed-by: Alex Bennée <[email protected]>
(cherry picked from commit 2a339fee450638b512c5122281cb5ab49331cfb8)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b870db1c24c7bcba00e8fe51152170e38aa0ccf0
https://github.com/qemu/qemu/commit/b870db1c24c7bcba00e8fe51152170e38aa0ccf0
Author: Ilya Leoshkevich <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M linux-user/elfload.c
Log Message:
-----------
linux-user: Tolerate CONFIG_LSM_MMAP_MIN_ADDR
Running qemu-i386 on a system running with SELinux in enforcing mode
(more precisely: s390x trixie container on Fedora 40) fails with:
qemu-i386: tests/tcg/i386-linux-user/sigreturn-sigmask: Unable to find a
guest_base to satisfy all guest address mapping requirements
00000000-ffffffff
The reason is that main() determines mmap_min_addr from
/proc/sys/vm/mmap_min_addr, but SELinux additionally defines
CONFIG_LSM_MMAP_MIN_ADDR, which is normally larger: 32K or 64K, but,
in general, can be anything. There is no portable way to query its
value: /boot/config, /proc/config and /proc/config.gz are distro- and
environment-specific.
Once the identity map fails, the magnitude of guest_base does not
matter, so fix by starting the search from 1M or 1G.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2598
Suggested-by: Richard Henderson <[email protected]>
Signed-off-by: Ilya Leoshkevich <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit fb7f3572b111ffb6c2dd2c7f6c5b4dc57dd8a3f5)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 23c24fbfb8450fd7fc56f1868dd86f204e3970e5
https://github.com/qemu/qemu/commit/23c24fbfb8450fd7fc56f1868dd86f204e3970e5
Author: Richard Henderson <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M linux-user/arm/Makefile.vdso
M linux-user/arm/vdso-be.so
M linux-user/arm/vdso-le.so
Log Message:
-----------
linux-user/arm: Reduce vdso alignment to 4k
Reduce vdso alignment to minimum page size.
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit f7150b2151398c9274686d06c2c1e24618aa4cd6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e5d832b6d3f0132cc1e5f23eaa09ce0728a09a5f
https://github.com/qemu/qemu/commit/e5d832b6d3f0132cc1e5f23eaa09ce0728a09a5f
Author: Richard Henderson <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M linux-user/arm/Makefile.vdso
M linux-user/arm/meson.build
R linux-user/arm/vdso-be.so
A linux-user/arm/vdso-be32.so
A linux-user/arm/vdso-be8.so
M linux-user/elfload.c
Log Message:
-----------
linux-user/arm: Select vdso for be8 and be32 modes
In be8 mode, instructions are little-endian.
In be32 mode, instructions are big-endian.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2333
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 95c9e2209cc09453cfd49e91321df254ccbf466f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 35e5688153af312e826195dd4a7f29b071b96de4
https://github.com/qemu/qemu/commit/35e5688153af312e826195dd4a7f29b071b96de4
Author: Peter Maydell <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M tcg/tcg-op-gvec.c
Log Message:
-----------
tcg: Allow top bit of SIMD_DATA_BITS to be set in simd_desc()
In simd_desc() we create a SIMD descriptor from various pieces
including an arbitrary data value from the caller. We try to
sanitize these to make sure everything will fit: the 'data' value
needs to fit in the SIMD_DATA_BITS (== 22) sized field. However we
do that sanitizing with:
tcg_debug_assert(data == sextract32(data, 0, SIMD_DATA_BITS));
This works for the case where the data is supposed to be considered
as a signed integer (which can then be returned via simd_data()).
However, some callers want to treat the data value as unsigned.
Specifically, for the Arm SVE operations, make_svemte_desc()
assembles a data value as a collection of fields, and it needs to use
all 22 bits. Currently if MTE is enabled then its MTEDESC SIZEM1
field may have the most significant bit set, and then it will trip
this assertion.
Loosen the assertion so that we only check that the data value will
fit into the field in some way, either as a signed or as an unsigned
value. This means we will fail to detect some kinds of bug in the
callers, but we won't spuriously assert for intentional use of the
data field as unsigned.
Cc: [email protected]
Fixes: db432672dc50e ("tcg: Add generic vector expanders")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2601
Signed-off-by: Peter Maydell <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 8377e3fb854d126ba10e61cb6b60885af8443ad4)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: de6c4c825959b7924e567afef1c856b3cd46e73c
https://github.com/qemu/qemu/commit/de6c4c825959b7924e567afef1c856b3cd46e73c
Author: Pierrick Bouvier <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M target/i386/tcg/sysemu/excp_helper.c
Log Message:
-----------
target/i386: fix hang when using slow path for ptw_setl
When instrumenting memory accesses for plugin, we force memory accesses
to use the slow path for mmu [1]. This create a situation where we end
up calling ptw_setl_slow. This was fixed recently in [2] but the issue
still could appear out of plugins use case.
Since this function gets called during a cpu_exec, start_exclusive then
hangs. This exclusive section was introduced initially for security
reasons [3].
I suspect this code path was never triggered, because ptw_setl_slow
would always be called transitively from cpu_exec, resulting in a hang.
[1]
https://gitlab.com/qemu-project/qemu/-/commit/6d03226b42247b68ab2f0b3663e0f624335a4055
[2]
https://gitlab.com/qemu-project/qemu/-/commit/115ade42d50144c15b74368d32dc734ea277d853
[2]
https://gitlab.com/qemu-project/qemu/-/commit/3a41aa8226bdaa709121515faea6e0e5ad1efa39
in 9.1.x series
[3] https://gitlab.com/qemu-project/qemu/-/issues/279
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2566
Signed-off-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 7ba055b49b74c4d2f4a338c5198485bdff373fb1)
Signed-off-by: Michael Tokarev <[email protected]>
(Mjt: mention [2] in 9.1.x series)
Commit: 019d93004bc0b65185ec7887b9b848d0849609fe
https://github.com/qemu/qemu/commit/019d93004bc0b65185ec7887b9b848d0849609fe
Author: Cédric Le Goater <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M hw/vfio/container-base.c
Log Message:
-----------
vfio/container: Fix container object destruction
When commit 96b7af4388b3 intoduced a .instance_finalize() handler,
it did not take into account that the container was not necessarily
inserted into the container list of the address space. Hence, if
the container object is destroyed, by calling object_unref() for
example, before vfio_address_space_insert() is called, QEMU may
crash when removing the container from the list as done in
vfio_container_instance_finalize(). This was seen with an SEV-SNP
guest for which discarding of RAM fails.
To resolve this issue, use the safe version of QLIST_REMOVE().
Cc: Zhenzhong Duan <[email protected]>
Cc: Eric Auger <[email protected]>
Fixes: 96b7af4388b3 ("vfio/container: Move vfio_container_destroy() to an
instance_finalize() handler")
Reviewed-by: Zhenzhong Duan <[email protected]>
Signed-off-by: Cédric Le Goater <[email protected]>
(cherry picked from commit ebbf7c60bbd1ceedf9faf962e428ceda2388c248)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 072d407be3f7dc9a6db8c214ee0dda3278201da1
https://github.com/qemu/qemu/commit/072d407be3f7dc9a6db8c214ee0dda3278201da1
Author: Thomas Huth <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M include/hw/misc/mos6522.h
Log Message:
-----------
hw/misc/mos6522: Fix bad class definition of the MOS6522 device
When compiling QEMU with --enable-cfi, the "q800" m68k machine
currently crashes very early, when the q800_machine_init() function
tries to wire the interrupts of the "via1" device.
This happens because TYPE_MOS6522_Q800_VIA1 is supposed to be a
proper SysBus device, but its parent (TYPE_MOS6522) has a mistake
in its class definition where it is only derived from DeviceClass,
and not from SysBusDeviceClass, so we end up in funny memory access
issues here. Using the right class hierarchy for the MOS6522 device
fixes the problem.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2675
Signed-off-by: Thomas Huth <[email protected]>
Fixes: 51f233ec92 ("misc: introduce new mos6522 VIA device")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Mark Cave-Ayland <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit c3d7c18b0d616cf7fb3c1f325503e1462307209d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8d9c6f6fa9eebd09ad8d0b4b4de4a0ec57e756d1
https://github.com/qemu/qemu/commit/8d9c6f6fa9eebd09ad8d0b4b4de4a0ec57e756d1
Author: Paolo Bonzini <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M hw/audio/hda-codec.c
Log Message:
-----------
Revert "hw/audio/hda: fix memory leak on audio setup"
This reverts commit 6d03242a7e47815ed56687ecd13f683d8da3f2fe,
which causes SPICE audio to break. While arguably this is a SPICE bug,
it is possible to fix the leak in a less heavy-handed way.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2639
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit e125d9835b89545b09c0367404dcf69f18ae6de1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a7b7953d8de6f01833e759d8c19a862f438caa89
https://github.com/qemu/qemu/commit/a7b7953d8de6f01833e759d8c19a862f438caa89
Author: Paolo Bonzini <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M hw/audio/hda-codec.c
Log Message:
-----------
hw/audio/hda: fix memory leak on audio setup
When SET_STREAM_FORMAT is called, the st->buft timer is overwritten, thus
causing a memory leak. This was originally fixed in commit 816139ae6a5
("hw/audio/hda: fix memory leak on audio setup", 2024-11-14) but that
caused the audio to break in SPICE.
Fortunately, a simpler fix is possible. The timer only needs to be
reset, because the callback is always the same (st->output is set at
realize time in hda_audio_init); call to timer_new_ns overkill. Replace
it with timer_del and only initialize the timer once; for simplicity,
do it even if use_timer is false.
An even simpler fix would be to free the old time in hda_audio_setup().
However, it seems better to place the initialization of the timer close
to that of st->ouput.
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
(cherry picked from commit 626b39006d2f9b1378a04cb88a2187bb852cb055)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 71c418c4a56411c0a37ffb137e13c8eb966cf209
https://github.com/qemu/qemu/commit/71c418c4a56411c0a37ffb137e13c8eb966cf209
Author: Guenter Roeck <[email protected]>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M hw/usb/dev-hub.c
Log Message:
-----------
usb-hub: Fix handling port power control messages
The ClearPortFeature control message fails for PORT_POWER because there
is no break; at the end of the case statement, causing it to fall through
to the failure handler. Add the missing break; to solve the problem.
Fixes: 1cc403eb21 ("usb-hub: emulate per port power switching")
Signed-off-by: Guenter Roeck <[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 b2cc69997924b651c0c6f4037782e25f2e438715)
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/4240bfa68bac...71c418c4a564
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
