[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] bc5014: tests: Wait for migration completion
|
From: |
Guenter Roeck |
|
Subject: |
[Qemu-commits] [qemu/qemu] bc5014: tests: Wait for migration completion on destinatio... |
|
Date: |
Mon, 18 Nov 2024 10:19:49 -0800 |
Branch: refs/heads/staging-8.2
Home: https://github.com/qemu/qemu
Commit: bc5014cde5d0d070242b635fd11af5902cd879ea
https://github.com/qemu/qemu/commit/bc5014cde5d0d070242b635fd11af5902cd879ea
Author: Stefan Berger <stefanb@linux.ibm.com>
Date: 2024-11-10 (Sun, 10 Nov 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: <qemu-stable@nongnu.org>
Reported-by: Fabiano Rosas <farosas@suse.de>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
(cherry picked from commit d9280ea3174700170d39c4cdd3f587f260757711)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e73e8d9bcb13ea78ca810a52f65d4d47c05da95d
https://github.com/qemu/qemu/commit/e73e8d9bcb13ea78ca810a52f65d4d47c05da95d
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2024-11-10 (Sun, 10 Nov 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: qemu-stable@nongnu.org
Fixes: 52b10c9c0c68e90f ("qemu-img: map: report compressed data blocks")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20241008164708.2966400-4-peter.maydell@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit d60bd080e783107cb876a6f16561fe03f9dcbca7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: ca45c06b006310b3d7bf5d0690e0db95f9a7ccde
https://github.com/qemu/qemu/commit/ca45c06b006310b3d7bf5d0690e0db95f9a7ccde
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2024-11-10 (Sun, 10 Nov 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 <kwolf@redhat.com>
Message-ID: <20240829185527.47152-1-kwolf@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 04bbc3ee52b32ac465547bb40c1f090a1b8f315a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c042070bbf0ac1b3024f758d43f4519920811673
https://github.com/qemu/qemu/commit/c042070bbf0ac1b3024f758d43f4519920811673
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2024-11-10 (Sun, 10 Nov 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: qemu-stable@nongnu.org
Fixes: 57a269469db ("tcg: Infrastructure for managing constant pools")
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit a7cfd751fb269de4a93bf1658cb13911c7ac77cc)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 253c0a06e030739057a902aac89413992ac5e409
https://github.com/qemu/qemu/commit/253c0a06e030739057a902aac89413992ac5e409
Author: Alexander Graf <graf@amazon.com>
Date: 2024-11-10 (Sun, 10 Nov 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: qemu-stable@nongnu.org
Fixes: fe441054bb3f0 ("target-i386: Add NPT support")
Signed-off-by: Alexander Graf <graf@amazon.com>
Reported-by: Eduard Vlad <evlad@amazon.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240921085712.28902-1-graf@amazon.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit b56617bbcb473c25815d1bf475e326f84563b1de)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9a96406787afcc9960fbe8791892c78311d6971f
https://github.com/qemu/qemu/commit/9a96406787afcc9960fbe8791892c78311d6971f
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2024-11-10 (Sun, 10 Nov 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: qemu-stable@nongnu.org
Fixes: 6d03226b422 ("plugins: force slow path when plugins instrument memory
ops")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20241013184733.1423747-3-richard.henderson@linaro.org>
(cherry picked from commit 115ade42d50144c15b74368d32dc734ea277d853)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: dad762774e9ac5a19f3e2d3875cdd63f529dcf03
https://github.com/qemu/qemu/commit/dad762774e9ac5a19f3e2d3875cdd63f529dcf03
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2024-11-10 (Sun, 10 Nov 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: qemu-stable@nongnu.org
Fixes: 7b7a3366e142 ("linux-user: Use walk_memory_regions for open_self_maps")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20241014203441.387560-1-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit bbd5630a75e70a0f1bcf04de74c94aa94a145628)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix in linux-user/syscall.c due to missing
v9.0.0-421-g59272469bd13
"user: Use get_task_state() helper")
Commit: 7ab3aff995d991c7601da269bb40d4a43efbd362
https://github.com/qemu/qemu/commit/7ab3aff995d991c7601da269bb40d4a43efbd362
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2024-11-10 (Sun, 10 Nov 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 <iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241017125811.447961-2-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 8704132805cf7a3259d1c5a073b3c2b92afa2616)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: fd5ec4709d418c3d7fac4e4e1c7358917459dc98
https://github.com/qemu/qemu/commit/fd5ec4709d418c3d7fac4e4e1c7358917459dc98
Author: Avihai Horon <avihaih@nvidia.com>
Date: 2024-11-10 (Sun, 10 Nov 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 <avihaih@nvidia.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 3b5948f808e3b99aedfa0aff45cffbe8b7ec07ed)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 8017ac63d36f62f89239e33893f2410a18790fc7
https://github.com/qemu/qemu/commit/8017ac63d36f62f89239e33893f2410a18790fc7
Author: Alex Bennée <alex.bennee@linaro.org>
Date: 2024-11-10 (Sun, 10 Nov 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é <berrange@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20241023113406.1284676-11-alex.bennee@linaro.org>
(cherry picked from commit 97f116f9c6fd127b6ed2953993fa9fb05e82f450)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: a15d41ac2e13239c5d302806763a61cc2d5589fa
https://github.com/qemu/qemu/commit/a15d41ac2e13239c5d302806763a61cc2d5589fa
Author: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Date: 2024-11-10 (Sun, 10 Nov 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 <pierrick.bouvier@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20241020213759.2168248-1-pierrick.bouvier@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20241023113406.1284676-10-alex.bennee@linaro.org>
(cherry picked from commit 24be5341fbeea341cca38b59d4c0928a8cf5fac1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 01f9d3553dc9bd56b5ba420d380221626eff2a7c
https://github.com/qemu/qemu/commit/01f9d3553dc9bd56b5ba420d380221626eff2a7c
Author: Stefan Weil <sw@weilnetz.de>
Date: 2024-11-10 (Sun, 10 Nov 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 <sw@weilnetz.de>
Cc: qemu-stable@nongnu.org
Reviewed-by: Zhang Chen <chen.zhang@intel.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit e29bc931e1699a98959680f6776b48673825762b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 719229d56404e7a60432f1d76d17fd9e44c5e34e
https://github.com/qemu/qemu/commit/719229d56404e7a60432f1d76d17fd9e44c5e34e
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2024-11-10 (Sun, 10 Nov 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é <berrange@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 1f37280b37dbf85f36748f359a9f8802c8fe7ccd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: f18960409ae442f99b2aaeb793a1d11791b43227
https://github.com/qemu/qemu/commit/f18960409ae442f99b2aaeb793a1d11791b43227
Author: Bernhard Beschow <shentey@gmail.com>
Date: 2024-11-10 (Sun, 10 Nov 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 <shentey@gmail.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2607
Cc: qemu-stable@nongnu.org
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 75fe36b4e8a994cdf9fd6eb601f49e96b1bc791d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9f4fe6710548ff265c1366465bae0d5a545b6778
https://github.com/qemu/qemu/commit/9f4fe6710548ff265c1366465bae0d5a545b6778
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2024-11-10 (Sun, 10 Nov 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: qemu-stable@nongnu.org
Fixes: e4c93e44ab103f ("target/arm: Implement FEAT_E0PD")
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20241017172331.822587-1-peter.maydell@linaro.org
(cherry picked from commit 1505b651fdbd9af59a4a90876a62ae7ea2d4cd39)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0c826be9969433abb6045240d17eb031c755bf24
https://github.com/qemu/qemu/commit/0c826be9969433abb6045240d17eb031c755bf24
Author: Ido Plat <ido.plat1@ibm.com>
Date: 2024-11-10 (Sun, 10 Nov 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: qemu-stable@nongnu.org
Fixes: 0e92818887dee ("target/arm: Implement the SET* instructions")
Signed-off-by: Ido Plat <ido.plat1@ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241025024909.799989-1-ido.plat1@ibm.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit bab209af35037b33f7eb1b8a3737085935bec3a3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 5e0f5840b9a3964a890cb84b217ecf1478a67fed
https://github.com/qemu/qemu/commit/5e0f5840b9a3964a890cb84b217ecf1478a67fed
Author: Evgenii Prokopiev <evgenii.prokopiev@syntacore.com>
Date: 2024-11-10 (Sun, 10 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 <evgenii.prokopiev@syntacore.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241002084436.89347-1-evgenii.prokopiev@syntacore.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 5a60026cad4e9dba929cab4f63229e4b9110cf0a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 2c7193876cf14c3ccb1f230d8853bd666908afd6
https://github.com/qemu/qemu/commit/2c7193876cf14c3ccb1f230d8853bd666908afd6
Author: TANG Tiancheng <tangtiancheng.ttc@alibaba-inc.com>
Date: 2024-11-10 (Sun, 10 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 <tangtiancheng.ttc@alibaba-inc.com>
Fixes: 05e6ca5e156 ("target/riscv: Ignore reserved bits in PTE for RV64")
Reviewed-by: Liu Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240919055048.562-4-zhiwei_liu@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 929e4277c128772bad41cc795995f754cb9991af)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0ff28bf039cd86d121892a0379f2406ce2b92dc0
https://github.com/qemu/qemu/commit/0ff28bf039cd86d121892a0379f2406ce2b92dc0
Author: Sergey Makarov <s.makarov@syntacore.com>
Date: 2024-11-10 (Sun, 10 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 <s.makarov@syntacore.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20240918140229.124329-3-s.makarov@syntacore.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit a84be2baa9eca8bc500f866ad943b8f63dc99adf)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9ed225f1baf7533cd701b4d8518ffb5c531ccaaa
https://github.com/qemu/qemu/commit/9ed225f1baf7533cd701b4d8518ffb5c531ccaaa
Author: Rob Bradford <rbradford@rivosinc.com>
Date: 2024-11-10 (Sun, 10 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 <rbradford@rivosinc.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240930165258.72258-1-rbradford@rivosinc.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit f8c1f36a2e3dab4935e7c5690e578ac71765766b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 54e5df724e08abb55b64ebc146dd47d0379ed406
https://github.com/qemu/qemu/commit/54e5df724e08abb55b64ebc146dd47d0379ed406
Author: Anup Patel <apatel@ventanamicro.com>
Date: 2024-11-10 (Sun, 10 Nov 2024)
Changed paths:
M hw/intc/riscv_aplic.c
Log Message:
-----------
hw/intc/riscv_aplic: Fix in_clrip[x] read emulation
The reads to in_clrip[x] registers return rectified input values of the
interrupt sources.
A rectified input value of an interrupt source is defined by the section
"4.5.2 Source configurations (sourcecfg[1]–sourcecfg[1023])" of the RISC-V
AIA specification as:
"rectified input value = (incoming wire value) XOR (source is inverted)"
Update the riscv_aplic_read_input_word() implementation to match the above.
Fixes: e8f79343cfc8 ("hw/intc: Add RISC-V AIA APLIC device emulation")
Signed-off-by: Anup Patel <apatel@ventanamicro.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Message-ID: <20240306095722.463296-3-apatel@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 0678e9f29c2301d0a1afc8d01a78cdfa7ad2ddbd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: d29ab85dacb8fbcf350cf518c377af6af6d1f5b6
https://github.com/qemu/qemu/commit/d29ab85dacb8fbcf350cf518c377af6af6d1f5b6
Author: Yong-Xuan Wang <yongxuan.wang@sifive.com>
Date: 2024-11-10 (Sun, 10 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 <yongxuan.wang@sifive.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241004104649.13129-1-yongxuan.wang@sifive.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 2ae6cca1d3389801ee72fc5e58c52573218f3514)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: ebb544a0327815bb118ef3d01d124137a8887481
https://github.com/qemu/qemu/commit/ebb544a0327815bb118ef3d01d124137a8887481
Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Date: 2024-11-10 (Sun, 10 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 <dbarboza@ventanamicro.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241028182037.290171-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit d201a127e164b1683df5e7c93c6d42a74122db99)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0125fae2fe60919f15ccb9d898eb0b1cc85a65cf
https://github.com/qemu/qemu/commit/0125fae2fe60919f15ccb9d898eb0b1cc85a65cf
Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Date: 2024-11-10 (Sun, 10 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 <dbarboza@ventanamicro.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241028182037.290171-3-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit fd16cfb2995e9196b579d8885145c4247dfa6058)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 325bda0afd1cae18614edbdf587995f98b14d3d6
https://github.com/qemu/qemu/commit/325bda0afd1cae18614edbdf587995f98b14d3d6
Author: Anton Blanchard <antonb@tenstorrent.com>
Date: 2024-11-10 (Sun, 10 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 <antonb@tenstorrent.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20241030043538.939712-1-antonb@tenstorrent.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit c128d39edeff337220fc536a3e935bcba01ecb49)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 1950253213b2c4ccce5265d3eed19801222e27ae
https://github.com/qemu/qemu/commit/1950253213b2c4ccce5265d3eed19801222e27ae
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2024-11-10 (Sun, 10 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: qemu-stable@nongnu.org
Fixes: 99082815f17f ("target/ppc: Add infrastructure for prefixed insns")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit c9b8a13a8841e0e23901e57e24ea98eeef16cf91)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: a0f6b02792a3332c6d108f6eef002b97e30e4ab5
https://github.com/qemu/qemu/commit/a0f6b02792a3332c6d108f6eef002b97e30e4ab5
Author: Nicholas Piggin <npiggin@gmail.com>
Date: 2024-11-10 (Sun, 10 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: qemu-stable@nongnu.org
Fixes: d24e80b2ae ("target/ppc: Add msgsnd/p and DPDES SMT support")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
(cherry picked from commit 0324d236d2918c18a9ad4a1081b1083965a1433b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9482f989cc30bb34558285564a19bdaea0cf86cf
https://github.com/qemu/qemu/commit/9482f989cc30bb34558285564a19bdaea0cf86cf
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2024-11-10 (Sun, 10 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: qemu-stable@nongnu.org
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 <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20241101185544.2130972-1-peter.maydell@linaro.org
(cherry picked from commit e6b2fa1b81ac6b05c4397237c846a295a9857920)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 15c1530270875b1c4034071c5c7b6ad512572280
https://github.com/qemu/qemu/commit/15c1530270875b1c4034071c5c7b6ad512572280
Author: Hanna Czenczek <hreitz@redhat.com>
Date: 2024-11-10 (Sun, 10 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 <hreitz@redhat.com>
Link: https://lore.kernel.org/r/20241015170437.310358-1-hreitz@redhat.com
Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 37dfcba1a04989830c706f9cbc00450e5d3a7447)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e3d2027be7197878b222a1598cc47aa8867be51a
https://github.com/qemu/qemu/commit/e3d2027be7197878b222a1598cc47aa8867be51a
Author: Klaus Jensen <k.jensen@samsung.com>
Date: 2024-11-10 (Sun, 10 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: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2388
Reported-by: Waldemar Kozaczuk <jwkozaczuk@gmail.com>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit 9529aa6bb4d18763f5b4704cb4198bd25cbbee31)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: b08f9df32cba45213a8bd39da43fd46d0c132609
https://github.com/qemu/qemu/commit/b08f9df32cba45213a8bd39da43fd46d0c132609
Author: Christian Schoenebeck <qemu_oss@crudebyte.com>
Date: 2024-11-10 (Sun, 10 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: qemu-stable@nongnu.org
Fixes: d62dbb51f7 ("virtio-9p: Add fidtype so that we can do type ...")
Reported-by: Akihiro Suda <suda.kyoto@gmail.com>
Tested-by: Akihiro Suda <suda.kyoto@gmail.com>
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <E1t8GnN-002RS8-E2@kylie.crudebyte.com>
(cherry picked from commit 042b4ebfd2298ae01553844124f27d651cdb1071)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 363d385dbff091e2dac0211b7dfce048cb52fada
https://github.com/qemu/qemu/commit/363d385dbff091e2dac0211b7dfce048cb52fada
Author: Alexander Graf <graf@amazon.com>
Date: 2024-11-13 (Wed, 13 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: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2654
Fixes: b56617bbcb4 ("target/i386: Walk NPT in guest real mode")
Fixes: 253c0a06e03 (commit b56617bbcb4 in stable-8.2.x series)
Signed-off-by: Alexander Graf <graf@amazon.com>
Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Link: https://lore.kernel.org/r/20241106154329.67218-1-graf@amazon.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 8fa11a4df344f58375eb26b3b65004345f21ef37)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 3dc3a04fb1e542623c0de28813ac4994e477f139
https://github.com/qemu/qemu/commit/3dc3a04fb1e542623c0de28813ac4994e477f139
Author: Helge Deller <deller@kernel.org>
Date: 2024-11-17 (Sun, 17 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: qemu-stable@nongnu.org
Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-ID: <Zyo2jMKqq8hG8Pkz@p100>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 8491026a08b417b2d4070f7c373dcb43134c5312)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 7db4f0c07492a4c230862be8fd0d5faa02d8c5c7
https://github.com/qemu/qemu/commit/7db4f0c07492a4c230862be8fd0d5faa02d8c5c7
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2024-11-17 (Sun, 17 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: qemu-stable@nongnu.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20241112141232.321354-1-richard.henderson@linaro.org>
(cherry picked from commit f27550804688da43c6e0d87b2f9e143adbf76271)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 482edc6de5611415a7f58ec84867ed0f969b8f37
https://github.com/qemu/qemu/commit/482edc6de5611415a7f58ec84867ed0f969b8f37
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2024-11-17 (Sun, 17 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: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2647
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: 20241111145002.144995-1-richard.henderson@linaro.org
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
(cherry picked from commit 2a339fee450638b512c5122281cb5ab49331cfb8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 44602592d23d6a3c2ee84ae6dcbf4dd876546dca
https://github.com/qemu/qemu/commit/44602592d23d6a3c2ee84ae6dcbf4dd876546dca
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2024-11-17 (Sun, 17 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: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2598
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-ID: <20241023002558.34589-1-iii@linux.ibm.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit fb7f3572b111ffb6c2dd2c7f6c5b4dc57dd8a3f5)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 33afee2f2ff85d163e599efb0ba941a9bbfc3c05
https://github.com/qemu/qemu/commit/33afee2f2ff85d163e599efb0ba941a9bbfc3c05
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2024-11-17 (Sun, 17 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é <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit f7150b2151398c9274686d06c2c1e24618aa4cd6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: a9a949b2704d58b9fb9f228ad3cca85d4316b5a6
https://github.com/qemu/qemu/commit/a9a949b2704d58b9fb9f228ad3cca85d4316b5a6
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2024-11-17 (Sun, 17 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é <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 95c9e2209cc09453cfd49e91321df254ccbf466f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 35df60caaddc140a6bf8cb97a9e18e5526969ebc
https://github.com/qemu/qemu/commit/35df60caaddc140a6bf8cb97a9e18e5526969ebc
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2024-11-17 (Sun, 17 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: qemu-stable@nongnu.org
Fixes: db432672dc50e ("tcg: Add generic vector expanders")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2601
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20241115172515.1229393-1-peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 8377e3fb854d126ba10e61cb6b60885af8443ad4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 16942fe5fd64c7a2acdc0d722872eb26bc44a267
https://github.com/qemu/qemu/commit/16942fe5fd64c7a2acdc0d722872eb26bc44a267
Author: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Date: 2024-11-17 (Sun, 17 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/9a96406787afcc9960fbe8791892c78311d6971f
in 8.2.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 <pierrick.bouvier@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20241025175857.2554252-2-pierrick.bouvier@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 7ba055b49b74c4d2f4a338c5198485bdff373fb1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: mention [2] in 8.2.x series)
Commit: 391c3f8888fdd69901b3f19fd3723ebbfc1cb407
https://github.com/qemu/qemu/commit/391c3f8888fdd69901b3f19fd3723ebbfc1cb407
Author: Alex Bennée <alex.bennee@linaro.org>
Date: 2024-11-18 (Mon, 18 Nov 2024)
Changed paths:
M contrib/plugins/lockstep.c
Log Message:
-----------
contrib/plugins: add compat for g_memdup2
We were premature if bumping this because some of our builds are still
on older glibs. Just copy the compat handler for now and we can remove
it later.
Fixes: ee293103b0 (plugins: update lockstep to use g_memdup2)
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2161
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20240729144414.830369-14-alex.bennee@linaro.org>
(cherry picked from commit 44e794896759236885f6d30d1f6b9b8b76355d52)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2681 in 8.2.x
Commit: 8a8a0e89805bd2f64a12f63a50997d49530eedfd
https://github.com/qemu/qemu/commit/8a8a0e89805bd2f64a12f63a50997d49530eedfd
Author: Thomas Huth <thuth@redhat.com>
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 <thuth@redhat.com>
Fixes: 51f233ec92 ("misc: introduce new mos6522 VIA device")
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-ID: <20241114104653.963812-1-thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit c3d7c18b0d616cf7fb3c1f325503e1462307209d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: fe6e7a8b22759ecdfb85d542fe4ce07ec452f3e0
https://github.com/qemu/qemu/commit/fe6e7a8b22759ecdfb85d542fe4ce07ec452f3e0
Author: Paolo Bonzini <pbonzini@redhat.com>
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: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-ID: <20241114125318.1707590-3-pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 626b39006d2f9b1378a04cb88a2187bb852cb055)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 78da6504d520406312823bfc0382a8e9f9f858d4
https://github.com/qemu/qemu/commit/78da6504d520406312823bfc0382a8e9f9f858d4
Author: Guenter Roeck <linux@roeck-us.net>
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 <linux@roeck-us.net>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20241112170152.217664-11-linux@roeck-us.net>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit b2cc69997924b651c0c6f4037782e25f2e438715)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/64813c90cbbf...78da6504d520
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] bc5014: tests: Wait for migration completion on destinatio...,
Guenter Roeck <=