Branch: refs/heads/stable-9.1
Home: https://github.com/qemu/qemu
Commit: 994f8717ee063ec6101c5d49714e3fab2bb2f27c
https://github.com/qemu/qemu/commit/994f8717ee063ec6101c5d49714e3fab2bb2f27c
Author: Paolo Bonzini <[email protected]>
Date: 2024-10-18 (Fri, 18 Oct 2024)
Changed paths:
M tcg/s390x/tcg-target.c.inc
Log Message:
-----------
tcg/s390x: fix constraint for 32-bit TSTEQ/TSTNE
32-bit TSTEQ and TSTNE is subject to the same constraints as
for 64-bit, but setcond_i32 and negsetcond_i32 were incorrectly
using TCG_CT_CONST ("i") instead of TCG_CT_CONST_CMP ("C").
Adjust the constraint and make tcg_target_const_match use the
same sequence as tgen_cmp2: first check if the constant is a
valid operand for TSTEQ/TSTNE, then accept everything for 32-bit
non-test comparisons, finally check if the constant is a valid
operand for 64-bit non-test comparisons.
Reported-by: Philippe Mathieu-Daudé <[email protected]>
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 615586cb356811e46c2e5f85c36db4b93f8381cd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9eb3cc1641b59a49a7180554de399143a8b69faf
https://github.com/qemu/qemu/commit/9eb3cc1641b59a49a7180554de399143a8b69faf
Author: Peter Xu <[email protected]>
Date: 2024-10-18 (Fri, 18 Oct 2024)
Changed paths:
M accel/kvm/kvm-all.c
M accel/kvm/trace-events
M include/sysemu/kvm_int.h
Log Message:
-----------
KVM: Dynamic sized kvm memslots array
Zhiyi reported an infinite loop issue in VFIO use case. The cause of that
was a separate discussion, however during that I found a regression of
dirty sync slowness when profiling.
Each KVMMemoryListerner maintains an array of kvm memslots. Currently it's
statically allocated to be the max supported by the kernel. However after
Linux commit 4fc096a99e ("KVM: Raise the maximum number of user memslots"),
the max supported memslots reported now grows to some number large enough
so that it may not be wise to always statically allocate with the max
reported.
What's worse, QEMU kvm code still walks all the allocated memslots entries
to do any form of lookups. It can drastically slow down all memslot
operations because each of such loop can run over 32K times on the new
kernels.
Fix this issue by making the memslots to be allocated dynamically.
Here the initial size was set to 16 because it should cover the basic VM
usages, so that the hope is the majority VM use case may not even need to
grow at all (e.g. if one starts a VM with ./qemu-system-x86_64 by default
it'll consume 9 memslots), however not too large to waste memory.
There can also be even better way to address this, but so far this is the
simplest and should be already better even than before we grow the max
supported memslots. For example, in the case of above issue when VFIO was
attached on a 32GB system, there are only ~10 memslots used. So it could
be good enough as of now.
In the above VFIO context, measurement shows that the precopy dirty sync
shrinked from ~86ms to ~3ms after this patch applied. It should also apply
to any KVM enabled VM even without VFIO.
NOTE: we don't have a FIXES tag for this patch because there's no real
commit that regressed this in QEMU. Such behavior existed for a long time,
but only start to be a problem when the kernel reports very large
nr_slots_max value. However that's pretty common now (the kernel change
was merged in 2021) so we attached cc:stable because we'll want this change
to be backported to stable branches.
Cc: qemu-stable <[email protected]>
Reported-by: Zhiyi Guo <[email protected]>
Tested-by: Zhiyi Guo <[email protected]>
Signed-off-by: Peter Xu <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Reviewed-by: Fabiano Rosas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 5504a8126115d173687b37e657312a8ffe29fc0c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6ad00eb0d39526e22b6956349fdc8f17916c678f
https://github.com/qemu/qemu/commit/6ad00eb0d39526e22b6956349fdc8f17916c678f
Author: Paolo Bonzini <[email protected]>
Date: 2024-10-18 (Fri, 18 Oct 2024)
Changed paths:
M target/i386/tcg/seg_helper.c
Log Message:
-----------
target/i386/tcg: Use DPL-level accesses for interrupts and call gates
Stack accesses should be explicit and use the privilege level of the
target stack. This ensures that SMAP is not applied when the target
stack is in ring 3.
This fixes a bug wherein i386/tcg assumed that an interrupt return, or a
far call using the CALL or JMP instruction, was always going from kernel
or user mode to kernel mode when using a call gate. This assumption is
violated if the call gate has a DPL that is greater than 0.
Analyzed-by: Robert R. Henry <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/249
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit e136648c5c95ee4ea233cccf999c07e065bef26d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 474487611b7d14be6bd864e8b2a2a642bad9f720
https://github.com/qemu/qemu/commit/474487611b7d14be6bd864e8b2a2a642bad9f720
Author: Tom Dohrmann <[email protected]>
Date: 2024-10-18 (Fri, 18 Oct 2024)
Changed paths:
M accel/kvm/kvm-all.c
Log Message:
-----------
accel/kvm: check for KVM_CAP_READONLY_MEM on VM
KVM_CAP_READONLY_MEM used to be a global capability, but with the
introduction of AMD SEV-SNP confidential VMs, this extension is not
always available on all VM types [1,2].
Query the extension on the VM level instead of on the KVM level.
[1]
https://patchwork.kernel.org/project/kvm/patch/[email protected]/
[2]
https://patchwork.kernel.org/project/kvm/patch/[email protected]/
Cc: Paolo Bonzini <[email protected]>
Signed-off-by: Tom Dohrmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 64e0e63ea16aa0122dc0c41a0679da0ae4616208)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 065bba4dfa55c1440d1628adae74e7386b32d0f0
https://github.com/qemu/qemu/commit/065bba4dfa55c1440d1628adae74e7386b32d0f0
Author: Richard Henderson <[email protected]>
Date: 2024-10-18 (Fri, 18 Oct 2024)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/i386: Use only 16 and 32-bit operands for IN/OUT
The REX.W prefix is ignored for these instructions.
Mirror the solution already used for INS/OUTS: X86_SIZE_z.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2581
Signed-off-by: Richard Henderson <[email protected]>
Cc: [email protected]
Link:
https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 15d955975bd484c2c66af0d6daaa02a7d04d2256)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 8dca0ab4c406690f02641ec49ce81320188ae543
https://github.com/qemu/qemu/commit/8dca0ab4c406690f02641ec49ce81320188ae543
Author: Stefan Berger <[email protected]>
Date: 2024-10-21 (Mon, 21 Oct 2024)
Changed paths:
M tests/qtest/tpm-tests.c
Log Message:
-----------
tests: Wait for migration completion on destination QEMU to avoid failures
Rather than waiting for the completion of migration on the source side,
wait for it on the destination QEMU side to avoid accessing the TPM TIS
memory mapped registers before QEMU could restore their state. This
error condition could be triggered on busy systems where the destination
QEMU did not have enough time to restore the TIS state while the test case
was already reading its registers. The test case was for example reading
the STS register and received an unexpected value (0xffffffff), which
lead to a segmentation fault later on due to trying to read 0xffff bytes
from the TIS into a buffer.
Cc: <[email protected]>
Reported-by: Fabiano Rosas <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Stefan Berger <[email protected]>
(cherry picked from commit d9280ea3174700170d39c4cdd3f587f260757711)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6cb943c361451991fd151ef0335969785ab847f3
https://github.com/qemu/qemu/commit/6cb943c361451991fd151ef0335969785ab847f3
Author: Thomas Huth <[email protected]>
Date: 2024-10-22 (Tue, 22 Oct 2024)
Changed paths:
M hw/sh4/r2d.c
Log Message:
-----------
Revert "hw/sh4/r2d: Realize IDE controller before accessing it"
This reverts commit 3c5f86a22686ef475a8259c0d8ee714f61c770c9.
Changing the order here caused a regression with the "tuxrun"
kernels (from https://storage.tuxboot.com/20230331/) - ATA commands
fail with a "ata1: lost interrupt (Status 0x58)" message.
Apparently we need to wire the interrupt here first before
realizing the device, so revert the change to the original
behavior.
Reported-by: Guenter Roeck <[email protected]>
Acked-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 68ad89b75ad2bb5f38abea815a50ec17a142565a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 88aaef7205d9b03617224db972bb4699b7d6579f
https://github.com/qemu/qemu/commit/88aaef7205d9b03617224db972bb4699b7d6579f
Author: Peter Maydell <[email protected]>
Date: 2024-10-24 (Thu, 24 Oct 2024)
Changed paths:
M tests/qemu-iotests/211.out
Log Message:
-----------
tests/qemu-iotests/211.out: Update to expect MapEntry 'compressed' field
In commit 52b10c9c0c68e90f in 2023 the QAPI MapEntry struct was
updated to add a 'compressed' field. That commit updated a number
of iotest expected-output files, but missed 211, which is vdi
specific. The result is that
./check -vdi
and more specifically
./check -vdi 211
fails because the expected and actual output don't match.
Update the reference output.
Cc: [email protected]
Fixes: 52b10c9c0c68e90f ("qemu-img: map: report compressed data blocks")
Signed-off-by: Peter Maydell <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit d60bd080e783107cb876a6f16561fe03f9dcbca7)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a22bd36631ecb0e8dfab73f7f1491c6d2cd340fb
https://github.com/qemu/qemu/commit/a22bd36631ecb0e8dfab73f7f1491c6d2cd340fb
Author: Kevin Wolf <[email protected]>
Date: 2024-10-24 (Thu, 24 Oct 2024)
Changed paths:
M block/raw-format.c
Log Message:
-----------
raw-format: Fix error message for invalid offset/size
s->offset and s->size are only set at the end of the function and still
contain the old values when formatting the error message. Print the
parameters with the new values that we actually checked instead.
Fixes: 500e2434207d ('raw-format: Split raw_read_options()')
Signed-off-by: Kevin Wolf <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Hanna Czenczek <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 04bbc3ee52b32ac465547bb40c1f090a1b8f315a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fbe5afdd30cdf428ee3f65d9bb8f9fdbbe4387bf
https://github.com/qemu/qemu/commit/fbe5afdd30cdf428ee3f65d9bb8f9fdbbe4387bf
Author: Richard Henderson <[email protected]>
Date: 2024-10-25 (Fri, 25 Oct 2024)
Changed paths:
M tcg/tcg.c
Log Message:
-----------
tcg: Reset data_gen_ptr correctly
This pointer needs to be reset after overflow just like
code_buf and code_ptr.
Cc: [email protected]
Fixes: 57a269469db ("tcg: Infrastructure for managing constant pools")
Acked-by: Alistair Francis <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Reviewed-by: LIU Zhiwei <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit a7cfd751fb269de4a93bf1658cb13911c7ac77cc)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 01bfc2e2959904265aa522585e36f7a4dc41b58a
https://github.com/qemu/qemu/commit/01bfc2e2959904265aa522585e36f7a4dc41b58a
Author: Alexander Graf <[email protected]>
Date: 2024-10-25 (Fri, 25 Oct 2024)
Changed paths:
M target/i386/tcg/sysemu/excp_helper.c
Log Message:
-----------
target/i386: Walk NPT in guest real mode
When translating virtual to physical address with a guest CPU that
supports nested paging (NPT), we need to perform every page table walk
access indirectly through the NPT, which we correctly do.
However, we treat real mode (no page table walk) special: In that case,
we currently just skip any walks and translate VA -> PA. With NPT
enabled, we also need to then perform NPT walk to do GVA -> GPA -> HPA
which we fail to do so far.
The net result of that is that TCG VMs with NPT enabled that execute
real mode code (like SeaBIOS) end up with GPA==HPA mappings which means
the guest accesses host code and data. This typically shows as failure
to boot guests.
This patch changes the page walk logic for NPT enabled guests so that we
always perform a GVA -> GPA translation and then skip any logic that
requires an actual PTE.
That way, all remaining logic to walk the NPT stays and we successfully
walk the NPT in real mode.
Cc: [email protected]
Fixes: fe441054bb3f0 ("target-i386: Add NPT support")
Signed-off-by: Alexander Graf <[email protected]>
Reported-by: Eduard Vlad <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit b56617bbcb473c25815d1bf475e326f84563b1de)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3a41aa8226bdaa709121515faea6e0e5ad1efa39
https://github.com/qemu/qemu/commit/3a41aa8226bdaa709121515faea6e0e5ad1efa39
Author: Richard Henderson <[email protected]>
Date: 2024-10-25 (Fri, 25 Oct 2024)
Changed paths:
M target/i386/tcg/sysemu/excp_helper.c
Log Message:
-----------
target/i386: Use probe_access_full_mmu in ptw_translate
The probe_access_full_mmu function was designed for this purpose,
and does not report the memory operation event to plugins.
Cc: [email protected]
Fixes: 6d03226b422 ("plugins: force slow path when plugins instrument memory
ops")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
(cherry picked from commit 115ade42d50144c15b74368d32dc734ea277d853)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 356d3ecec0feef1be7a2b2db37d1f3f99a0562be
https://github.com/qemu/qemu/commit/356d3ecec0feef1be7a2b2db37d1f3f99a0562be
Author: Ilya Leoshkevich <[email protected]>
Date: 2024-10-25 (Fri, 25 Oct 2024)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: Emulate /proc/self/maps under mmap_lock
If one thread modifies the mappings and another thread prints them,
a situation may occur that the printer thread sees a guest mapping
without a corresponding host mapping, leading to a crash in
open_self_maps_2().
Cc: [email protected]
Fixes: 7b7a3366e142 ("linux-user: Use walk_memory_regions for open_self_maps")
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Laurent Vivier <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit bbd5630a75e70a0f1bcf04de74c94aa94a145628)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 29027de5da0f9308f51a51de1b7c19aa1893d32d
https://github.com/qemu/qemu/commit/29027de5da0f9308f51a51de1b7c19aa1893d32d
Author: Ilya Leoshkevich <[email protected]>
Date: 2024-10-25 (Fri, 25 Oct 2024)
Changed paths:
M linux-user/ppc/signal.c
Log Message:
-----------
linux-user/ppc: Fix sigmask endianness issue in sigreturn
do_setcontext() copies the target sigmask without endianness handling
and then uses target_to_host_sigset_internal(), which expects a
byte-swapped one. Use target_to_host_sigset() instead.
Fixes: bcd4933a23f1 ("linux-user: ppc signal handling")
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 8704132805cf7a3259d1c5a073b3c2b92afa2616)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b861f65eaf80eb3815d9df509137e9f0cf91f7cd
https://github.com/qemu/qemu/commit/b861f65eaf80eb3815d9df509137e9f0cf91f7cd
Author: Yao Zi <[email protected]>
Date: 2024-10-25 (Fri, 25 Oct 2024)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user/riscv: Fix definition of RISCV_HWPROBE_EXT_ZVFHMIN
Current definition yields a negative 32bits value, messing up hwprobe
result when Zvfhmin extension presents. Replace it by using a 1ULL bit
shift value as done in kernel upstream.
Link:
https://github.com/torvalds/linux/commit/5ea6764d9095e234b024054f75ebbccc4f0eb146
Fixes: a3432cf227 ("linux-user/riscv: Sync hwprobe keys with Linux")
Cc: [email protected]
Signed-off-by: Yao Zi <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Richard Henderson <[email protected]>
(cherry picked from commit 310df7a9fe400f32cde8a7edf80daad12cd9cf02)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7926d4d0d15ee7b1b53aafbd1bccbf26d399d870
https://github.com/qemu/qemu/commit/7926d4d0d15ee7b1b53aafbd1bccbf26d399d870
Author: Avihai Horon <[email protected]>
Date: 2024-10-25 (Fri, 25 Oct 2024)
Changed paths:
M hw/vfio/migration.c
Log Message:
-----------
vfio/migration: Report only stop-copy size in vfio_state_pending_exact()
vfio_state_pending_exact() is used to update migration core how much
device data is left for the device migration. Currently, the sum of
pre-copy and stop-copy sizes of the VFIO device are reported.
The pre-copy size is obtained via the VFIO_MIG_GET_PRECOPY_INFO ioctl,
which returns the amount of device data available to be transferred
while the device is in the PRE_COPY states.
The stop-copy size is obtained via the VFIO_DEVICE_FEATURE_MIG_DATA_SIZE
ioctl, which returns the total amount of device data left to be
transferred in order to complete the device migration.
According to the above, current implementation is wrong -- it reports
extra overlapping data because pre-copy size is already contained in
stop-copy size. Fix it by reporting only stop-copy size.
Fixes: eda7362af959 ("vfio/migration: Add VFIO migration pre-copy support")
Signed-off-by: Avihai Horon <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
(cherry picked from commit 3b5948f808e3b99aedfa0aff45cffbe8b7ec07ed)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 4ab2bc6482bc883ab0834c2b6834468743d110b1
https://github.com/qemu/qemu/commit/4ab2bc6482bc883ab0834c2b6834468743d110b1
Author: Alex Bennée <[email protected]>
Date: 2024-10-28 (Mon, 28 Oct 2024)
Changed paths:
M .gitlab-ci.d/check-dco.py
M .gitlab-ci.d/check-patch.py
Log Message:
-----------
gitlab: make check-[dco|patch] a little more verbose
When git fails the rather terse backtrace only indicates it failed
without some useful context. Add some to make the log a little more
useful.
Reviewed-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 97f116f9c6fd127b6ed2953993fa9fb05e82f450)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 34f38a1b11d646a898cb6378706d3bcf5a786a9b
https://github.com/qemu/qemu/commit/34f38a1b11d646a898cb6378706d3bcf5a786a9b
Author: Pierrick Bouvier <[email protected]>
Date: 2024-10-29 (Tue, 29 Oct 2024)
Changed paths:
M tests/docker/dockerfiles/debian-loongarch-cross.docker
Log Message:
-----------
dockerfiles: fix default targets for debian-loongarch-cross
fix system target name, and remove --disable-system (which deactivates
system target).
Found using: make docker-test-build@debian-loongarch-cross V=1
Signed-off-by: Pierrick Bouvier <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Thomas Huth <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 24be5341fbeea341cca38b59d4c0928a8cf5fac1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c044440a42041ae2de94117dd9d17cfd7d80dfd8
https://github.com/qemu/qemu/commit/c044440a42041ae2de94117dd9d17cfd7d80dfd8
Author: Pierrick Bouvier <[email protected]>
Date: 2024-10-29 (Tue, 29 Oct 2024)
Changed paths:
M accel/tcg/plugin-gen.c
Log Message:
-----------
plugins: fix qemu_plugin_reset
34e5e1 refactored the plugin context initialization. After this change,
tcg_ctx->plugin_insn is not reset inconditionnally anymore, but only if
one plugin at least is active.
When uninstalling the last plugin active, we stopped reinitializing
tcg_ctx->plugin_insn, which leads to memory callbacks being emitted.
This results in an error as they don't appear in a plugin op sequence as
expected.
The correct fix is to make sure we reset plugin translation variables
after current block translation ends. This way, we can catch any
potential misuse of those after a given block, in more than fixing the
current bug.
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2570
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Pierrick Bouvier <[email protected]>
Tested-by: Robbin Ehn <[email protected]>
Message-Id: <[email protected]>
[AJB: trim patch version details from commit msg]
Signed-off-by: Alex Bennée <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit b56f7dd203c301231d3bb2d071b4e32b345f49d6)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6ea3f1f06b09867615b2069edd1c45ea40474cf5
https://github.com/qemu/qemu/commit/6ea3f1f06b09867615b2069edd1c45ea40474cf5
Author: Akihiko Odaki <[email protected]>
Date: 2024-10-30 (Wed, 30 Oct 2024)
Changed paths:
M net/net.c
Log Message:
-----------
net: Check if nc is NULL in qemu_get_vnet_hdr_len()
A netdev may not have a peer specified, resulting in NULL. We should
make it behave like /dev/null in such a case instead of letting it
cause segmentatin fault.
Fixes: 4b52d63249a5 ("tap: Remove qemu_using_vnet_hdr()")
Cc: [email protected]
Reported-by: Jonathan Cameron <[email protected]>
Signed-off-by: Akihiko Odaki <[email protected]>
Tested-by; Jonathan Cameron <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 76240dd2a37c7b361740616a7d6080beafdb8a71)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 289ac098b627f69a9571ab076f0ce49aae29b781
https://github.com/qemu/qemu/commit/289ac098b627f69a9571ab076f0ce49aae29b781
Author: Stefan Weil <[email protected]>
Date: 2024-10-30 (Wed, 30 Oct 2024)
Changed paths:
M net/colo-compare.c
Log Message:
-----------
Fix calculation of minimum in colo_compare_tcp
GitHub's CodeQL reports a critical error which is fixed by using the MIN macro:
Unsigned difference expression compared to zero
Signed-off-by: Stefan Weil <[email protected]>
Cc: [email protected]
Reviewed-by: Zhang Chen <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit e29bc931e1699a98959680f6776b48673825762b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 9657daca0e0011343d7469950d143b404464105f
https://github.com/qemu/qemu/commit/9657daca0e0011343d7469950d143b404464105f
Author: Daniel P. Berrangé <[email protected]>
Date: 2024-10-30 (Wed, 30 Oct 2024)
Changed paths:
M meson.build
M net/meson.build
Log Message:
-----------
net: fix build when libbpf is disabled, but libxdp is enabled
The net/af-xdp.c code is enabled when the libxdp library is present,
however, it also has direct API calls to bpf_xdp_query_id &
bpf_xdp_detach which are provided by the libbpf library.
As a result if building with --disable-libbpf, but libxdp gets
auto-detected, we'll fail to link QEMU
/usr/bin/ld: libcommon.a.p/net_af-xdp.c.o: undefined reference to symbol
'bpf_xdp_query_id@@LIBBPF_0.7.0'
There are two bugs here
* Since we have direct libbpf API calls, when building
net/af-xdp.c, we must tell meson that libbpf is a
dependancy, so that we directly link to it, rather
than relying on indirect linkage.
* When must skip probing for libxdp at all, when libbpf
is not found, raising an error if --enable-libxdp was
given explicitly.
Fixes: cb039ef3d9e3112da01e1ecd9b136ac9809ef733
Signed-off-by: Daniel P. Berrangé <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 1f37280b37dbf85f36748f359a9f8802c8fe7ccd)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: b5cd9f8b5bdfdd0cc6659b82c1ed189628a36827
https://github.com/qemu/qemu/commit/b5cd9f8b5bdfdd0cc6659b82c1ed189628a36827
Author: Bernhard Beschow <[email protected]>
Date: 2024-10-30 (Wed, 30 Oct 2024)
Changed paths:
M net/tap-win32.c
Log Message:
-----------
net/tap-win32: Fix gcc 14 format truncation errors
The patch fixes the following errors generated by GCC 14.2:
../src/net/tap-win32.c:343:19: error: '%s' directive output may be truncated
writing up to 255 bytes into a region of size 176 [-Werror=format-truncation=]
343 | "%s\\%s\\Connection",
| ^~
344 | NETWORK_CONNECTIONS_KEY, enum_name);
| ~~~~~~~~~
../src/net/tap-win32.c:341:9: note: 'snprintf' output between 92 and 347 bytes
into a destination of size 256
341 | snprintf(connection_string,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
342 | sizeof(connection_string),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
343 | "%s\\%s\\Connection",
| ~~~~~~~~~~~~~~~~~~~~~
344 | NETWORK_CONNECTIONS_KEY, enum_name);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/net/tap-win32.c:242:58: error: '%s' directive output may be truncated
writing up to 255 bytes into a region of size 178 [-Werror=format-truncation=]
242 | snprintf (unit_string, sizeof(unit_string), "%s\\%s",
| ^~
243 | ADAPTER_KEY, enum_name);
| ~~~~~~~~~
../src/net/tap-win32.c:242:9: note: 'snprintf' output between 79 and 334 bytes
into a destination of size 256
242 | snprintf (unit_string, sizeof(unit_string), "%s\\%s",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
243 | ADAPTER_KEY, enum_name);
| ~~~~~~~~~~~~~~~~~~~~~~~
../src/net/tap-win32.c:620:52: error: '%s' directive output may be truncated
writing up to 255 bytes into a region of size 245 [-Werror=format-truncation=]
620 | snprintf (device_path, sizeof(device_path), "%s%s%s",
| ^~
621 | USERMODEDEVICEDIR,
622 | device_guid,
| ~~~~~~~~~~~
../src/net/tap-win32.c:620:5: note: 'snprintf' output between 16 and 271 bytes
into a destination of size 256
620 | snprintf (device_path, sizeof(device_path), "%s%s%s",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
621 | USERMODEDEVICEDIR,
| ~~~~~~~~~~~~~~~~~~
622 | device_guid,
| ~~~~~~~~~~~~
623 | TAPSUFFIX);
| ~~~~~~~~~~
Signed-off-by: Bernhard Beschow <[email protected]>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2607
Cc: [email protected]
Reviewed-by: Michael Tokarev <[email protected]>
Reviewed-by: Pierrick Bouvier <[email protected]>
Signed-off-by: Jason Wang <[email protected]>
(cherry picked from commit 75fe36b4e8a994cdf9fd6eb601f49e96b1bc791d)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: ae0a9ccfe3739bdafce5fc2426d7b6a5ada9f126
https://github.com/qemu/qemu/commit/ae0a9ccfe3739bdafce5fc2426d7b6a5ada9f126
Author: Peter Maydell <[email protected]>
Date: 2024-10-31 (Thu, 31 Oct 2024)
Changed paths:
M target/arm/internals.h
Log Message:
-----------
target/arm: Don't assert in regime_is_user() for E10 mmuidx values
In regime_is_user() we assert if we're passed an ARMMMUIdx_E10_*
mmuidx value. This used to make sense because we only used this
function in ptw.c and would never use it on this kind of stage 1+2
mmuidx, only for an individual stage 1 or stage 2 mmuidx.
However, when we implemented FEAT_E0PD we added a callsite in
aa64_va_parameters(), which means this can now be called for
stage 1+2 mmuidx values if the guest sets the TCG_ELX.{E0PD0,E0PD1}
bits to enable use of the feature. This will then result in
an assertion failure later, for instance on a TLBI operation:
#6 0x00007ffff6d0e70f in g_assertion_message_expr
(domain=0x0, file=0x55555676eeba "../../target/arm/internals.h", line=978,
func=0x555556771d48 <__func__.5> "regime_is_user", expr=<optimised out>)
at ../../../glib/gtestutils.c:3279
#7 0x0000555555f286d2 in regime_is_user (env=0x555557f2fe00,
mmu_idx=ARMMMUIdx_E10_0) at ../../target/arm/internals.h:978
#8 0x0000555555f3e31c in aa64_va_parameters (env=0x555557f2fe00,
va=18446744073709551615, mmu_idx=ARMMMUIdx_E10_0, data=true, el1_is_aa32=false)
at ../../target/arm/helper.c:12048
#9 0x0000555555f3163b in tlbi_aa64_get_range (env=0x555557f2fe00,
mmuidx=ARMMMUIdx_E10_0, value=106721347371041) at ../../target/arm/helper.c:5214
#10 0x0000555555f317e8 in do_rvae_write (env=0x555557f2fe00,
value=106721347371041, idxmap=21, synced=true) at ../../target/arm/helper.c:5260
#11 0x0000555555f31925 in tlbi_aa64_rvae1is_write (env=0x555557f2fe00,
ri=0x555557fbeae0, value=106721347371041) at ../../target/arm/helper.c:5302
#12 0x0000555556036f8f in helper_set_cp_reg64 (env=0x555557f2fe00,
rip=0x555557fbeae0, value=106721347371041) at
../../target/arm/tcg/op_helper.c:965
Since we do know whether these mmuidx values are for usermode
or not, we can easily make regime_is_user() handle them:
ARMMMUIdx_E10_0 is user, and the other two are not.
Cc: [email protected]
Fixes: e4c93e44ab103f ("target/arm: Implement FEAT_E0PD")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Alex Bennée <[email protected]>
Tested-by: Alex Bennée <[email protected]>
Message-id: [email protected]
(cherry picked from commit 1505b651fdbd9af59a4a90876a62ae7ea2d4cd39)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fde3af1971f71a7b05dc6bcd6d1c9998b0b2c4c1
https://github.com/qemu/qemu/commit/fde3af1971f71a7b05dc6bcd6d1c9998b0b2c4c1
Author: Peter Maydell <[email protected]>
Date: 2024-10-31 (Thu, 31 Oct 2024)
Changed paths:
M hw/sd/omap_mmc.c
M hw/sd/sd.c
M include/hw/sd/sd.h
Log Message:
-----------
hw/sd/omap_mmc: Don't use sd_cmd_type_t
In commit 1ab08790bb75e4 we did some refactoring of the SD card
implementation, which included a rearrangement of the sd_cmd_type_t
enum values. Unfortunately we didn't notice that this enum is not
used solely inside the SD card model itself, but is also used by the
OMAP MMC controller device. In the OMAP MMC controller, it is used
to implement the handling of the Type field of the MMC_CMD register,
so changing the enum values so that they no longer lined up with the
bit definitions for that register field broke the controller model.
The effect is that Linux fails to boot from an SD card on the "sx1"
machine.
Give omap-mmc its own enum which we can document as needing to match
the encoding used in this device's register, so it isn't sharing
sd_cmd_type_t with the SD card model any more. We can then move
sd_cmd_type_t's definition out of sd.h and into sd.c, which is the
only place that uses it.
Cc: [email protected]
Fixes: 1ab08790bb75 ("hw/sd/sdcard: Store command type in SDProto")
Signed-off-by: Peter Maydell <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Message-id: [email protected]
(cherry picked from commit 77dd098a5e790e3ede0dea5ddd5f690086fe608c)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 10eb3721fccd06e81bf36ebdf39dc1504eba9beb
https://github.com/qemu/qemu/commit/10eb3721fccd06e81bf36ebdf39dc1504eba9beb
Author: Ido Plat <[email protected]>
Date: 2024-10-31 (Thu, 31 Oct 2024)
Changed paths:
M target/arm/tcg/helper-a64.c
Log Message:
-----------
target/arm: Fix arithmetic underflow in SETM instruction
Pass the stage size to step function callback, otherwise do_setm
would hang when size is larger then page size because stage size
would underflow. This fix changes do_setm to be more inline with
do_setp.
Cc: [email protected]
Fixes: 0e92818887dee ("target/arm: Implement the SET* instructions")
Signed-off-by: Ido Plat <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit bab209af35037b33f7eb1b8a3737085935bec3a3)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 13d162d4d098999e6b08c648ed9728ac4b61648e
https://github.com/qemu/qemu/commit/13d162d4d098999e6b08c648ed9728ac4b61648e
Author: Peter Maydell <[email protected]>
Date: 2024-10-31 (Thu, 31 Oct 2024)
Changed paths:
M target/arm/vfp_helper.c
Log Message:
-----------
target/arm: Store FPSR cumulative exception bits in env->vfp.fpsr
Currently we store the FPSR cumulative exception bits in the
float_status fields, and use env->vfp.fpsr only for the NZCV bits.
(The QC bit is stored in env->vfp.qc[].)
This works for TCG, but if QEMU was built without CONFIG_TCG (i.e.
with KVM support only) then we use the stub versions of
vfp_get_fpsr_from_host() and vfp_set_fpsr_to_host() which do nothing,
throwing away the cumulative exception bit state. The effect is that
if the FPSR state is round-tripped from KVM to QEMU then we lose the
cumulative exception bits. In particular, this will happen if the VM
is migrated. There is no user-visible bug when using KVM with a QEMU
binary that was built with CONFIG_TCG.
Fix this by always storing the cumulative exception bits in
env->vfp.fpsr. If we are using TCG then we may also keep pending
cumulative exception information in the float_status fields, so we
continue to fold that in on reads.
This change will also be helpful for implementing FEAT_AFP later,
because that includes a feature where in some situations we want to
cause input denormals to be flushed to zero without affecting the
existing state of the FPSR.IDC bit, so we need a place to store IDC
which is distinct from the various float_status fields.
(Note for stable backports: the bug goes back to 4a15527c9fee but
this code was refactored in commits ea8618382aba..a8ab8706d4cc461, so
fixing it in branches without those refactorings will mean either
backporting the refactor or else implementing a conceptually similar
fix for the old code.)
Cc: [email protected]
Fixes: 4a15527c9fee ("target/arm/vfp_helper: Restrict the SoftFloat use to TCG")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit d9c7adb6019f2ac3d6a5a36c4121341f4b6424af)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e69b2c679030300023e4261633537c86a0ddaee9
https://github.com/qemu/qemu/commit/e69b2c679030300023e4261633537c86a0ddaee9
Author: Paolo Bonzini <[email protected]>
Date: 2024-11-04 (Mon, 04 Nov 2024)
Changed paths:
M stubs/meson.build
Log Message:
-----------
stubs: avoid duplicate symbols in libqemuutil.a
qapi_event_send_device_deleted is always included (together with the
rest of QAPI) in libqemuutil.a if either system-mode emulation or tools
are being built, and in that case the stub causes a duplicate symbol
to appear in libqemuutil.a.
Add the symbol only if events are not being requested.
Cc: [email protected]
Reviewed-by: Alex Bennée <[email protected]>
Tested-by: Alex Bennée <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 388b849fb6c33882b481123568995a749a54f648)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 646746a131d550372a33235ad0c09f03b8eb820e
https://github.com/qemu/qemu/commit/646746a131d550372a33235ad0c09f03b8eb820e
Author: Evgenii Prokopiev <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/riscv/csr.c
Log Message:
-----------
target/riscv/csr.c: Fix an access to VXSAT
The register VXSAT should be RW only to the first bit.
The remaining bits should be 0.
The RISC-V Instruction Set Manual Volume I: Unprivileged Architecture
The vxsat CSR has a single read-write least-significant bit (vxsat[0])
that indicates if a fixed-point instruction has had to saturate an output
value to fit into a destination format. Bits vxsat[XLEN-1:1]
should be written as zeros.
Signed-off-by: Evgenii Prokopiev <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 5a60026cad4e9dba929cab4f63229e4b9110cf0a)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 1c627d726545038a6ed16fb38b2765a1c0981db5
https://github.com/qemu/qemu/commit/1c627d726545038a6ed16fb38b2765a1c0981db5
Author: TANG Tiancheng <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/riscv/cpu.h
Log Message:
-----------
target/riscv: Correct SXL return value for RV32 in RV64 QEMU
Ensure that riscv_cpu_sxl returns MXL_RV32 when runningRV32 in an
RV64 QEMU.
Signed-off-by: TANG Tiancheng <[email protected]>
Fixes: 05e6ca5e156 ("target/riscv: Ignore reserved bits in PTE for RV64")
Reviewed-by: Liu Zhiwei <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 929e4277c128772bad41cc795995f754cb9991af)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 59fad1ebadc28995c5d356d097ba6a4d42cae7e7
https://github.com/qemu/qemu/commit/59fad1ebadc28995c5d356d097ba6a4d42cae7e7
Author: Sergey Makarov <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/intc/sifive_plic.c
Log Message:
-----------
hw/intc: Don't clear pending bits on IRQ lowering
According to PLIC specification (chapter 5), there
is only one case, when interrupt is claimed. Fix
PLIC controller to match this behavior.
Signed-off-by: Sergey Makarov <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit a84be2baa9eca8bc500f866ad943b8f63dc99adf)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 08c6ed47e6fee0c4c536e1202c643a0ce36f48be
https://github.com/qemu/qemu/commit/08c6ed47e6fee0c4c536e1202c643a0ce36f48be
Author: Rob Bradford <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/riscv/cpu.c
Log Message:
-----------
target/riscv: Set vtype.vill on CPU reset
The RISC-V unprivileged specification "31.3.11. State of Vector
Extension at Reset" has a note that recommends vtype.vill be set on
reset as part of ensuring that the vector extension have a consistent
state at reset.
This change now makes QEMU consistent with Spike which sets vtype.vill
on reset.
Signed-off-by: Rob Bradford <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit f8c1f36a2e3dab4935e7c5690e578ac71765766b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2a5c4a91ca5fbd46f5a58eb9bf274af56dc7252c
https://github.com/qemu/qemu/commit/2a5c4a91ca5fbd46f5a58eb9bf274af56dc7252c
Author: Yong-Xuan Wang <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/intc/riscv_aplic.c
Log Message:
-----------
hw/intc/riscv_aplic: Check and update pending when write sourcecfg
The section 4.5.2 of the RISC-V AIA specification says that any write
to a sourcecfg register of an APLIC might (or might not) cause the
corresponding interrupt-pending bit to be set to one if the rectified
input value is high (= 1) under the new source mode.
If an interrupt is asserted before the driver configs its interrupt
type to APLIC, it's pending bit will not be set except a relevant
write to a setip or setipnum register. When we write the interrupt
type to sourcecfg register, if the APLIC device doesn't check
rectified input value and update the pending bit, this interrupt
might never becomes pending.
For APLIC.m, we can manully set pending by setip or setipnum
registers in driver. But for APLIC.w, the pending status totally
depends on the rectified input value, we can't control the pending
status via mmio registers. In this case, hw should check and update
pending status for us when writing sourcecfg registers.
Update QEMU emulation to handle "pre-existing" interrupts.
Signed-off-by: Yong-Xuan Wang <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit 2ae6cca1d3389801ee72fc5e58c52573218f3514)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7f9dc099c7fdad24fca85b4171df0713855164f5
https://github.com/qemu/qemu/commit/7f9dc099c7fdad24fca85b4171df0713855164f5
Author: Daniel Henrique Barboza <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: set 'aia_mode' to default in error path
When failing to set the selected AIA mode, 'aia_mode' is left untouched.
This means that 'aia_mode' will not reflect the actual AIA mode,
retrieved in 'default_aia_mode',
This is benign for now, but it will impact QMP query commands that will
expose the 'aia_mode' value, retrieving the wrong value.
Set 'aia_mode' to 'default_aia_mode' if we fail to change the AIA mode
in KVM.
While we're at it, rework the log/warning messages to be a bit less
verbose. Instead of:
KVM AIA: default mode is emul
qemu-system-riscv64: warning: KVM AIA: failed to set KVM AIA mode
We can use a single warning message:
qemu-system-riscv64: warning: KVM AIA: failed to set KVM AIA mode 'auto', using
default host mode 'emul'
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit d201a127e164b1683df5e7c93c6d42a74122db99)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 19a4974ca7ef967dae0eaae5fe0ebe44088ef186
https://github.com/qemu/qemu/commit/19a4974ca7ef967dae0eaae5fe0ebe44088ef186
Author: Daniel Henrique Barboza <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/riscv/kvm/kvm-cpu.c
Log Message:
-----------
target/riscv/kvm: clarify how 'riscv-aia' default works
We do not have control in the default 'riscv-aia' default value. We can
try to set it to a specific value, in this case 'auto', but there's no
guarantee that the host will accept it.
Couple with this we're always doing a 'qemu_log' to inform whether we're
ended up using the host default or if we managed to set the AIA mode to
the QEMU default we wanted to set.
Change the 'riscv-aia' description to better reflect how the option
works, and remove the two informative 'qemu_log' that are now unneeded:
if no message shows, riscv-aia was set to the default or uset-set value.
Signed-off-by: Daniel Henrique Barboza <[email protected]>
Acked-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit fd16cfb2995e9196b579d8885145c4247dfa6058)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 56478d5a5eafd7b419a69729f487d97c14696ec0
https://github.com/qemu/qemu/commit/56478d5a5eafd7b419a69729f487d97c14696ec0
Author: Anton Blanchard <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/riscv/vector_helper.c
Log Message:
-----------
target/riscv: Fix vcompress with rvv_ta_all_1s
vcompress packs vl or less fields into vd, so the tail starts after the
last packed field. This could be more clearly expressed in the ISA,
but for now this thread helps to explain it:
https://github.com/riscv/riscv-v-spec/issues/796
Signed-off-by: Anton Blanchard <[email protected]>
Reviewed-by: Daniel Henrique Barboza <[email protected]>
Reviewed-by: Alistair Francis <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
(cherry picked from commit c128d39edeff337220fc536a3e935bcba01ecb49)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 563d60e921597b0e829b2764646d43d7c445783f
https://github.com/qemu/qemu/commit/563d60e921597b0e829b2764646d43d7c445783f
Author: Ilya Leoshkevich <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/ppc/translate.c
Log Message:
-----------
target/ppc: Set ctx->opcode for decode_insn32()
divdu (without a dot) sometimes updates cr0, even though it shouldn't.
The reason is that gen_op_arith_divd() checks Rc(ctx->opcode), which is
not initialized. This field is initialized only for instructions that
go through decode_legacy(), and not decodetree.
There already was a similar issue fixed in commit 86e6202a57b1
("target/ppc: Make divw[u] handler method decodetree compatible.").
It's not immediately clear what else may access the uninitialized
ctx->opcode, so instead of playing whack-a-mole and changing the check
to compute_rc0, simply initialize ctx->opcode.
Cc: [email protected]
Fixes: 99082815f17f ("target/ppc: Add infrastructure for prefixed insns")
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Ilya Leoshkevich <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit c9b8a13a8841e0e23901e57e24ea98eeef16cf91)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 84fb165d967d7245d2779b3a4217a08b0c312a51
https://github.com/qemu/qemu/commit/84fb165d967d7245d2779b3a4217a08b0c312a51
Author: Ilya Leoshkevich <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/ppc/translate.c
Log Message:
-----------
target/ppc: Make divd[u] handler method decodetree compatible
This is like commit 86e6202a57b1 ("target/ppc: Make divw[u] handler
method decodetree compatible."), but for gen_op_arith_divd().
Cc: [email protected]
Suggested-by: Richard Henderson <[email protected]>
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 7b4820a3e1dfba2b81f2354e7c748fc04b275dba)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: afbd6b50773b91318067bc6633dd6d6486b93edc
https://github.com/qemu/qemu/commit/afbd6b50773b91318067bc6633dd6d6486b93edc
Author: Nicholas Piggin <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/ppc/pnv_lpc.c
M target/ppc/cpu.h
Log Message:
-----------
ppc/pnv: Fix LPC serirq routing calculation
The serirq routing table is split over two registers, the calculation
for the high irqs in the second register did not subtract the irq
offset. This was spotted by Coverity as a shift-by-negative. Fix this
and change the open-coded shifting and masking to use extract32()
function so it's less error-prone.
This went unnoticed because irqs >= 14 are not used in a standard
QEMU/OPAL boot, changing the first QEMU serial-isa irq to 14 to test
does demonstrate serial irqs aren't received, and that this change
fixes that.
Cc: [email protected]
Reported-by: Cédric Le Goater <[email protected]>
Resolves: Coverity CID 1558829 (partially)
Reviewed-by: Cédric Le Goater <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 899e488650bb8bd52e1b2b44ceaae17df2e20b7f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3583e93223fe534dce511b3b5b902b76bb136968
https://github.com/qemu/qemu/commit/3583e93223fe534dce511b3b5b902b76bb136968
Author: Nicholas Piggin <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/ppc/pnv_lpc.c
Log Message:
-----------
ppc/pnv: Fix LPC POWER8 register sanity check
POWER8 does not have the ISA IRQ -> SERIRQ routing system of later
CPUs, instead all ISA IRQs are sent to the CPU via a single PSI
interrupt. There is a sanity check in the POWER8 case to ensure the
routing bits have not been set, because that would indicate a
programming error.
Those bits were incorrectly specified because of ppc bit numbering
fun. Coverity detected this as an always-zero expression.
Cc: [email protected]
Reported-by: Cédric Le Goater <[email protected]>
Resolves: Coverity CID 1558829 (partially)
Reviewed-by: Cédric Le Goater <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 84416e262ea1218026a8567ed9ea31c16d77edea)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2a14b2f441df165c57ce4cd9bfb260a375f00519
https://github.com/qemu/qemu/commit/2a14b2f441df165c57ce4cd9bfb260a375f00519
Author: Nicholas Piggin <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/ppc/misc_helper.c
Log Message:
-----------
target/ppc: Fix mtDPDES targeting SMT siblings
A typo in the loop over SMT threads to set irq level for doorbells
when storing to DPDES meant everything was aimed at the CPU executing
the instruction.
Cc: [email protected]
Fixes: d24e80b2ae ("target/ppc: Add msgsnd/p and DPDES SMT support")
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 0324d236d2918c18a9ad4a1081b1083965a1433b)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 963bfe9c6288a3b2cb6215b889de1b8efce39d5d
https://github.com/qemu/qemu/commit/963bfe9c6288a3b2cb6215b889de1b8efce39d5d
Author: Nicholas Piggin <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M target/ppc/cpu.h
Log Message:
-----------
target/ppc: Fix HFSCR facility checks
The HFSCR defines were being encoded as bit masks, but the users
expect (and analogous FSCR defines are) bit numbers.
Cc: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 87de77f6aeba4e38d123f7541cfdae7b124f6a02)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: a16570419b4fe31dc426e3f54979b9dd92aac48e
https://github.com/qemu/qemu/commit/a16570419b4fe31dc426e3f54979b9dd92aac48e
Author: Nicholas Piggin <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/ppc/pnv_adu.c
Log Message:
-----------
ppc/pnv: ADU fix possible buffer overrun with invalid size
The ADU LPC transfer-size field is 7 bits, but the supported sizes for
LPC access via ADU appear to be 1, 2, 4, 8. The data buffer could
overrun if firmware set an invalid size field, so add checks to reject
them with a message.
Cc: [email protected]
Reported-by: Cédric Le Goater <[email protected]>
Resolves: Coverity CID 1558830
Fixes: 24bd283bccb33 ("ppc/pnv: Implement ADU access to LPC space")
Reviewed-by: Cédric Le Goater <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit ddd2a060a0da41000ddca31e329ab1d54e37fedb)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5d305310c441abe197c787703fc6496141d9d590
https://github.com/qemu/qemu/commit/5d305310c441abe197c787703fc6496141d9d590
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/ssi/pnv_spi.c
Log Message:
-----------
hw/ssi/pnv_spi: Match _xfer_buffer_free() with _xfer_buffer_new()
pnv_spi_xfer_buffer_new() allocates %payload using g_malloc0(),
and pnv_spi_xfer_buffer_write_ptr() allocates %payload->data
using g_realloc(). Use the API equivalent g_free() to release
the buffers.
Cc: [email protected]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 65f53702d2e4bd045ce16ca874469cdd1e1ef4e4)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2408ff818d79e0d5e4731fd4f86e9da9710ae8b2
https://github.com/qemu/qemu/commit/2408ff818d79e0d5e4731fd4f86e9da9710ae8b2
Author: Philippe Mathieu-Daudé <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/ssi/pnv_spi.c
Log Message:
-----------
hw/ssi/pnv_spi: Return early in transfer()
Return early to simplify next commit.
No logical change intended.
Cc: [email protected]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 3feabc18ad4d4bdc178a205b986353a54dbfcf20)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 2a5eec6dd28c87a054fe02e54844b7fb920d9ede
https://github.com/qemu/qemu/commit/2a5eec6dd28c87a054fe02e54844b7fb920d9ede
Author: Chalapathi V <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/ssi/pnv_spi.c
Log Message:
-----------
hw/ssi/pnv_spi: Fixes Coverity CID 1558831
In this commit the following coverity scan defect has been fixed
CID 1558831: Resource leaks (RESOURCE_LEAK)
Variable "rsp_payload" going out of scope leaks the storage it
points to.
Cc: [email protected]
Fixes: Coverity CID 1558831
Signed-off-by: Chalapathi V <[email protected]>
Fixes: b4cb930e40 ("hw/ssi: Extend SPI model")
[PMD: Rebased on previous commit (returning earlier)]
Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit 031324472eee57bce9bd4a0231aa9b137494d8a1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: cbfbd133469e4772bb369e130dc30195385b1e5b
https://github.com/qemu/qemu/commit/cbfbd133469e4772bb369e130dc30195385b1e5b
Author: Ilya Leoshkevich <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M tests/tcg/ppc64/Makefile.target
Log Message:
-----------
tests/tcg: Replace -mpower8-vector with -mcpu=power8
[1] deprecated -mpower8-vector, resulting in:
powerpc64-linux-gnu-gcc: warning: switch '-mpower8-vector' is no longer
supported
qemu/tests/tcg/ppc64/vsx_f2i_nan.c:4:15: error: expected ';' before 'float'
4 | typedef vector float vsx_float32_vec_t;
| ^~~~~~
Use -mcpu=power8 instead. In order to properly verify that this works,
one needs a big-endian (the minimum supported CPU for 64-bit
little-endian is power8 anyway) GCC configured with --enable-checking
(see GCC commit e154242724b0 ("[RS6000] Don't pass -many to the
assembler").
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987
Cc: [email protected]
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Acked-by: Alex Bennée <[email protected]>
Signed-off-by: Nicholas Piggin <[email protected]>
(cherry picked from commit ddf4dd46e5c31bd223f2e867f2cae43bfd41dfb9)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: e30319cddd744055757999e45512898cdf2d190c
https://github.com/qemu/qemu/commit/e30319cddd744055757999e45512898cdf2d190c
Author: Jan Luebbe <[email protected]>
Date: 2024-11-05 (Tue, 05 Nov 2024)
Changed paths:
M hw/sd/sd.c
Log Message:
-----------
hw/sd/sdcard: Fix calculation of size when using eMMC boot partitions
The sd_bootpart_offset() function calculates the *runtime* offset which
changes as the guest switches between accessing the main user data area
and the boot partitions by writing to the EXT_CSD_PART_CONFIG_ACC_MASK
bits, so it shouldn't be used to calculate the main user data area size.
Instead, subtract the boot_part_size directly (twice, as there are two
identical boot partitions defined by the eMMC spec).
Suggested-by: Cédric Le Goater <[email protected]>
Signed-off-by: Jan Luebbe <[email protected]>
Fixes: c8cb19876d3e ("hw/sd/sdcard: Support boot area in emmc image")
Tested-by: Guenter Roeck <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
(cherry picked from commit c078298301a8c72fe12da85d94372689196628bc)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: fac933cae4223fecb454b609148d417cae2ca5fd
https://github.com/qemu/qemu/commit/fac933cae4223fecb454b609148d417cae2ca5fd
Author: Sunil Nimmagadda <[email protected]>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M qga/commands-posix.c
Log Message:
-----------
qemu-ga: Fix a SIGSEGV in ga_run_command() helper
qemu-ga on a NetBSD -current VM terminates with a SIGSEGV upon receiving
'guest-set-time' command...
Core was generated by `qemu-ga'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000cd37a40 in ga_pipe_read_str (fd=fd@entry=0xffffff922a20,
str=str@entry=0xffffff922a18)
at ../qga/commands-posix.c:88
88 *str[len] = '\0';
[Current thread is 1 (process 1112)]
(gdb) bt
#0 0x000000000cd37a40 in ga_pipe_read_str (fd=fd@entry=0xffffff922a20,
str=str@entry=0xffffff922a18)
at ../qga/commands-posix.c:88
#1 0x000000000cd37b60 in ga_run_command (argv=argv@entry=0xffffff922a90,
action=action@entry=0xcda34b8 "set hardware clock to system time",
errp=errp@entry=0xffffff922a70, in_str=0x0)
at ../qga/commands-posix.c:164
#2 0x000000000cd380c4 in qmp_guest_set_time (has_time=<optimized out>,
time_ns=<optimized out>,
errp=errp@entry=0xffffff922ad0) at ../qga/commands-posix.c:304
#3 0x000000000cd253d8 in qmp_marshal_guest_set_time (args=<optimized out>,
ret=<optimized out>, errp=0xffffff922b48)
at qga/qga-qapi-commands.c:193
#4 0x000000000cd4e71c in qmp_dispatch (cmds=cmds@entry=0xcdf5b18
<ga_commands>, request=request@entry=0xf3c711a4b000,
allow_oob=allow_oob@entry=false, cur_mon=cur_mon@entry=0x0) at
../qapi/qmp-dispatch.c:220
#5 0x000000000cd36524 in process_event (opaque=0xf3c711a79000,
obj=0xf3c711a4b000, err=0x0) at ../qga/main.c:677
#6 0x000000000cd526f0 in json_message_process_token
(lexer=lexer@entry=0xf3c711a79018, input=0xf3c712072480,
type=type@entry=JSON_RCURLY, x=28, y=1) at ../qobject/json-streamer.c:99
#7 0x000000000cd93860 in json_lexer_feed_char
(lexer=lexer@entry=0xf3c711a79018, ch=125 '}', flush=flush@entry=false)
at ../qobject/json-lexer.c:313
#8 0x000000000cd93a00 in json_lexer_feed (lexer=lexer@entry=0xf3c711a79018,
buffer=buffer@entry=0xffffff922d10 "{\"execute\":\"guest-set-time\"}\n",
size=<optimized out>)
at ../qobject/json-lexer.c:350
#9 0x000000000cd5290c in json_message_parser_feed
(parser=parser@entry=0xf3c711a79000,
buffer=buffer@entry=0xffffff922d10 "{\"execute\":\"guest-set-time\"}\n",
size=<optimized out>)
at ../qobject/json-streamer.c:121
#10 0x000000000cd361fc in channel_event_cb (condition=<optimized out>,
data=0xf3c711a79000) at ../qga/main.c:703
#11 0x000000000cd3710c in ga_channel_client_event (channel=<optimized out>,
condition=<optimized out>, data=0xf3c711b2d300)
at ../qga/channel-posix.c:94
#12 0x0000f3c7120d9bec in g_main_dispatch () from /usr/pkg/lib/libglib-2.0.so.0
#13 0x0000f3c7120dd25c in g_main_context_iterate_unlocked.constprop () from
/usr/pkg/lib/libglib-2.0.so.0
#14 0x0000f3c7120ddbf0 in g_main_loop_run () from /usr/pkg/lib/libglib-2.0.so.0
#15 0x000000000cda00d8 in run_agent_once (s=0xf3c711a79000) at
../qga/main.c:1522
#16 run_agent (s=0xf3c711a79000) at ../qga/main.c:1559
#17 main (argc=<optimized out>, argv=<optimized out>) at ../qga/main.c:1671
(gdb)
The commandline options used on the host machine...
qemu-system-aarch64 \
-machine type=virt,pflash0=rom \
-m 8G \
-cpu host \
-smp 8 \
-accel hvf \
-device virtio-net-pci,netdev=unet \
-device virtio-blk-pci,drive=hd \
-drive file=netbsd.qcow2,if=none,id=hd \
-netdev user,id=unet,hostfwd=tcp::2223-:22 \
-object rng-random,filename=/dev/urandom,id=viornd0 \
-device virtio-rng-pci,rng=viornd0 \
-serial mon:stdio \
-display none \
-blockdev
node-name=rom,driver=file,filename=/opt/homebrew/Cellar/qemu/9.0.2/share/qemu/edk2-aarch64-code.fd,read-only=true
\
-chardev socket,path=/tmp/qga_netbsd.sock,server=on,wait=off,id=qga0 \
-device virtio-serial \
-device virtconsole,chardev=qga0,name=org.qemu.guest_agent.0
This patch rectifies the operator precedence while assigning the NUL
terminator.
Fixes: c3f32c13a325f1ca9a0b08c19fefe9e5cc04289d
Signed-off-by: Sunil Nimmagadda <[email protected]>
Reviewed-by: Konstantin Kostiuk <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Konstantin Kostiuk <[email protected]>
(cherry picked from commit 9cfe110d9fc0be88178770a85dc6170eecdf6be1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 7ee7418dae177bb34226baf6a66e461f55e15465
https://github.com/qemu/qemu/commit/7ee7418dae177bb34226baf6a66e461f55e15465
Author: Jonathan Cameron <[email protected]>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M hw/acpi/acpi_generic_initiator.c
Log Message:
-----------
hw/acpi: Fix ordering of BDF in Generic Initiator PCI Device Handle.
The ordering in ACPI specification [1] has bus number in the lowest byte.
As ACPI tables are little endian this is the reverse of the ordering
used by PCI_BUILD_BDF(). As a minimal fix split the QEMU BDF up
into bus and devfn and write them as single bytes in the correct
order.
[1] ACPI Spec 6.3, Table 5.80
Fixes: 0a5b5acdf2d8 ("hw/acpi: Implement the SRAT GI affinity structure")
Reviewed-by: Igor Mammedov <[email protected]>
Tested-by: "Huang, Ying" <[email protected]>
Signed-off-by: Jonathan Cameron <[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 16c687d84574a1139a6475c33e3b9191f7932ac0)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 19b80ef0b512b2a839cb714e1a3765b80ff5cb96
https://github.com/qemu/qemu/commit/19b80ef0b512b2a839cb714e1a3765b80ff5cb96
Author: Michael S. Tsirkin <[email protected]>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M tests/data/acpi/disassemle-aml.sh
Log Message:
-----------
acpi/disassemle-aml.sh: fix up after dir reorg
We moved expected files around, fix up the disassembler script.
Fixes: 7c08eefcaf ("tests/data/acpi: Move x86 ACPI tables under x86/${machine}
path")
Fixes: 7434f90467 ("tests/data/acpi/virt: Move ARM64 ACPI tables under
aarch64/${machine} path")
Cc: "Sunil V L" <[email protected]>
Message-ID:
<ce456091058734b7f765617ac5dfeebcb366d4a9.1730729695.git....@redhat.com>
Signed-off-by: Michael S. Tsirkin <[email protected]>
Acked-by: Igor Mammedov <[email protected]>
(cherry picked from commit feb58e3b261db503ade94c5f43ccedeee4eac41f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: f147ed377a80269ebd9c1c64ea72a2b3b5fede6a
https://github.com/qemu/qemu/commit/f147ed377a80269ebd9c1c64ea72a2b3b5fede6a
Author: Peter Maydell <[email protected]>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M target/arm/cpu.h
M target/arm/helper.c
M target/arm/internals.h
M target/arm/ptw.c
M target/arm/tcg/hflags.c
M target/arm/tcg/translate-a64.c
M target/arm/tcg/translate.c
M target/arm/tcg/translate.h
Log Message:
-----------
Revert "target/arm: Fix usage of MMU indexes when EL3 is AArch32"
This reverts commit 4c2c0474693229c1f533239bb983495c5427784d.
This commit tried to fix a problem with our usage of MMU indexes when
EL3 is AArch32, using what it described as a "more complicated
approach" where we share the same MMU index values for Secure PL1&0
and NonSecure PL1&0. In theory this should work, but the change
didn't account for (at least) two things:
(1) The design change means we need to flush the TLBs at any point
where the CPU state flips from one to the other. We already flush
the TLB when SCR.NS is changed, but we don't flush the TLB when we
take an exception from NS PL1&0 into Mon or when we return from Mon
to NS PL1&0, and the commit didn't add any code to do that.
(2) The ATS12NS* address translate instructions allow Mon code (which
is Secure) to do a stage 1+2 page table walk for NS. I thought this
was OK because do_ats_write() does a page table walk which doesn't
use the TLBs, so because it can pass both the MMU index and also an
ARMSecuritySpace argument we can tell the table walk that we want NS
stage1+2, not S. But that means that all the code within the ptw
that needs to find e.g. the regime EL cannot do so only with an
mmu_idx -- all these functions like regime_sctlr(), regime_el(), etc
would need to pass both an mmu_idx and the security_space, so they
can tell whether this is a translation regime controlled by EL1 or
EL3 (and so whether to look at SCTLR.S or SCTLR.NS, etc).
In particular, because regime_el() wasn't updated to look at the
ARMSecuritySpace it would return 1 even when the CPU was in Monitor
mode (and the controlling EL is 3). This meant that page table walks
in Monitor mode would look at the wrong SCTLR, TCR, etc and would
generally fault when they should not.
Rather than trying to make the complicated changes needed to rescue
the design of 4c2c04746932, we revert it in order to instead take the
route that that commit describes as "the most straightforward" fix,
where we add new MMU indexes EL30_0, EL30_3, EL30_3_PAN to correspond
to "Secure PL1&0 at PL0", "Secure PL1&0 at PL1", and "Secure PL1&0 at
PL1 with PAN".
This revert will re-expose the "spurious alignment faults in
Secure PL0" issue #2326; we'll fix it again in the next commit.
Cc: [email protected]
Signed-off-by: Peter Maydell <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Message-id: [email protected]
Reviewed-by: Richard Henderson <[email protected]>
(cherry picked from commit 056c5c90c171c4895b407af0cf3d198e1d44b40f)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 6d62f309f869c6a563fbe280c85182954df5855c
https://github.com/qemu/qemu/commit/6d62f309f869c6a563fbe280c85182954df5855c
Author: Peter Maydell <[email protected]>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M target/arm/cpu.h
M target/arm/helper.c
M target/arm/internals.h
M target/arm/ptw.c
M target/arm/tcg/op_helper.c
M target/arm/tcg/translate.c
Log Message:
-----------
target/arm: Add new MMU indexes for AArch32 Secure PL1&0
Our current usage of MMU indexes when EL3 is AArch32 is confused.
Architecturally, when EL3 is AArch32, all Secure code runs under the
Secure PL1&0 translation regime:
* code at EL3, which might be Mon, or SVC, or any of the
other privileged modes (PL1)
* code at EL0 (Secure PL0)
This is different from when EL3 is AArch64, in which case EL3 is its
own translation regime, and EL1 and EL0 (whether AArch32 or AArch64)
have their own regime.
We claimed to be mapping Secure PL1 to our ARMMMUIdx_EL3, but didn't
do anything special about Secure PL0, which meant it used the same
ARMMMUIdx_EL10_0 that NonSecure PL0 does. This resulted in a bug
where arm_sctlr() incorrectly picked the NonSecure SCTLR as the
controlling register when in Secure PL0, which meant we were
spuriously generating alignment faults because we were looking at the
wrong SCTLR control bits.
The use of ARMMMUIdx_EL3 for Secure PL1 also resulted in the bug that
we wouldn't honour the PAN bit for Secure PL1, because there's no
equivalent _PAN mmu index for it.
Fix this by adding two new MMU indexes:
* ARMMMUIdx_E30_0 is for Secure PL0
* ARMMMUIdx_E30_3_PAN is for Secure PL1 when PAN is enabled
The existing ARMMMUIdx_E3 is used to mean "Secure PL1 without PAN"
(and would be named ARMMMUIdx_E30_3 in an AArch32-centric scheme).
These extra two indexes bring us up to the maximum of 16 that the
core code can currently support.
This commit:
* adds the new MMU index handling to the various places
where we deal in MMU index values
* adds assertions that we aren't AArch32 EL3 in a couple of
places that currently use the E10 indexes, to document why
they don't also need to handle the E30 indexes
* documents in a comment why regime_has_2_ranges() doesn't need
updating
Notes for backporting: this commit depends on the preceding revert of
4c2c04746932; that revert and this commit should probably be
backported to everywhere that we originally backported 4c2c04746932.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2326
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2588
Signed-off-by: Peter Maydell <[email protected]>
Tested-by: Thomas Huth <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit efbe180ad2ed75d4cc64dfc6fb46a015eef713d1)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 5e29203bc7428d77f940d6427557a3b258e2224c
https://github.com/qemu/qemu/commit/5e29203bc7428d77f940d6427557a3b258e2224c
Author: Peter Maydell <[email protected]>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M target/arm/tcg/vec_helper.c
Log Message:
-----------
target/arm: Fix SVE SDOT/UDOT/USDOT (4-way, indexed)
Our implementation of the indexed version of SVE SDOT/UDOT/USDOT got
the calculation of the inner loop terminator wrong. Although we
correctly account for the element size when we calculate the
terminator for the first iteration:
intptr_t segend = MIN(16 / sizeof(TYPED), opr_sz_n);
we don't do that when we move it forward after the first inner loop
completes. The intention is that we process the vector in 128-bit
segments, which for a 64-bit element size should mean (1, 2), (3, 4),
(5, 6), etc. This bug meant that we would iterate (1, 2), (3, 4, 5,
6), (7, 8, 9, 10) etc and apply the wrong indexed element to some of
the operations, and also index off the end of the vector.
You don't see this bug if the vector length is small enough that we
don't need to iterate the outer loop, i.e. if it is only 128 bits,
or if it is the 64-bit special case from AA32/AA64 AdvSIMD. If the
vector length is 256 bits then we calculate the right results for the
elements in the vector but do index off the end of the vector. Vector
lengths greater than 256 bits see wrong answers. The instructions
that produce 32-bit results behave correctly.
Fix the recalculation of 'segend' for subsequent iterations, and
restore a version of the comment that was lost in the refactor of
commit 7020ffd656a5 that explains why we only need to clamp segend to
opr_sz_n for the first iteration, not the later ones.
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2595
Fixes: 7020ffd656a5 ("target/arm: Macroize helper_gvec_{s,u}dot_idx_{b,h}")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit e6b2fa1b81ac6b05c4397237c846a295a9857920)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 0098207eb1d958600b80705f3be0b2064d232178
https://github.com/qemu/qemu/commit/0098207eb1d958600b80705f3be0b2064d232178
Author: Hanna Czenczek <[email protected]>
Date: 2024-11-06 (Wed, 06 Nov 2024)
Changed paths:
M migration/vmstate.c
Log Message:
-----------
migration: Ensure vmstate_save() sets errp
migration/savevm.c contains some calls to vmstate_save() that are
followed by migrate_set_error() if the integer return value indicates an
error. migrate_set_error() requires that the `Error *` object passed to
it is set. Therefore, vmstate_save() is assumed to always set *errp on
error.
Right now, that assumption is not met: vmstate_save_state_v() (called
internally by vmstate_save()) will not set *errp if
vmstate_subsection_save() or vmsd->post_save() fail. Fix that by adding
an *errp parameter to vmstate_subsection_save(), and by generating a
generic error in case post_save() fails (as is already done for
pre_save()).
Without this patch, qemu will crash after vmstate_subsection_save() or
post_save() have failed inside of a vmstate_save() call (unless
migrate_set_error() then happen to discard the new error because
s->error is already set). This happens e.g. when receiving the state
from a virtio-fs back-end (virtiofsd) fails.
Signed-off-by: Hanna Czenczek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Peter Xu <[email protected]>
(cherry picked from commit 37dfcba1a04989830c706f9cbc00450e5d3a7447)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: c5e48f281d713eb979c5a694777609a8e1973599
https://github.com/qemu/qemu/commit/c5e48f281d713eb979c5a694777609a8e1973599
Author: Klaus Jensen <[email protected]>
Date: 2024-11-08 (Fri, 08 Nov 2024)
Changed paths:
M hw/nvme/ctrl.c
Log Message:
-----------
hw/nvme: fix handling of over-committed queues
If a host chooses to use the SQHD "hint" in the CQE to know if there is
room in the submission queue for additional commands, it may result in a
situation where there are not enough internal resources (struct
NvmeRequest) available to process the command. For a lack of a better
term, the host may "over-commit" the device (i.e., it may have more
inflight commands than the queue size).
For example, assume a queue with N entries. The host submits N commands
and all are picked up for processing, advancing the head and emptying
the queue. Regardless of which of these N commands complete first, the
SQHD field of that CQE will indicate to the host that the queue is
empty, which allows the host to issue N commands again. However, if the
device has not posted CQEs for all the previous commands yet, the device
will have less than N resources available to process the commands, so
queue processing is suspended.
And here lies an 11 year latent bug. In the absense of any additional
tail updates on the submission queue, we never schedule the processing
bottom-half again unless we observe a head update on an associated full
completion queue. This has been sufficient to handle N-to-1 SQ/CQ setups
(in the absense of over-commit of course). Incidentially, that "kick all
associated SQs" mechanism can now be killed since we now just schedule
queue processing when we return a processing resource to a non-empty
submission queue, which happens to cover both edge cases. However, we
must retain kicking the CQ if it was previously full.
So, apparently, no previous driver tested with hw/nvme has ever used
SQHD (e.g., neither the Linux NVMe driver or SPDK uses it). But then OSv
shows up with the driver that actually does. I salute you.
Fixes: f3c507adcd7b ("NVMe: Initial commit for new storage interface")
Cc: [email protected]
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2388
Reported-by: Waldemar Kozaczuk <[email protected]>
Reviewed-by: Keith Busch <[email protected]>
Signed-off-by: Klaus Jensen <[email protected]>
(cherry picked from commit 9529aa6bb4d18763f5b4704cb4198bd25cbbee31)
Signed-off-by: Michael Tokarev <[email protected]>
Commit: 3d28b84487345b669d8afba972f8b64dd3f75098
https://github.com/qemu/qemu/commit/3d28b84487345b669d8afba972f8b64dd3f75098
Author: Christian Schoenebeck <[email protected]>
Date: 2024-11-08 (Fri, 08 Nov 2024)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
9pfs: fix crash on 'Treaddir' request
A bad (broken or malicious) 9p client (guest) could cause QEMU host to
crash by sending a 9p 'Treaddir' request with a numeric file ID (FID) that
was previously opened for a file instead of an expected directory:
#0 0x0000762aff8f4919 in __GI___rewinddir (dirp=0xf) at
../sysdeps/unix/sysv/linux/rewinddir.c:29
#1 0x0000557b7625fb40 in do_readdir_many (pdu=0x557bb67d2eb0,
fidp=0x557bb67955b0, entries=0x762afe9fff58, offset=0, maxsize=131072,
dostat=<optimized out>) at ../hw/9pfs/codir.c:101
#2 v9fs_co_readdir_many (pdu=pdu@entry=0x557bb67d2eb0,
fidp=fidp@entry=0x557bb67955b0, entries=entries@entry=0x762afe9fff58,
offset=0, maxsize=131072, dostat=false) at ../hw/9pfs/codir.c:226
#3 0x0000557b7625c1f9 in v9fs_do_readdir (pdu=0x557bb67d2eb0,
fidp=0x557bb67955b0, offset=<optimized out>,
max_count=<optimized out>) at ../hw/9pfs/9p.c:2488
#4 v9fs_readdir (opaque=0x557bb67d2eb0) at ../hw/9pfs/9p.c:2602
That's because V9fsFidOpenState was declared as union type. So the
same memory region is used for either an open POSIX file handle (int),
or a POSIX DIR* pointer, etc., so 9p server incorrectly used the
previously opened (valid) POSIX file handle (0xf) as DIR* pointer,
eventually causing a crash in glibc's rewinddir() function.
Root cause was therefore a missing check in 9p server's 'Treaddir'
request handler, which must ensure that the client supplied FID was
really opened as directory stream before trying to access the
aforementioned union and its DIR* member.
Cc: [email protected]
Fixes: d62dbb51f7 ("virtio-9p: Add fidtype so that we can do type ...")
Reported-by: Akihiro Suda <[email protected]>
Tested-by: Akihiro Suda <[email protected]>
Signed-off-by: Christian Schoenebeck <[email protected]>
Reviewed-by: Greg Kurz <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 042b4ebfd2298ae01553844124f27d651cdb1071)
Signed-off-by: Michael Tokarev <[email protected]>
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]>
Commit: 508081a49b0d624930ca479b8a27bccdc50bdfb2
https://github.com/qemu/qemu/commit/508081a49b0d624930ca479b8a27bccdc50bdfb2
Author: Michael Tokarev <[email protected]>
Date: 2024-11-21 (Thu, 21 Nov 2024)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 9.1.2 release
Signed-off-by: Michael Tokarev <[email protected]>
Compare: https://github.com/qemu/qemu/compare/0ff5ab6f57a2...508081a49b0d
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
