[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] e347aa: s390x/tcg: Fix LDER instruction forma
|
From: |
Alex Bennée |
|
Subject: |
[Qemu-commits] [qemu/qemu] e347aa: s390x/tcg: Fix LDER instruction format |
|
Date: |
Fri, 19 May 2023 21:57:13 -0700 |
Branch: refs/heads/staging-8.0
Home: https://github.com/qemu/qemu
Commit: e347aa89dd516db439c1f0b7b525eda5fb4507f9
https://github.com/qemu/qemu/commit/e347aa89dd516db439c1f0b7b525eda5fb4507f9
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: 2023-05-17 (Wed, 17 May 2023)
Changed paths:
M target/s390x/tcg/insn-data.h.inc
Log Message:
-----------
s390x/tcg: Fix LDER instruction format
It's RRE, not RXE.
Found by running valgrind's none/tests/s390x/bfp-2.
Fixes: 86b59624c4aa ("s390x/tcg: Implement LOAD LENGTHENED short HFP to long
HFP")
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Message-Id: <20230511134726.469651-1-iii@linux.ibm.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 970641de01908dd09b569965e78f13842e5854bc)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 117f33c9a76791f436624ef21c2562c928b4c86f
https://github.com/qemu/qemu/commit/117f33c9a76791f436624ef21c2562c928b4c86f
Author: Jason Andryuk <jandryuk@gmail.com>
Date: 2023-05-17 (Wed, 17 May 2023)
Changed paths:
M hw/9pfs/trace-events
M hw/9pfs/xen-9p-backend.c
Log Message:
-----------
9pfs/xen: Fix segfault on shutdown
xen_9pfs_free can't use gnttabdev since it is already closed and NULL-ed
out when free is called. Do the teardown in _disconnect(). This
matches the setup done in _connect().
trace-events are also added for the XenDevOps functions.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Message-Id: <20230502143722.15613-1-jandryuk@gmail.com>
[C.S.: - Remove redundant return in xen_9pfs_free().
- Add comment to trace-events. ]
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
(cherry picked from commit 92e667f6fd5806a6a705a2a43e572bd9ec6819da)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 36cd9bc8e2817dd5ae9cc7c427ec3a822eb1169d
https://github.com/qemu/qemu/commit/36cd9bc8e2817dd5ae9cc7c427ec3a822eb1169d
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-05-17 (Wed, 17 May 2023)
Changed paths:
M tcg/i386/tcg-target.c.inc
Log Message:
-----------
tcg/i386: Set P_REXW in tcg_out_addi_ptr
The REXW bit must be set to produce a 64-bit pointer result; the
bit is disabled in 32-bit mode, so we can do this unconditionally.
Fixes: 7d9e1ee424b0 ("tcg/i386: Adjust assert in tcg_out_addi_ptr")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1592
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1642
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 988998503bc6d8c03fbea001a0513e8372fddf28)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 21b54a683d14c0c6f9af35536d9059c60b7449ca
https://github.com/qemu/qemu/commit/21b54a683d14c0c6f9af35536d9059c60b7449ca
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
Date: 2023-05-17 (Wed, 17 May 2023)
Changed paths:
M hw/s390x/pv.c
M hw/s390x/s390-virtio-ccw.c
M include/hw/s390x/pv.h
Log Message:
-----------
s390x/pv: Fix spurious warning with asynchronous teardown
Kernel commit 292a7d6fca33 ("KVM: s390: pv: fix asynchronous teardown
for small VMs") causes the KVM_PV_ASYNC_CLEANUP_PREPARE ioctl to fail
if the VM is not larger than 2GiB. QEMU would attempt it and fail,
print an error message, and then proceed with a normal teardown.
Avoid attempting to use asynchronous teardown altogether when the VM is
not larger than 2 GiB. This will avoid triggering the error message and
also avoid pointless overhead; normal teardown is fast enough for small
VMs.
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Fixes: c3a073c610 ("s390x/pv: Add support for asynchronous teardown for reboot")
Link: https://lore.kernel.org/all/20230421085036.52511-2-imbrenda@linux.ibm.com/
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20230510105531.30623-2-imbrenda@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
[thuth: Fix inline function parameter in pv.h]
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 88693ab2a53f2f3d25cb39a7b5034ab391bc5a81)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 8ad637881f6ddf404bd554e149450a98ba8f5446
https://github.com/qemu/qemu/commit/8ad637881f6ddf404bd554e149450a98ba8f5446
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
Date: 2023-05-17 (Wed, 17 May 2023)
Changed paths:
M docs/about/deprecated.rst
M os-posix.c
M qemu-options.hx
M util/async-teardown.c
Log Message:
-----------
util/async-teardown: wire up query-command-line-options
Add new -run-with option with an async-teardown=on|off parameter. It is
visible in the output of query-command-line-options QMP command, so it
can be discovered and used by libvirt.
The option -async-teardown is now redundant, deprecate it.
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Fixes: c891c24b1a ("os-posix: asynchronous teardown for shutdown on Linux")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Message-Id: <20230505120051.36605-2-imbrenda@linux.ibm.com>
[thuth: Add curly braces to fix error with GCC 8.5, fix bug in deprecated.rst]
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 80bd81cadd127c1e2fc784612a52abe392670ba4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context tweak in docs/about/deprecated.rst)
Commit: eb82a80f512a15d3fec3cb3ffb2e0b93e3bc5b5f
https://github.com/qemu/qemu/commit/eb82a80f512a15d3fec3cb3ffb2e0b93e3bc5b5f
Author: Lizhi Yang <sledgeh4w@gmail.com>
Date: 2023-05-17 (Wed, 17 May 2023)
Changed paths:
M docs/about/emulation.rst
Log Message:
-----------
docs/about/emulation: fix typo
Duplicated word "are".
Signed-off-by: Lizhi Yang <sledgeh4w@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230511080119.99018-1-sledgeh4w@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit c70bb9a771d467302d1c7df5c5bd56b48f42716e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0b1b5a420428c24b106b97c454125ac7e346bca2
https://github.com/qemu/qemu/commit/0b1b5a420428c24b106b97c454125ac7e346bca2
Author: Alex Bennée <alex.bennee@linaro.org>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M tests/docker/dockerfiles/debian-xtensa-cross.docker
Log Message:
-----------
tests/docker: bump the xtensa base to debian:11-slim
Stretch is going out of support so things like security updates will
fail. As the toolchain itself is binary it hopefully won't mind the
underlying OS being updated.
Message-Id: <20230503091244.1450613-3-alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reported-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 3217b84f3cd813a7daffc64b26543c313f3a042a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 69a6ea7c4bd2696b21b1644c40370c654a324c42
https://github.com/qemu/qemu/commit/69a6ea7c4bd2696b21b1644c40370c654a324c42
Author: Daniil Kovalev <dkovalev@compiler-toolchain-for.me>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M linux-user/mips/cpu_loop.c
Log Message:
-----------
linux-user: Fix mips fp64 executables loading
If a program requires fr1, we should set the FR bit of CP0 control status
register and add F64 hardware flag. The corresponding `else if` branch
statement is copied from the linux kernel sources (see `arch_check_elf` function
in linux/arch/mips/kernel/elf.c).
Signed-off-by: Daniil Kovalev <dkovalev@compiler-toolchain-for.me>
Reviewed-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Message-Id: <20230404052153.16617-1-dkovalev@compiler-toolchain-for.me>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
(cherry picked from commit a0f8d2701b205d9d7986aa555e0566b13dc18fa0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 45a67df841d0d67b466fdb31a63f57d934444b5e
https://github.com/qemu/qemu/commit/45a67df841d0d67b466fdb31a63f57d934444b5e
Author: Michael Tokarev <mjt@tls.msk.ru>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: fix getgroups/setgroups allocations
linux-user getgroups(), setgroups(), getgroups32() and setgroups32()
used alloca() to allocate grouplist arrays, with unchecked gidsetsize
coming from the "guest". With NGROUPS_MAX being 65536 (linux, and it
is common for an application to allocate NGROUPS_MAX for getgroups()),
this means a typical allocation is half the megabyte on the stack.
Which just overflows stack, which leads to immediate SIGSEGV in actual
system getgroups() implementation.
An example of such issue is aptitude, eg
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811087#72
Cap gidsetsize to NGROUPS_MAX (return EINVAL if it is larger than that),
and use heap allocation for grouplist instead of alloca(). While at it,
fix coding style and make all 4 implementations identical.
Try to not impose random limits - for example, allow gidsetsize to be
negative for getgroups() - just do not allocate negative-sized grouplist
in this case but still do actual getgroups() call. But do not allow
negative gidsetsize for setgroups() since its argument is unsigned.
Capping by NGROUPS_MAX seems a bit arbitrary, - we can do more, it is
not an error if set size will be NGROUPS_MAX+1. But we should not allow
integer overflow for the array being allocated. Maybe it is enough to
just call g_try_new() and return ENOMEM if it fails.
Maybe there's also no need to convert setgroups() since this one is
usually smaller and known beforehand (KERN_NGROUPS_MAX is actually 63, -
this is apparently a kernel-imposed limit for runtime group set).
The patch fixes aptitude segfault mentioned above.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Message-Id: <20230409105327.1273372-1-mjt@msgid.tls.msk.ru>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
(cherry picked from commit 1e35d327890bdd117a67f79c52e637fb12bb1bf4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: cb898262a455a65e55c3b2821b26b7e93929c74d
https://github.com/qemu/qemu/commit/cb898262a455a65e55c3b2821b26b7e93929c74d
Author: Eric Blake <eblake@redhat.com>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Handle block device inactivation failures better
Consider what happens when performing a migration between two host
machines connected to an NFS server serving multiple block devices to
the guest, when the NFS server becomes unavailable. The migration
attempts to inactivate all block devices on the source (a necessary
step before the destination can take over); but if the NFS server is
non-responsive, the attempt to inactivate can itself fail. When that
happens, the destination fails to get the migrated guest (good,
because the source wasn't able to flush everything properly):
(qemu) qemu-kvm: load of migration failed: Input/output error
at which point, our only hope for the guest is for the source to take
back control. With the current code base, the host outputs a message, but then
appears to resume:
(qemu) qemu-kvm: qemu_savevm_state_complete_precopy_non_iterable:
bdrv_inactivate_all() failed (-1)
(src qemu)info status
VM status: running
but a second migration attempt now asserts:
(src qemu) qemu-kvm: ../block.c:6738: int
bdrv_inactivate_recurse(BlockDriverState *): Assertion `!(bs->open_flags &
BDRV_O_INACTIVE)' failed.
Whether the guest is recoverable on the source after the first failure
is debatable, but what we do not want is to have qemu itself fail due
to an assertion. It looks like the problem is as follows:
In migration.c:migration_completion(), the source sets 'inactivate' to
true (since COLO is not enabled), then tries
savevm.c:qemu_savevm_state_complete_precopy() with a request to
inactivate block devices. In turn, this calls
block.c:bdrv_inactivate_all(), which fails when flushing runs up
against the non-responsive NFS server. With savevm failing, we are
now left in a state where some, but not all, of the block devices have
been inactivated; but migration_completion() then jumps to 'fail'
rather than 'fail_invalidate' and skips an attempt to reclaim those
those disks by calling bdrv_activate_all(). Even if we do attempt to
reclaim disks, we aren't taking note of failure there, either.
Thus, we have reached a state where the migration engine has forgotten
all state about whether a block device is inactive, because we did not
set s->block_inactive in enough places; so migration allows the source
to reach vm_start() and resume execution, violating the block layer
invariant that the guest CPUs should not be restarted while a device
is inactive. Note that the code in migration.c:migrate_fd_cancel()
will also try to reactivate all block devices if s->block_inactive was
set, but because we failed to set that flag after the first failure,
the source assumes it has reclaimed all devices, even though it still
has remaining inactivated devices and does not try again. Normally,
qmp_cont() will also try to reactivate all disks (or correctly fail if
the disks are not reclaimable because NFS is not yet back up), but the
auto-resumption of the source after a migration failure does not go
through qmp_cont(). And because we have left the block layer in an
inconsistent state with devices still inactivated, the later migration
attempt is hitting the assertion failure.
Since it is important to not resume the source with inactive disks,
this patch marks s->block_inactive before attempting inactivation,
rather than after succeeding, in order to prevent any vm_start() until
it has successfully reactivated all devices.
See also https://bugzilla.redhat.com/show_bug.cgi?id=2058982
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Lukas Straub <lukasstraub2@web.de>
Tested-by: Lukas Straub <lukasstraub2@web.de>
Signed-off-by: Juan Quintela <quintela@redhat.com>
(cherry picked from commit 403d18ae384239876764bbfa111d6cc5dcb673d1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: d2a811dd7d95e3c35271edad066504d76e83dea4
https://github.com/qemu/qemu/commit/d2a811dd7d95e3c35271edad066504d76e83dea4
Author: Eric Blake <eblake@redhat.com>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Minor control flow simplification
No need to declare a temporary variable.
Suggested-by: Juan Quintela <quintela@redhat.com>
Fixes: 1df36e8c6289 ("migration: Handle block device inactivation failures
better")
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
(cherry picked from commit 5d39f44d7ac5c63f53d4d0900ceba9521bc27e49)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c0ad2a91914751819ddbf49d19043f9cbcbe2651
https://github.com/qemu/qemu/commit/c0ad2a91914751819ddbf49d19043f9cbcbe2651
Author: Eric Blake <eblake@redhat.com>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Attempt disk reactivation in more failure scenarios
Commit fe904ea824 added a fail_inactivate label, which tries to
reactivate disks on the source after a failure while s->state ==
MIGRATION_STATUS_ACTIVE, but didn't actually use the label if
qemu_savevm_state_complete_precopy() failed. This failure to
reactivate is also present in commit 6039dd5b1c (also covering the new
s->state == MIGRATION_STATUS_DEVICE state) and 403d18ae (ensuring
s->block_inactive is set more reliably).
Consolidate the two labels back into one - no matter HOW migration is
failed, if there is any chance we can reach vm_start() after having
attempted inactivation, it is essential that we have tried to restart
disks before then. This also makes the cleanup more like
migrate_fd_cancel().
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20230502205212.134680-1-eblake@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 6dab4c93ecfae48e2e67b984d1032c1e988d3005)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: minor context tweak near added comment in migration/migration.c)
Commit: c283a4bc7621b37fc62fd0eac1932796d2de84ab
https://github.com/qemu/qemu/commit/c283a4bc7621b37fc62fd0eac1932796d2de84ab
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M target/arm/tcg/sve_helper.c
Log Message:
-----------
target/arm: Fix vd == vm overlap in sve_ldff1_z
If vd == vm, copy vm to scratch, so that we can pre-zero
the output and still access the gather indicies.
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1612
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20230504104232.1877774-1-richard.henderson@linaro.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit a6771f2f5cbfbf312e2fb5b1627f38a6bf6321d0)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 1e029102e6b6b176d692944d9df94c6b46185912
https://github.com/qemu/qemu/commit/1e029102e6b6b176d692944d9df94c6b46185912
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M hw/scsi/scsi-generic.c
Log Message:
-----------
scsi-generic: fix buffer overflow on block limits inquiry
Using linux 6.x guest, at boot time, an inquiry on a scsi-generic
device makes qemu crash. This is caused by a buffer overflow when
scsi-generic patches the block limits VPD page.
Do the operations on a temporary on-stack buffer that is guaranteed
to be large enough.
Reported-by: Théo Maillart <tmaillart@freebox.fr>
Analyzed-by: Théo Maillart <tmaillart@freebox.fr>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 9bd634b2f5e2f10fe35d7609eb83f30583f2e15a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: db8051ad59f416a91ad4121d3d11f52e2879c429
https://github.com/qemu/qemu/commit/db8051ad59f416a91ad4121d3d11f52e2879c429
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M target/i386/tcg/decode-new.c.inc
Log Message:
-----------
target/i386: fix operand size for VCOMI/VUCOMI instructions
Compared to other SSE instructions, VUCOMISx and VCOMISx are different:
the single and double precision versions are distinguished through a
prefix, however they use no-prefix and 0x66 for SS and SD respectively.
Scalar values usually are associated with 0xF2 and 0xF3.
Because of these, they incorrectly perform a 128-bit memory load instead
of a 32- or 64-bit load. Fix this by writing a custom decoding function.
I tested that the reproducer is fixed and the test-avx output does not
change.
Reported-by: Gabriele Svelto <gsvelto@mozilla.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1637
Fixes: f8d19eec0d53 ("target/i386: reimplement 0x0f 0x28-0x2f, add AVX",
2022-10-18)
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 2b55e479e6fcbb466585fd25077a50c32e10dc3a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0de51178193afc8bf614cbb2af2d69508408bbcb
https://github.com/qemu/qemu/commit/0de51178193afc8bf614cbb2af2d69508408bbcb
Author: Xinyu Li <lixinyu20s@ict.ac.cn>
Date: 2023-05-18 (Thu, 18 May 2023)
Changed paths:
M target/i386/ops_sse.h
M target/i386/tcg/emit.c.inc
Log Message:
-----------
target/i386: fix avx2 instructions vzeroall and vpermdq
vzeroall: xmm_regs should be used instead of xmm_t0
vpermdq: bit 3 and 7 of imm should be considered
Signed-off-by: Xinyu Li <lixinyu20s@ict.ac.cn>
Message-Id: <20230510145222.586487-1-lixinyu20s@ict.ac.cn>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 056d649007bc9fdae9f1d576e77c1316e9a34468)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: a9144eed6c431ed760247388acff2b601f3721d9
https://github.com/qemu/qemu/commit/a9144eed6c431ed760247388acff2b601f3721d9
Author: Hawkins Jiawei <yin31149@gmail.com>
Date: 2023-05-19 (Fri, 19 May 2023)
Changed paths:
M hw/virtio/vhost-shadow-virtqueue.c
M hw/virtio/vhost-shadow-virtqueue.h
Log Message:
-----------
vhost: fix possible wrap in SVQ descriptor ring
QEMU invokes vhost_svq_add() when adding a guest's element
into SVQ. In vhost_svq_add(), it uses vhost_svq_available_slots()
to check whether QEMU can add the element into SVQ. If there is
enough space, then QEMU combines some out descriptors and some
in descriptors into one descriptor chain, and adds it into
`svq->vring.desc` by vhost_svq_vring_write_descs().
Yet the problem is that, `svq->shadow_avail_idx - svq->shadow_used_idx`
in vhost_svq_available_slots() returns the number of occupied elements,
or the number of descriptor chains, instead of the number of occupied
descriptors, which may cause wrapping in SVQ descriptor ring.
Here is an example. In vhost_handle_guest_kick(), QEMU forwards
as many available buffers to device by virtqueue_pop() and
vhost_svq_add_element(). virtqueue_pop() returns a guest's element,
and then this element is added into SVQ by vhost_svq_add_element(),
a wrapper to vhost_svq_add(). If QEMU invokes virtqueue_pop() and
vhost_svq_add_element() `svq->vring.num` times,
vhost_svq_available_slots() thinks QEMU just ran out of slots and
everything should work fine. But in fact, virtqueue_pop() returns
`svq->vring.num` elements or descriptor chains, more than
`svq->vring.num` descriptors due to guest memory fragmentation,
and this causes wrapping in SVQ descriptor ring.
This bug is valid even before marking the descriptors used.
If the guest memory is fragmented, SVQ must add chains
so it can try to add more descriptors than possible.
This patch solves it by adding `num_free` field in
VhostShadowVirtqueue structure and updating this field
in vhost_svq_add() and vhost_svq_get_buf(), to record
the number of free descriptors.
Fixes: 100890f7ca ("vhost: Shadow virtqueue buffers forwarding")
Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230509084817.3973-1-yin31149@gmail.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Lei Yang <leiyang@redhat.com>
(cherry picked from commit 5d410557dea452f6231a7c66155e29a37e168528)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 2e4df3b10b9c96db934257c81ec90828fe70c772
https://github.com/qemu/qemu/commit/2e4df3b10b9c96db934257c81ec90828fe70c772
Author: Hao Zeng <zenghao@kylinos.cn>
Date: 2023-05-19 (Fri, 19 May 2023)
Changed paths:
M hw/cxl/cxl-cdat.c
Log Message:
-----------
hw/cxl: cdat: Fix open file not closed in ct3_load_cdat()
Open file descriptor not closed in error paths. Fix by replace
open coded handling of read of whole file into a buffer with
g_file_get_contents()
Fixes: aba578bdac ("hw/cxl: CDAT Data Object Exchange implementation")
Signed-off-by: Zeng Hao <zenghao@kylinos.cn>
Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Suggested-by: Jonathan Cameron via <qemu-devel@nongnu.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
--
Changes since v5:
- Drop if guard on g_free() as per checkpatch warning.
Message-Id: <20230421132020.7408-2-Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 71ba92f3488b64bd5c81e2872c56e88cea21bb95)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: d79c7325b21e6a9610bff500ea9259554aec67ca
https://github.com/qemu/qemu/commit/d79c7325b21e6a9610bff500ea9259554aec67ca
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date: 2023-05-20 (Sat, 20 May 2023)
Changed paths:
M hw/cxl/cxl-cdat.c
M hw/mem/cxl_type3.c
M hw/pci-bridge/cxl_upstream.c
Log Message:
-----------
hw/cxl: cdat: Fix failure to free buffer in erorr paths
The failure paths in CDAT file loading did not clear up properly.
Change to using g_auto_free and a local pointer for the buffer to
ensure this function has no side effects on error.
Also drop some unnecessary checks that can not fail.
Cleanup properly after a failure to load a CDAT file.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Message-Id: <20230421132020.7408-3-Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 7b22a3218ad0b8388c8bf20d394e3220b2fc8798)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 4e29d7aca06770dc4dc8212de2fad313ac05b4c7
https://github.com/qemu/qemu/commit/4e29d7aca06770dc4dc8212de2fad313ac05b4c7
Author: Leonardo Bras <leobras@redhat.com>
Date: 2023-05-20 (Sat, 20 May 2023)
Changed paths:
M hw/core/machine.c
M hw/pci/pci.c
M hw/pci/pcie_aer.c
M include/hw/pci/pci.h
Log Message:
-----------
hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0
Since it's implementation on v8.0.0-rc0, having the PCI_ERR_UNCOR_MASK
set for machine types < 8.0 will cause migration to fail if the target
QEMU version is < 8.0.0 :
qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10a read: 40
device: 0 cmask: ff wmask: 0 w1cmask:0
qemu-system-x86_64: Failed to load PCIDevice:config
qemu-system-x86_64: Failed to load e1000e:parent_obj
qemu-system-x86_64: error while loading state for instance 0x0 of device
'0000:00:02.0/e1000e'
qemu-system-x86_64: load of migration failed: Invalid argument
The above test migrated a 7.2 machine type from QEMU master to QEMU 7.2.0,
with this cmdline:
./qemu-system-x86_64 -M pc-q35-7.2 [-incoming XXX]
In order to fix this, property x-pcie-err-unc-mask was introduced to
control when PCI_ERR_UNCOR_MASK is enabled. This property is enabled by
default, but is disabled if machine type <= 7.2.
Fixes: 010746ae1d ("hw/pci/aer: Implement PCI_ERR_UNCOR_MASK register")
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Leonardo Bras <leobras@redhat.com>
Message-Id: <20230503002701.854329-1-leobras@redhat.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1576
Tested-by: Fiona Ebner <f.ebner@proxmox.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 5ed3dabe57dd9f4c007404345e5f5bf0e347317f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 51233b9ee2dae93cfa4499bab014c99033986250
https://github.com/qemu/qemu/commit/51233b9ee2dae93cfa4499bab014c99033986250
Author: Eugenio Pérez <eperezma@redhat.com>
Date: 2023-05-20 (Sat, 20 May 2023)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
virtio-net: not enable vq reset feature unconditionally
The commit 93a97dc5200a ("virtio-net: enable vq reset feature") enables
unconditionally vq reset feature as long as the device is emulated.
This makes impossible to actually disable the feature, and it causes
migration problems from qemu version previous than 7.2.
The entire final commit is unneeded as device system already enable or
disable the feature properly.
This reverts commit 93a97dc5200a95e63b99cb625f20b7ae802ba413.
Fixes: 93a97dc5200a ("virtio-net: enable vq reset feature")
Signed-off-by: Eugenio Pérez <eperezma@redhat.com>
Message-Id: <20230504101447.389398-1-eperezma@redhat.com>
Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 1fac00f70b3261050af5564b20ca55c1b2a3059a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 26da5de3a09da208df9c77230ab4341b329c039a
https://github.com/qemu/qemu/commit/26da5de3a09da208df9c77230ab4341b329c039a
Author: Mauro Matteo Cascella <mcascell@redhat.com>
Date: 2023-05-20 (Sat, 20 May 2023)
Changed paths:
M hw/virtio/virtio-crypto.c
Log Message:
-----------
virtio-crypto: fix NULL pointer dereference in virtio_crypto_free_request
Ensure op_info is not NULL in case of QCRYPTODEV_BACKEND_ALG_SYM algtype.
Fixes: 0e660a6f90a ("crypto: Introduce RSA algorithm")
Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>
Reported-by: Yiming Tao <taoym@zju.edu.cn>
Message-Id: <20230509075317.1132301-1-mcascell@redhat.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: zhenwei pi<pizhenwei@bytedance.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 3e69908907f8d3dd20d5753b0777a6e3824ba824)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/8c7966df7b0e...26da5de3a09d
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] e347aa: s390x/tcg: Fix LDER instruction format,
Alex Bennée <=