[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 151399: multi-process: Initialize variables d
|
From: |
Marcel Apfelbaum |
|
Subject: |
[Qemu-commits] [qemu/qemu] 151399: multi-process: Initialize variables declared with ... |
|
Date: |
Mon, 18 Oct 2021 08:09:18 -0700 |
Branch: refs/heads/stable-6.0-staging
Home: https://github.com/qemu/qemu
Commit: 1513997aa2aac392d8a2e020feddd26f0f1fc4d3
https://github.com/qemu/qemu/commit/1513997aa2aac392d8a2e020feddd26f0f1fc4d3
Author: Zenghui Yu <yuzenghui@huawei.com>
Date: 2021-10-13 (Wed, 13 Oct 2021)
Changed paths:
M hw/remote/memory.c
M hw/remote/proxy.c
Log Message:
-----------
multi-process: Initialize variables declared with g_auto*
Quote docs/devel/style.rst (section "Automatic memory deallocation"):
* Variables declared with g_auto* MUST always be initialized,
otherwise the cleanup function will use uninitialized stack memory
Initialize @name properly to get rid of the compilation error (using
gcc-7.3.0 on CentOS):
../hw/remote/proxy.c: In function 'pci_proxy_dev_realize':
/usr/include/glib-2.0/glib/glib-autocleanups.h:28:3: error: 'name' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
g_free (*pp);
^~~~~~~~~~~~
../hw/remote/proxy.c:350:30: note: 'name' was declared here
g_autofree char *name;
^~~~
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Reviewed-by: Jagannathan Raman <jag.raman@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Miroslav Rezanina <mrezanin@redhat.com>
Message-id: 20210312112143.1369-1-yuzenghui@huawei.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit d90226808b5b1b30b07968e94d8f74bf8804fc89)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 5d0c78455ebac78fba07949910434c040352facc
https://github.com/qemu/qemu/commit/5d0c78455ebac78fba07949910434c040352facc
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2021-10-13 (Wed, 13 Oct 2021)
Changed paths:
M linux-user/elfload.c
Log Message:
-----------
linux-user/aarch64: Enable hwcap for RND, BTI, and MTE
These three features are already enabled by TCG, but are missing
their hwcap bits. Update HWCAP2 from linux v5.12.
Cc: qemu-stable@nongnu.org (for 6.0.1)
Buglink: https://bugs.launchpad.net/bugs/1926044
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210427214108.88503-1-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 68948d18224b93361e2880e2946ab268d0c650d7)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: c1d1c0b4c3a3a96b25b8dff091ae9874705e39b1
https://github.com/qemu/qemu/commit/c1d1c0b4c3a3a96b25b8dff091ae9874705e39b1
Author: Greg Kurz <groug@kaod.org>
Date: 2021-10-13 (Wed, 13 Oct 2021)
Changed paths:
M docs/system/removed-features.rst
Log Message:
-----------
docs/system: Document the removal of "compat" property for POWER CPUs
This is just an oversight.
Fixes: f518be3aa35b ("target/ppc: Remove "compat" property of server class
POWER CPUs")
Cc: groug@kaod.org
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <161399328834.51902.14269239378658110394.stgit@bahia.lan>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
(cherry picked from commit a058b895079348d0854a027a42ce3396a4a00bb7)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 318b07635651ca284f0e3f60f1c117a5fda41463
https://github.com/qemu/qemu/commit/318b07635651ca284f0e3f60f1c117a5fda41463
Author: Stefan Reiter <s.reiter@proxmox.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M monitor/qmp.c
Log Message:
-----------
monitor/qmp: fix race on CHR_EVENT_CLOSED without OOB
The QMP dispatcher coroutine holds the qmp_queue_lock over a yield
point, where it expects to be rescheduled from the main context. If a
CHR_EVENT_CLOSED event is received just then, it can race and block the
main thread on the mutex in monitor_qmp_cleanup_queue_and_resume.
monitor_resume does not need to be called from main context, so we can
call it immediately after popping a request from the queue, which allows
us to drop the qmp_queue_lock mutex before yielding.
Suggested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Message-Id: <20210322154024.15011-1-s.reiter@proxmox.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
(cherry picked from commit a67b996e7894edfafbcd3fd007c9f58f26d25908)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: fdf58b451b4d419238b266f578d50fd693c36844
https://github.com/qemu/qemu/commit/fdf58b451b4d419238b266f578d50fd693c36844
Author: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M migration/rdma.c
Log Message:
-----------
migration/rdma: Fix cm_event used before being initialized
A segmentation fault was triggered when i try to abort a postcopy + rdma
migration.
since rdma_ack_cm_event releases a uninitialized cm_event in these case.
like below:
2496 ret = rdma_get_cm_event(rdma->channel, &cm_event);
2497 if (ret) {
2498 perror("rdma_get_cm_event after rdma_connect");
2499 ERROR(errp, "connecting to destination!");
2500 rdma_ack_cm_event(cm_event); <<<< cause segmentation fault
2501 goto err_rdma_source_connect;
2502 }
Refer to the rdma_get_cm_event() code, cm_event will be
updated/changed only if rdma_get_cm_event() returns 0. So it's okey to
remove the ack in error patch.
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
Message-Id: <20210519064740.10828-1-lizhijian@cn.fujitsu.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit efb208dc9c3f1e881aecff21fb1c7a7b6b869480)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: e2258e527950fff984f1be0a71dbbae2cb14ebfc
https://github.com/qemu/qemu/commit/e2258e527950fff984f1be0a71dbbae2cb14ebfc
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M target/i386/tcg/translate.c
Log Message:
-----------
target/i386: Exit tb after wrmsr
At minimum, wrmsr can change efer, which affects HF_LMA.
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210514151342.384376-46-richard.henderson@linaro.org>
(cherry picked from commit 244843b757220c432e0e9ae8d2210218c034730d)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 59ac5e6d61fcf95d723c7191711ff9b7f6462320
https://github.com/qemu/qemu/commit/59ac5e6d61fcf95d723c7191711ff9b7f6462320
Author: Giuseppe Musacchio <thatlemon@gmail.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M target/ppc/translate/vsx-impl.c.inc
Log Message:
-----------
target/ppc: Fix load endianness for lxvwsx/lxvdsx
TARGET_WORDS_BIGENDIAN may not match the machine endianness if that's a
runtime-configurable parameter.
Fixes: bcb0b7b1a1c05707304f80ca6f523d557816f85c
Fixes: afae37d98ae991c0792c867dbd9f32f988044318
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/212
Signed-off-by: Giuseppe Musacchio <thatlemon@gmail.com>
Message-Id: <20210518133020.58927-1-thatlemon@gmail.com>
Tested-by: Paul A. Clarke <pc@us.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 861f10fd528263a507476b8c4dda93a9588dfa5c)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: b20eff3ba44576dad70b76969870837de7105ba3
https://github.com/qemu/qemu/commit/b20eff3ba44576dad70b76969870837de7105ba3
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M softmmu/vl.c
Log Message:
-----------
vl: allow not specifying size in -m when using -M memory-backend
Starting in QEMU 6.0's commit f5c9fcb82d ("vl: separate
qemu_create_machine", 2020-12-10), a function have_custom_ram_size()
replaced the return value of set_memory_options().
The purpose of the return value was to record the presence of
"-m size", and if it was not there, change the default RAM
size to the size of the memory backend passed with "-M
memory-backend".
With that commit, however, have_custom_ram_size() is now queried only
after set_memory_options has stored the fixed-up RAM size in QemuOpts for
"future use". This was actually the only future use of the fixed-up RAM
size, so remove that code and fix the bug.
Cc: qemu-stable@nongnu.org
Fixes: f5c9fcb82d ("vl: separate qemu_create_machine", 2020-12-10)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d349f92f78d26db2805ca39a7745cc70affea021)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: ab331881254228561c1045d4fa96cc5f66672a41
https://github.com/qemu/qemu/commit/ab331881254228561c1045d4fa96cc5f66672a41
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M target/xtensa/translate.c
Log Message:
-----------
target/xtensa: fix access ring in l32ex
l32ex does memory access as all regular load/store operations at CRING
level. Fix apparent pasto from l32e that caused it to use RING instead.
This is a correctness issue, not a security issue, because in the worst
case the privilege level of memory access may be lowered, resulting in
an exception when the correct implementation would've succeeded.
In no case it would allow memory access that would've raised an
exception in the correct implementation.
Cc: qemu-stable@nongnu.org
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 735aa900e4bf57b777ac620bed7c88234ec4b601)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 4e1eef86117da65c7e084e9e87df3f562682a84b
https://github.com/qemu/qemu/commit/4e1eef86117da65c7e084e9e87df3f562682a84b
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M util/qemu-option.c
Log Message:
-----------
qemu-option: support accept-any QemuOptsList in qemu_opts_absorb_qdict
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 941a4736d2b465be1d6429415f8b1f26e2167585)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 701ff59cc42e5812c1cd024a07b4802f19e0fd2a
https://github.com/qemu/qemu/commit/701ff59cc42e5812c1cd024a07b4802f19e0fd2a
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M include/qemu/config-file.h
M softmmu/vl.c
M stubs/meson.build
A stubs/module-opts.c
M util/qemu-config.c
Log Message:
-----------
qemu-config: load modules when instantiating option groups
Right now the SPICE module is special cased to be loaded when processing
of the -spice command line option. However, the spice option group
can also be brought in via -readconfig, in which case the module is
not loaded.
Add a generic hook to load modules that provide a QemuOpts group,
and use it for the "spice" and "iscsi" groups.
Fixes: #194
Fixes: https://bugs.launchpad.net/qemu/+bug/1910696
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 632a8873500d27022c584256afc11e57e2418b94)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 203f0ba14434057d6ea1fef15a34694965771837
https://github.com/qemu/qemu/commit/203f0ba14434057d6ea1fef15a34694965771837
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M include/qemu/config-file.h
M softmmu/vl.c
M util/qemu-config.c
Log Message:
-----------
qemu-config: parse configuration files to a QDict
Change the parser to put the values into a QDict and pass them
to a callback. qemu_config_parse's QemuOpts creation is
itself turned into a callback function.
This is useful for -readconfig to support keyval-based options;
getting a QDict from the parser removes a roundtrip from
QDict to QemuOpts and then back to QDict.
Unfortunately there is a disadvantage in that semantic errors will
point to the last line of the group, because the entries of the QDict
do not have a location attached.
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210524105752.3318299-2-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 37701411397c7b7d709ae92abd347cc593940ee5)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: c675ba821cc2369fe369b89efa09696a2b1afda1
https://github.com/qemu/qemu/commit/c675ba821cc2369fe369b89efa09696a2b1afda1
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M include/block/qdict.h
M include/qapi/qmp/qdict.h
M softmmu/vl.c
Log Message:
-----------
vl: plumb keyval-based options into -readconfig
Let -readconfig support parsing command line options into QDict or
QemuOpts. This will be used to add back support for objects in
-readconfig.
Cc: Markus Armbruster <armbru@redhat.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210524105752.3318299-3-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit c0d4aa82f895af67cbf7772324e05605e22b4162)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 5b96b36a6162d24fd6a4d64c81e71b3a60e511a6
https://github.com/qemu/qemu/commit/5b96b36a6162d24fd6a4d64c81e71b3a60e511a6
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M softmmu/vl.c
Log Message:
-----------
vl: plug -object back into -readconfig
Commit bc2f4fcb1d ("qom: move user_creatable_add_opts logic to vl.c
and QAPIfy it", 2021-03-19) switched the creation of objects from
qemu_opts_foreach to a bespoke QTAILQ in preparation for supporting JSON
syntax in -object.
Unfortunately in doing so it lost support for [object] stanzas in
configuration files and also for "-set object.ID.KEY=VAL". The latter
is hard to re-establish and probably best solved by deprecating -set.
This patch uses the infrastructure introduced by the previous two
patches in order to parse QOM objects correctly from configuration
files.
Cc: Markus Armbruster <armbru@redhat.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20210524105752.3318299-4-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 49e987695a1873a769a823604f9065aa88e00c55)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 9b0ee423a1b5312f12e375eaacb6fcdd56e60d16
https://github.com/qemu/qemu/commit/9b0ee423a1b5312f12e375eaacb6fcdd56e60d16
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M util/qemu-sockets.c
Log Message:
-----------
sockets: update SOCKET_ADDRESS_TYPE_FD listen(2) backlog
socket_get_fd() fails with the error "socket_get_fd: too many
connections" if the given listen backlog value is not 1.
Not all callers set the backlog to 1. For example, commit
582d4210eb2f2ab5baac328fe4b479cd86da1647 ("qemu-nbd: Use SOMAXCONN for
socket listen() backlog") uses SOMAXCONN. This will always fail with in
socket_get_fd().
This patch calls listen(2) on the fd to update the backlog value. The
socket may already be in the listen state. I have tested that this works
on Linux 5.10 and macOS Catalina.
As a bonus this allows us to detect when the fd cannot listen. Now we'll
be able to catch unbound or connected fds in socket_listen().
Drop the num argument from socket_get_fd() since this function is also
called by socket_connect() where a listen backlog value does not make
sense.
Fixes: e5b6353cf25c99c3f08bf51e29933352f7140e8f ("socket: Add backlog parameter
to socket_listen")
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20210310173004.420190-1-stefanha@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 37179e9ea45d6428b29ae789209c119ac18c1d39)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: fcfe1509a1a622d85224a1e7003aba940897fe8d
https://github.com/qemu/qemu/commit/fcfe1509a1a622d85224a1e7003aba940897fe8d
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M monitor/hmp-cmds.c
Log Message:
-----------
hmp: Fix loadvm to resume the VM on success instead of failure
Commit f61fe11aa6f broke hmp_loadvm() by adding an incorrect negation
when converting from 0/-errno return values to a bool value. The result
is that loadvm resumes the VM now if it failed and keeps it stopped if
it failed. Fix it to restore the old behaviour and do it the other way
around.
Fixes: f61fe11aa6f7f8f0ffe4ddaa56a8108f3ab57854
Cc: qemu-stable@nongnu.org
Reported-by: Yanhui Ma <yama@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20210511163151.45167-1-kwolf@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit c53cd04e70641fdf9410aac40c617d074047b3e1)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: ad8c49081aad03dbeab57717280326d3d98d659e
https://github.com/qemu/qemu/commit/ad8c49081aad03dbeab57717280326d3d98d659e
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M configure
Log Message:
-----------
configure: fix detection of gdbus-codegen
"pkg-config --variable=gdbus_codegen gio-2.0" returns "gdbus-codegen",
and it does not pass test -x (which does not walk the path).
Meson 0.58.0 notices that something is iffy, as the dbus_vmstate1
assignment in tests/qtest/meson.build uses an empty string as the
command, and fails very eloquently:
../tests/qtest/meson.build:92:2: ERROR: No program name specified.
Use the "has" function instead of test -x, and fix the generation
of config-host.mak since meson.build expects that GDBUS_CODEGEN
is absent, rather than empty, if the tool is unavailable.
Reported-by: Sebastian Mitterle <smitterl@redhat.com>
Fixes: #178
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 5ecfb76ccc056eb6127e44268e475827ae73b9e0)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 8d719825d93b219d3de046e3e41ccc6ff39bea11
https://github.com/qemu/qemu/commit/8d719825d93b219d3de046e3e41ccc6ff39bea11
Author: Jason Wang <jasowang@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/virtio/vhost-vdpa.c
Log Message:
-----------
vhost-vdpa: don't initialize backend_features
We used to initialize backend_features during vhost_vdpa_init()
regardless whether or not it was supported by vhost. This will lead
the unsupported features like VIRTIO_F_IN_ORDER to be included and set
to the vhost-vdpa during vhost_dev_start. Because the
VIRTIO_F_IN_ORDER is not supported by vhost-vdpa so it won't be
advertised to guest which will break the datapath.
Fix this by not initializing the backend_features, so the
acked_features could be built only from guest features via
vhost_net_ack_features().
Fixes: 108a64818e69b ("vhost-vdpa: introduce vhost-vdpa backend")
Cc: qemu-stable@nongnu.org
Cc: Gautam Dawar <gdawar@xilinx.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit c33f23a419f95da16ab4faaf08be635c89b96ff0)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 44e5878ce34d27dbebd4198766eb843833f4972e
https://github.com/qemu/qemu/commit/44e5878ce34d27dbebd4198766eb843833f4972e
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/scsi/esp.c
Log Message:
-----------
esp: only assert INTR_DC interrupt flag if selection fails
The datasheet sequence tables confirm that when a target selection fails, only
the INTR_DC interrupt flag should be asserted.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Fixes: cf47a41e05 ("esp: latch individual bits in ESP_RINTR register")
Message-Id: <20210518212511.21688-2-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit cf1a7a9b3721544aaa3e43d111eb383c30d71a62)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: b6f5c02f5f757e0aec2869b336a3ea11ed5eec7c
https://github.com/qemu/qemu/commit/b6f5c02f5f757e0aec2869b336a3ea11ed5eec7c
Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/scsi/esp.c
Log Message:
-----------
esp: only set ESP_RSEQ at the start of the select sequence
When processing a command to select a target and send a CDB, the ESP device
maintains a sequence step register so that if an error occurs the host can
determine which part of the selection/CDB submission sequence failed.
The old Linux 2.6 driver is really pedantic here: it checks the sequence step
register even if a command succeeds and complains loudly on the console if the
sequence step register doesn't match the expected bus phase and interrupt flags.
This reason this mismatch occurs is because the ESP emulation currently doesn't
update the bus phase until the next TI (Transfer Information) command and so the
cleared sequence step register is considered invalid for the stale bus phase.
Normally this isn't an issue as the host only checks the sequence step register
if an error occurs but the old Linux 2.6 driver does this in several places
causing a large stream of "esp0: STEP_ASEL for tgt 0" messages to appear on the
console during the boot process.
Fix this by not clearing the sequence step register when reading the interrupt
register and clearing the DMA status, so the guest sees a valid sequence step
and bus phase combination at the end of the command phase. No other change is
required since the sequence step register is correctly updated throughout the
selection/CDB submission sequence once one of the select commands is issued.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Fixes: 1b9e48a5bd ("esp: implement non-DMA transfers in PDMA mode")
Message-Id: <20210518212511.21688-3-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit af947a3d853a235943681a00f07f3081f5143cc3)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: d1000ee07b02c3a6f87a39b45d1b8c5689a14aa9
https://github.com/qemu/qemu/commit/d1000ee07b02c3a6f87a39b45d1b8c5689a14aa9
Author: Peng Liang <liangpeng10@huawei.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M softmmu/runstate.c
Log Message:
-----------
runstate: Initialize Error * to NULL
Based on the description of error_setg(), the local variable err in
qemu_init_subsystems() should be initialized to NULL.
Fixes: efd7ab22fb ("vl: extract qemu_init_subsystems")
Cc: qemu-stable@nongnu.org
Signed-off-by: Peng Liang <liangpeng10@huawei.com>
Message-Id: <20210610131729.3906565-1-liangpeng10@huawei.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 6e1da3d305499d3907f3c7f6638243e2e09b5085)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 5b55370e28e262fba0c95f5dc05e9551c875671a
https://github.com/qemu/qemu/commit/5b55370e28e262fba0c95f5dc05e9551c875671a
Author: Kunkun Jiang <jiangkunkun@huawei.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/vfio/migration.c
Log Message:
-----------
vfio: Fix unregister SaveVMHandler in vfio_migration_finalize
In the vfio_migration_init(), the SaveVMHandler is registered for
VFIO device. But it lacks the operation of 'unregister'. It will
lead to 'Segmentation fault (core dumped)' in
qemu_savevm_state_setup(), if performing live migration after a
VFIO device is hot deleted.
Fixes: 7c2f5f75f94 (vfio: Register SaveVMHandlers for VFIO device)
Reported-by: Qixin Gan <ganqixin@huawei.com>
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com>
Message-Id: <20210527123101.289-1-jiangkunkun@huawei.com>
Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
(cherry picked from commit 22fca190e25b10761925bb1eeadeda07aabf3c26)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: cdb8a71e2e4bcef3a7815d6a3d02bb8da2a1001d
https://github.com/qemu/qemu/commit/cdb8a71e2e4bcef3a7815d6a3d02bb8da2a1001d
Author: Zhenzhong Duan <zhenzhong.duan@intel.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M softmmu/vl.c
Log Message:
-----------
vl: Fix an assert failure in error path
Based on the description of error_setg(), the local variable err in
qemu_maybe_daemonize() should be initialized to NULL.
Without fix, the uninitialized *errp triggers assert failure which
doesn't show much valuable information.
Before the fix:
qemu-system-x86_64: ../util/error.c:59: error_setv: Assertion `*errp == NULL'
failed.
After fix:
qemu-system-x86_64: cannot create PID file: Cannot open pid file: Permission
denied
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Message-Id: <20210610084741.456260-1-zhenzhong.duan@intel.com>
Cc: qemu-stable@nongnu.org
Fixes: 0546c0609c ("vl: split various early command line options to a separate
function", 2020-12-10)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 38f71349c7c4969bc14da4da1c70b8cc4078d596)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 1a0a1c49649f7e7b2116daa127337a003bb0dcfb
https://github.com/qemu/qemu/commit/1a0a1c49649f7e7b2116daa127337a003bb0dcfb
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M tcg/sparc/tcg-target.c.inc
M tcg/tcg.c
Log Message:
-----------
tcg/sparc: Fix temp_allocate_frame vs sparc stack bias
We should not be aligning the offset in temp_allocate_frame,
because the odd offset produces an aligned address in the end.
Instead, pass the logical offset into tcg_set_frame and add
the stack bias last.
Cc: qemu-stable@nongnu.org
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 9defd1bdfb0f2ddb3ca9863e39577f3a9929d58c)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 059ad82f38073afb5aaa2245aeeda7eee608fc79
https://github.com/qemu/qemu/commit/059ad82f38073afb5aaa2245aeeda7eee608fc79
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M tcg/tcg.c
Log Message:
-----------
tcg: Allocate sufficient storage in temp_allocate_frame
This function should have been updated for vector types
when they were introduced.
Fixes: d2fd745fe8b
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/367
Cc: qemu-stable@nongnu.org
Tested-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit c1c091948ae4a73c1a80b5005f6204d0e665ce52)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 0a579d4389fb52bd139cec5457b2a27fc29b78f7
https://github.com/qemu/qemu/commit/0a579d4389fb52bd139cec5457b2a27fc29b78f7
Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/pci-host/q35.c
Log Message:
-----------
hw/pci-host/q35: Ignore write of reserved PCIEXBAR LENGTH field
libFuzzer triggered the following assertion:
cat << EOF | qemu-system-i386 -M pc-q35-5.0 \
-nographic -monitor none -serial none \
-qtest stdio -d guest_errors -trace pci\*
outl 0xcf8 0xf2000060
outl 0xcfc 0x8400056e
EOF
pci_cfg_write mch 00:0 @0x60 <- 0x8400056e
Aborted (core dumped)
This is because guest wrote MCH_HOST_BRIDGE_PCIEXBAR_LENGTH_RVD
(reserved value) to the PCIE XBAR register.
There is no indication on the datasheet about what occurs when
this value is written. Simply ignore it on QEMU (and report an
guest error):
pci_cfg_write mch 00:0 @0x60 <- 0x8400056e
Q35: Reserved PCIEXBAR LENGTH
pci_cfg_read mch 00:0 @0x0 -> 0x8086
pci_cfg_read mch 00:0 @0x0 -> 0x29c08086
...
Cc: qemu-stable@nongnu.org
Reported-by: Alexander Bulekov <alxndr@bu.edu>
BugLink: https://bugs.launchpad.net/qemu/+bug/1878641
Fixes: df2d8b3ed4 ("q35: Introduce q35 pc based chipset emulator")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210526142438.281477-1-f4bug@amsat.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 9b0ca75e0196a72523232063db1e07ae36a5077a)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 072a8d3693b40f46efcc7b05f6f4136760e57612
https://github.com/qemu/qemu/commit/072a8d3693b40f46efcc7b05f6f4136760e57612
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M block/nvme.c
Log Message:
-----------
block/nvme: Fix VFIO_MAP_DMA failed: No space left on device
When the NVMe block driver was introduced (see commit bdd6a90a9e5,
January 2018), Linux VFIO_IOMMU_MAP_DMA ioctl was only returning
-ENOMEM in case of error. The driver was correctly handling the
error path to recycle its volatile IOVA mappings.
To fix CVE-2019-3882, Linux commit 492855939bdb ("vfio/type1: Limit
DMA mappings per container", April 2019) added the -ENOSPC error to
signal the user exhausted the DMA mappings available for a container.
The block driver started to mis-behave:
qemu-system-x86_64: VFIO_MAP_DMA failed: No space left on device
(qemu)
(qemu) info status
VM status: paused (io-error)
(qemu) c
VFIO_MAP_DMA failed: No space left on device
(qemu) c
VFIO_MAP_DMA failed: No space left on device
(The VM is not resumable from here, hence stuck.)
Fix by handling the new -ENOSPC error (when DMA mappings are
exhausted) without any distinction to the current -ENOMEM error,
so we don't change the behavior on old kernels where the CVE-2019-3882
fix is not present.
An easy way to reproduce this bug is to restrict the DMA mapping
limit (65535 by default) when loading the VFIO IOMMU module:
# modprobe vfio_iommu_type1 dma_entry_limit=666
Cc: qemu-stable@nongnu.org
Cc: Fam Zheng <fam@euphon.net>
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Reported-by: Michal Prívozník <mprivozn@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20210723195843.1032825-1-philmd@redhat.com
Fixes: bdd6a90a9e5 ("block: Add VFIO based NVMe driver")
Buglink: https://bugs.launchpad.net/qemu/+bug/1863333
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/65
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 15a730e7a3aaac180df72cd5730e0617bcf44a5a)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 7e84d58e8be9c8b64710982f947f63b95816d311
https://github.com/qemu/qemu/commit/7e84d58e8be9c8b64710982f947f63b95816d311
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M crypto/tlscreds.c
M include/crypto/tlscreds.h
Log Message:
-----------
crypto/tlscreds: Introduce qcrypto_tls_creds_check_endpoint() helper
Introduce the qcrypto_tls_creds_check_endpoint() helper
to access QCryptoTLSCreds internal 'endpoint' field.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit e9ac68083f26759b85ef0d871ca2bbe897218f64)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 738ff4bf07304399d3d830afd4b5e3296fbb3cce
https://github.com/qemu/qemu/commit/738ff4bf07304399d3d830afd4b5e3296fbb3cce
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M block/nbd.c
M blockdev-nbd.c
Log Message:
-----------
block/nbd: Use qcrypto_tls_creds_check_endpoint()
Avoid accessing QCryptoTLSCreds internals by using
the qcrypto_tls_creds_check_endpoint() helper.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 7b3b616838c30830c004b746e7b1209297118318)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 8d5c255a2569b01c56b32783da93b1c2f15c7deb
https://github.com/qemu/qemu/commit/8d5c255a2569b01c56b32783da93b1c2f15c7deb
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M qemu-nbd.c
Log Message:
-----------
qemu-nbd: Use qcrypto_tls_creds_check_endpoint()
Avoid accessing QCryptoTLSCreds internals by using
the qcrypto_tls_creds_check_endpoint() helper.
Tested-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 0279cd9535283cf5711768ab6401b204e5697a81)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 0a7e2c99f9cbe6c64e0e7ba002d362d0e4b6dc5c
https://github.com/qemu/qemu/commit/0a7e2c99f9cbe6c64e0e7ba002d362d0e4b6dc5c
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M chardev/char-socket.c
Log Message:
-----------
chardev/socket: Use qcrypto_tls_creds_check_endpoint()
Avoid accessing QCryptoTLSCreds internals by using
the qcrypto_tls_creds_check_endpoint() helper.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 8612df2ebef9ff1f880fe76d223a3369b9c98db2)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: a1c966bdf4174f238077784016854231033034cf
https://github.com/qemu/qemu/commit/a1c966bdf4174f238077784016854231033034cf
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M migration/tls.c
Log Message:
-----------
migration/tls: Use qcrypto_tls_creds_check_endpoint()
Avoid accessing QCryptoTLSCreds internals by using
the qcrypto_tls_creds_check_endpoint() helper.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 5590f65facc508fbc38575f19a0ab2fdcdcf18a4)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 43844c2fb2fffd0f710071259453714acb804c07
https://github.com/qemu/qemu/commit/43844c2fb2fffd0f710071259453714acb804c07
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M ui/vnc.c
Log Message:
-----------
ui/vnc: Use qcrypto_tls_creds_check_endpoint()
Avoid accessing QCryptoTLSCreds internals by using
the qcrypto_tls_creds_check_endpoint() helper.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 3c52bf0c608419d7892fea95f2a0af8f2e99633e)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 747fd3cb1336e482c2da31036cb2706e9c45074d
https://github.com/qemu/qemu/commit/747fd3cb1336e482c2da31036cb2706e9c45074d
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M crypto/tls-cipher-suites.c
M crypto/tlscredsanon.c
M crypto/tlscredspriv.h
M crypto/tlscredspsk.c
M crypto/tlscredsx509.c
M crypto/tlssession.c
M include/crypto/tls-cipher-suites.h
M include/crypto/tlscreds.h
M include/crypto/tlscredsanon.h
M include/crypto/tlscredspsk.h
M include/crypto/tlscredsx509.h
Log Message:
-----------
crypto: Make QCryptoTLSCreds* structures private
Code consuming the "crypto/tlscreds*.h" APIs doesn't need
to access its internals. Move the structure definitions to
the "tlscredspriv.h" private header (only accessible by
implementations). The public headers (in include/) still
forward-declare the structures typedef.
Note, tlscreds.c and 3 of the 5 modified source files already
include "tlscredspriv.h", so only add it to tls-cipher-suites.c
and tlssession.c.
Removing the internals from the public header solves a bug
introduced by commit 7de2e856533 ("yank: Unregister function
when using TLS migration") which made migration/qemu-file-channel.c
include "io/channel-tls.h", itself sometime depends on GNUTLS,
leading to a build failure on OSX:
[2/35] Compiling C object libmigration.fa.p/migration_qemu-file-channel.c.o
FAILED: libmigration.fa.p/migration_qemu-file-channel.c.o
cc -Ilibmigration.fa.p -I. -I.. -Iqapi [ ... ] -o
libmigration.fa.p/migration_qemu-file-channel.c.o -c
../migration/qemu-file-channel.c
In file included from ../migration/qemu-file-channel.c:29:
In file included from include/io/channel-tls.h:26:
In file included from include/crypto/tlssession.h:24:
include/crypto/tlscreds.h:28:10: fatal error: 'gnutls/gnutls.h' file not found
#include <gnutls/gnutls.h>
^~~~~~~~~~~~~~~~~
1 error generated.
Reported-by: Stefan Weil <sw@weilnetz.de>
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/407
Fixes: 7de2e856533 ("yank: Unregister function when using TLS migration")
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 678bcc3c2cf22262d0a72b52da57737c4a40e040)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 22de6752c12383e0778177fda314566d1d54b54f
https://github.com/qemu/qemu/commit/22de6752c12383e0778177fda314566d1d54b54f
Author: Leonardo Bras <leobras.c@gmail.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M migration/channel.c
M migration/multifd.c
M migration/qemu-file-channel.c
Log Message:
-----------
yank: Unregister function when using TLS migration
After yank feature was introduced in migration, whenever migration
is started using TLS, the following error happens in both source and
destination hosts:
(qemu) qemu-kvm: ../util/yank.c:107: yank_unregister_instance:
Assertion `QLIST_EMPTY(&entry->yankfns)' failed.
This happens because of a missing yank_unregister_function() when using
qio-channel-tls.
Fix this by also allowing TYPE_QIO_CHANNEL_TLS object type to perform
yank_unregister_function() in channel_close() and multifd_load_cleanup().
Also, inside migration_channel_connect() and
migration_channel_process_incoming() move yank_register_function() so
it only runs once on a TLS migration.
Fixes: b5eea99ec2f ("migration: Add yank feature", 2021-01-13)
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1964326
Signed-off-by: Leonardo Bras <leobras.c@gmail.com>
Reviewed-by: Lukas Straub <lukasstraub2@web.de>
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Changes since v2:
- Dropped all references to ioc->master
- yank_register_function() and yank_unregister_function() now only run
once in a TLS migration.
Changes since v1:
- Cast p->c to QIOChannelTLS into multifd_load_cleanup()
Message-Id: <20210601054030.1153249-1-leobras.c@gmail.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit 7de2e8565335c13fb3516cddbe2e40e366cce273)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: e23fe27ed9fa45d44b2234309565e42284165e86
https://github.com/qemu/qemu/commit/e23fe27ed9fa45d44b2234309565e42284165e86
Author: Igor Mammedov <imammedo@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests: acpi: prepare for changing DSDT tables
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20210624204229.998824-2-imammedo@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: John Sucaet <john.sucaet@ekinops.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a4344574fd47336b6d8fc85ce1f66d4262e7dafd)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: b989641145f079d487edce798b7557e47ee080a9
https://github.com/qemu/qemu/commit/b989641145f079d487edce798b7557e47ee080a9
Author: Igor Mammedov <imammedo@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/i386/acpi-build.c
Log Message:
-----------
acpi: pc: revert back to v5.2 PCI slot enumeration
Commit [1] moved _SUN variable from only hot-pluggable to
all devices. This made linux kernel enumerate extra slots
that weren't present before. If extra slot happens to be
be enumerated first and there is a device in th same slot
but on other bridge, linux kernel will add -N suffix to
slot name of the later, thus changing NIC name compared to
QEMU 5.2. This in some case confuses systemd, if it is
using SLOT NIC naming scheme and interface name becomes
not the same as it was under QEMU-5.2.
Reproducer QEMU CLI:
-M pc-i440fx-5.2 -nodefaults \
-device pci-bridge,chassis_nr=1,id=pci.1,bus=pci.0,addr=0x3 \
-device virtio-net-pci,id=nic1,bus=pci.1,addr=0x1 \
-device virtio-net-pci,id=nic2,bus=pci.1,addr=0x2 \
-device virtio-net-pci,id=nic3,bus=pci.1,addr=0x3
with RHEL8 guest produces following results:
v5.2:
kernel: virtio_net virtio0 ens1: renamed from eth0
kernel: virtio_net virtio2 ens3: renamed from eth2
kernel: virtio_net virtio1 enp1s2: renamed from eth1
(slot 2 is assigned to empty bus 0 slot and virtio1
is assigned to 2-2 slot, and renaming falls back,
for some reason, to path based naming scheme)
v6.0:
kernel: virtio_net virtio0 ens1: renamed from eth0
kernel: virtio_net virtio2 ens3: renamed from eth2
systemd-udevd[299]: Error changing net interface name 'eth1' to 'ens3':
File exists
systemd-udevd[299]: could not rename interface '3' from 'eth1' to 'ens3':
File exists
(with commit [1] kernel assigns virtio2 to 3-2 slot
since bridge advertises _SUN=0x3 and kernel assigns
slot 3 to bridge. Still it manages to rename virtio2
correctly to ens3, however systemd gets confused with virtio1
where slot allocation exactly the same (2-2) as in 5.2 case
and tries to rename it to ens3 which is rightfully taken by
virtio2)
I'm not sure what breaks in systemd interface renaming (it probably
should be investigated), but on QEMU side we can safely revert
_SUN to 5.2 behavior (i.e. avoid cold-plugged bridges and non
hot-pluggable device classes), without breaking acpi-index, which uses
slot numbers but it doesn't have to use _SUN, it could use an arbitrary
variable name that has the same slot value).
It will help existing VMs to keep networking with non trivial
configs in working order since systemd will do its interface
renaming magic as it used to do.
1)
Fixes: b7f23f62e40 (pci: acpi: add _DSM method to PCI devices)
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20210624204229.998824-3-imammedo@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: John Sucaet <john.sucaet@ekinops.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 7193d7cdd93e50f0e5f09803b98d27d3f9b147ac)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 765ed56e7606c0993e47619db38471d3210963c4
https://github.com/qemu/qemu/commit/765ed56e7606c0993e47619db38471d3210963c4
Author: Igor Mammedov <imammedo@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M tests/data/acpi/pc/DSDT
M tests/data/acpi/pc/DSDT.acpihmat
M tests/data/acpi/pc/DSDT.bridge
M tests/data/acpi/pc/DSDT.cphp
M tests/data/acpi/pc/DSDT.dimmpxm
M tests/data/acpi/pc/DSDT.hpbridge
M tests/data/acpi/pc/DSDT.ipmikcs
M tests/data/acpi/pc/DSDT.memhp
M tests/data/acpi/pc/DSDT.nohpet
M tests/data/acpi/pc/DSDT.numamem
M tests/qtest/bios-tables-test-allowed-diff.h
Log Message:
-----------
tests: acpi: pc: update expected DSDT blobs
@@ -930,20 +930,20 @@ DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPC ",
0x00000001)
Device (S00)
{
Name (_ADR, Zero) // _ADR: Address
- Name (_SUN, Zero) // _SUN: Slot User Number
+ Name (ASUN, Zero)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
- Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
+ Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
}
Device (S10)
{
Name (_ADR, 0x00020000) // _ADR: Address
- Name (_SUN, 0x02) // _SUN: Slot User Number
+ Name (ASUN, 0x02)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
- Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
+ Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
Method (_S1D, 0, NotSerialized) // _S1D: S1 Device State
with a hank per bridge:
@@ -965,10 +965,10 @@ DefinitionBlock ("", "DSDT", 1, "BOCHS ", "BXPC ",
0x00000001)
Device (S18)
{
Name (_ADR, 0x00030000) // _ADR: Address
- Name (_SUN, 0x03) // _SUN: Slot User Number
+ Name (ASUN, 0x03)
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
- Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, _SUN))
+ Return (PDSM (Arg0, Arg1, Arg2, Arg3, BSEL, ASUN))
}
}
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20210624204229.998824-4-imammedo@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: John Sucaet <john.sucaet@ekinops.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 40f23e4e52f6188036062abea432560e5cdd239a)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: aa99651295cf13aafa8db030c3cc1a0c1b64427d
https://github.com/qemu/qemu/commit/aa99651295cf13aafa8db030c3cc1a0c1b64427d
Author: Gollu Appalanaidu <anaidu.gollu@samsung.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/block/nvme-ns.c
M hw/block/nvme.c
M include/block/nvme.h
Log Message:
-----------
hw/block/nvme: align with existing style
While QEMU coding style prefers lowercase hexadecimals in constants, the
NVMe subsystem uses the format from the NVMe specifications in comments,
i.e. 'h' suffix instead of '0x' prefix.
Fix this up across the code base.
Signed-off-by: Gollu Appalanaidu <anaidu.gollu@samsung.com>
[k.jensen: updated message; added conversion in a couple of missing comments]
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit 312c3531bba416e589f106db8c8241fc6e7e6332)
*context dependency for 2b02aabc9d
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: bef905cd8a3eb0753262703ecebf2fae0658154b
https://github.com/qemu/qemu/commit/bef905cd8a3eb0753262703ecebf2fae0658154b
Author: Klaus Jensen <k.jensen@samsung.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/block/nvme.c
Log Message:
-----------
hw/nvme: fix missing check for PMR capability
Qiang Liu reported that an access on an unknown address is triggered in
memory_region_set_enabled because a check on CAP.PMRS is missing for the
PMRCTL register write when no PMR is configured.
Cc: qemu-stable@nongnu.org
Fixes: 75c3c9de961d ("hw/block/nvme: disable PMR at boot up")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/362
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Reviewed-by: Keith Busch <kbusch@kernel.org>
(cherry picked from commit 2b02aabc9d02f9e95946cf639f546bb61f1721b7)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 6576f6ab8726e52fbd9060224670683bc3e613d6
https://github.com/qemu/qemu/commit/6576f6ab8726e52fbd9060224670683bc3e613d6
Author: Klaus Jensen <k.jensen@samsung.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/block/nvme.c
M hw/block/nvme.h
Log Message:
-----------
hw/nvme: fix pin-based interrupt behavior (again)
Jakub noticed[1] that, when using pin-based interrupts, the device will
unconditionally deasssert when any CQEs are acknowledged. However, the
pin should not be deasserted if other completion queues still holds
unacknowledged CQEs.
The bug is an artifact of commit ca247d35098d ("hw/block/nvme: fix
pin-based interrupt behavior") which fixed one bug but introduced
another. This is the third time someone tries to fix pin-based
interrupts (see commit 5e9aa92eb1a5 ("hw/block: Fix pin-based interrupt
behaviour of NVMe"))...
Third time's the charm, so fix it, again, by keeping track of how many
CQs have unacknowledged CQEs and only deassert when all are cleared.
[1]: <20210610114624.304681-1-jakub.jermar@kernkonzept.com>
Cc: qemu-stable@nongnu.org
Fixes: ca247d35098d ("hw/block/nvme: fix pin-based interrupt behavior")
Reported-by: Jakub Jermář <jakub.jermar@kernkonzept.com>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
Reviewed-by: Keith Busch <kbusch@kernel.org>
(cherry picked from commit 83d7ed5c570d4c1d5163951b3057cac2ae7da4ff)
*avoid dependency on 88eea45c ("hw/nvme: move nvme emulation out of hw/block")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 7999d5b12f336b4b2064361c163e06878e5d20e8
https://github.com/qemu/qemu/commit/7999d5b12f336b4b2064361c163e06878e5d20e8
Author: David Hildenbrand <david@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: don't start free page hinting if postcopy is possible
Postcopy never worked properly with 'free-page-hint=on', as there are
at least two issues:
1) With postcopy, the guest will never receive a VIRTIO_BALLOON_CMD_ID_DONE
and consequently won't release free pages back to the OS once
migration finishes.
The issue is that for postcopy, we won't do a final bitmap sync while
the guest is stopped on the source and
virtio_balloon_free_page_hint_notify() will only call
virtio_balloon_free_page_done() on the source during
PRECOPY_NOTIFY_CLEANUP, after the VM state was already migrated to
the destination.
2) Once the VM touches a page on the destination that has been excluded
from migration on the source via qemu_guest_free_page_hint() while
postcopy is active, that thread will stall until postcopy finishes
and all threads are woken up. (with older Linux kernels that won't
retry faults when woken up via userfaultfd, we might actually get a
SEGFAULT)
The issue is that the source will refuse to migrate any pages that
are not marked as dirty in the dirty bmap -- for example, because the
page might just have been sent. Consequently, the faulting thread will
stall, waiting for the page to be migrated -- which could take quite
a while and result in guest OS issues.
While we could fix 1) comparatively easily, 2) is harder to get right and
might require more involved RAM migration changes on source and destination
[1].
As it never worked properly, let's not start free page hinting in the
precopy notifier if the postcopy migration capability was enabled to fix
it easily. Capabilities cannot be enabled once migration is already
running.
Note 1: in the future we might either adjust migration code on the source
to track pages that have actually been sent or adjust
migration code on source and destination to eventually send
pages multiple times from the source and and deal with pages
that are sent multiple times on the destination.
Note 2: virtio-mem has similar issues, however, access to "unplugged"
memory by the guest is very rare and we would have to be very
lucky for it to happen during migration. The spec states
"The driver SHOULD NOT read from unplugged memory blocks ..."
and "The driver MUST NOT write to unplugged memory blocks".
virtio-mem will move away from virtio_balloon_free_page_done()
soon and handle this case explicitly on the destination.
[1] https://lkml.kernel.org/r/e79fd18c-aa62-c1d8-c7f3-ba3fc2c25fc8@redhat.com
Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT")
Cc: qemu-stable@nongnu.org
Cc: Wei Wang <wei.w.wang@intel.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Juan Quintela <quintela@redhat.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20210708095339.20274-2-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit fd51e54fa10221e5a8add894c38cc1cf199f4bc4)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 4d3cfb2f6bb6afa07d0a9629136ae71eb6ab0268
https://github.com/qemu/qemu/commit/4d3cfb2f6bb6afa07d0a9629136ae71eb6ab0268
Author: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/net/can/can_sja1000.c
Log Message:
-----------
hw/net/can: sja1000 fix buff2frame_bas and buff2frame_pel when dlc is out of
std CAN 8 bytes
Problem reported by openEuler fuzz-sig group.
The buff2frame_bas function (hw\net\can\can_sja1000.c)
infoleak(qemu5.x~qemu6.x) or stack-overflow(qemu 4.x).
Reported-by: Qiang Ning <ningqiang1@huawei.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 11744862f27b9ba6488a247d2fd6bb83d9bc3c8d)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 21611dd0a5634946367137a30f52a7677ff75928
https://github.com/qemu/qemu/commit/21611dd0a5634946367137a30f52a7677ff75928
Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/sd/sd.c
Log Message:
-----------
hw/sd/sdcard: Document out-of-range addresses for SEND_WRITE_PROT
Per the 'Physical Layer Simplified Specification Version 3.01',
Table 4-22: 'Block Oriented Write Protection Commands'
SEND_WRITE_PROT (CMD30)
If the card provides write protection features, this command asks
the card to send the status of the write protection bits [1].
[1] 32 write protection bits (representing 32 write protect groups
starting at the specified address) [...]
The last (least significant) bit of the protection bits corresponds
to the first addressed group. If the addresses of the last groups
are outside the valid range, then the corresponding write protection
bits shall be set to 0.
Split the if() statement (without changing the behaviour of the code)
to better position the description comment.
Reviewed-by: Alexander Bulekov <alxndr@bu.edu>
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210802235524.3417739-2-f4bug@amsat.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
(cherry picked from commit 2a0396285daa9483459ec1d3791951300b595e85)
*context dependency for 4ac0b72bae ("hw/sd/sdcard: Fix assertion accessing
out-of-range addresses with CMD30")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 978c11b013bfd2a484c6b2ad0edb14bd754f23ac
https://github.com/qemu/qemu/commit/978c11b013bfd2a484c6b2ad0edb14bd754f23ac
Author: Philippe Mathieu-Daudé <f4bug@amsat.org>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M hw/sd/sd.c
Log Message:
-----------
hw/sd/sdcard: Fix assertion accessing out-of-range addresses with CMD30
OSS-Fuzz found sending illegal addresses when querying the write
protection bits triggers the assertion added in commit 84816fb63e5
("hw/sd/sdcard: Assert if accessing an illegal group"):
qemu-fuzz-i386-target-generic-fuzz-sdhci-v3: ../hw/sd/sd.c:824: uint32_t
sd_wpbits(SDState *, uint64_t):
Assertion `wpnum < sd->wpgrps_size' failed.
#3 0x7f62a8b22c91 in __assert_fail
#4 0x5569adcec405 in sd_wpbits hw/sd/sd.c:824:9
#5 0x5569adce5f6d in sd_normal_command hw/sd/sd.c:1389:38
#6 0x5569adce3870 in sd_do_command hw/sd/sd.c:1737:17
#7 0x5569adcf1566 in sdbus_do_command hw/sd/core.c:100:16
#8 0x5569adcfc192 in sdhci_send_command hw/sd/sdhci.c:337:12
#9 0x5569adcfa3a3 in sdhci_write hw/sd/sdhci.c:1186:9
#10 0x5569adfb3447 in memory_region_write_accessor softmmu/memory.c:492:5
It is legal for the CMD30 to query for out-of-range addresses.
Such invalid addresses are simply ignored in the response (write
protection bits set to 0).
In commit 84816fb63e5 ("hw/sd/sdcard: Assert if accessing an illegal
group") we misplaced the assertion *before* we test the address is
in range. Move it *after*.
Include the qtest reproducer provided by Alexander Bulekov:
$ make check-qtest-i386
...
Running test qtest-i386/fuzz-sdcard-test
qemu-system-i386: ../hw/sd/sd.c:824: sd_wpbits: Assertion `wpnum <
sd->wpgrps_size' failed.
Cc: qemu-stable@nongnu.org
Reported-by: OSS-Fuzz (Issue 29225)
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Fixes: 84816fb63e5 ("hw/sd/sdcard: Assert if accessing an illegal group")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/495
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20210802235524.3417739-3-f4bug@amsat.org>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Alexander Bulekov <alxndr@bu.edu>
(cherry picked from commit 4ac0b72bae85cf94ae0e5153b9c2c288c71667d4)
*drop fuzz test additions, since sdcard fuzz test has functional
dependency on guest-visible change not flagged for stable:
59b63d78 ("hw/sd/sdcard: Check for valid address range in SEND_WRITE_PROT
(CMD30)")
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 4fca33b4bec8afa8e902137c82a0f47a02134c13
https://github.com/qemu/qemu/commit/4fca33b4bec8afa8e902137c82a0f47a02134c13
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date: 2021-10-14 (Thu, 14 Oct 2021)
Changed paths:
M audio/audio.c
Log Message:
-----------
audio: Never send migration section
The audio migration vmstate is empty, and always has been; we can't
just remove it though because an old qemu might send it us.
Changes with -audiodev now mean it's sometimes created when it didn't
used to be, and can confuse migration to old qemu.
Change it so that vmstate_audio is never sent; if it's received it
should still be accepted, and old qemu's shouldn't be too upset if it's
missing.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20210809170956.78536-1-dgilbert@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit da77adbaf619c4d170cb42d769145ad1803fbad9)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 2ae61d81a575d22599fb22355acc995def2902fc
https://github.com/qemu/qemu/commit/2ae61d81a575d22599fb22355acc995def2902fc
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2021-10-15 (Fri, 15 Oct 2021)
Changed paths:
M target/arm/cpu.c
Log Message:
-----------
target/arm: Don't skip M-profile reset entirely in user mode
Currently all of the M-profile specific code in arm_cpu_reset() is
inside a !defined(CONFIG_USER_ONLY) ifdef block. This is
unintentional: it happened because originally the only
M-profile-specific handling was the setup of the initial SP and PC
from the vector table, which is system-emulation only. But then we
added a lot of other M-profile setup to the same "if (ARM_FEATURE_M)"
code block without noticing that it was all inside a not-user-mode
ifdef. This has generally been harmless, but with the addition of
v8.1M low-overhead-loop support we ran into a problem: the reset of
FPSCR.LTPSIZE to 4 was only being done for system emulation mode, so
if a user-mode guest tried to execute the LE instruction it would
incorrectly take a UsageFault.
Adjust the ifdefs so only the really system-emulation specific parts
are covered. Because this means we now run some reset code that sets
up initial values in the FPCCR and similar FPU related registers,
explicitly set up the registers controlling FPU context handling in
user-emulation mode so that the FPU works by design and not by
chance.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/613
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20210914120725.24992-2-peter.maydell@linaro.org
(cherry picked from commit b62ceeaf8096fdbbbfdc6087da0028bc4a4dd77e)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 5881d76ff41ab898751babdf26ea668cb8fb7a0e
https://github.com/qemu/qemu/commit/5881d76ff41ab898751babdf26ea668cb8fb7a0e
Author: Jason Wang <jasowang@redhat.com>
Date: 2021-10-15 (Fri, 15 Oct 2021)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
virtio-net: fix use after unmap/free for sg
When mergeable buffer is enabled, we try to set the num_buffers after
the virtqueue elem has been unmapped. This will lead several issues,
E.g a use after free when the descriptor has an address which belongs
to the non direct access region. In this case we use bounce buffer
that is allocated during address_space_map() and freed during
address_space_unmap().
Fixing this by storing the elems temporarily in an array and delay the
unmap after we set the the num_buffers.
This addresses CVE-2021-3748.
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Fixes: fbe78f4f55c6 ("virtio-net support")
Cc: qemu-stable@nongnu.org
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit bedd7e93d01961fcb16a97ae45d93acf357e11f6)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 916372e48faf47ce0950d4cf2ae7d0b63c803227
https://github.com/qemu/qemu/commit/916372e48faf47ce0950d4cf2ae7d0b63c803227
Author: Nir Soffer <nirsof@gmail.com>
Date: 2021-10-15 (Fri, 15 Oct 2021)
Changed paths:
M docs/tools/qemu-nbd.rst
M qemu-nbd.c
Log Message:
-----------
qemu-nbd: Change default cache mode to writeback
Both qemu and qemu-img use writeback cache mode by default, which is
already documented in qemu(1). qemu-nbd uses writethrough cache mode by
default, and the default cache mode is not documented.
According to the qemu-nbd(8):
--cache=CACHE
The cache mode to be used with the file. See the
documentation of the emulator's -drive cache=... option for
allowed values.
qemu(1) says:
The default mode is cache=writeback.
So users have no reason to assume that qemu-nbd is using writethough
cache mode. The only hint is the painfully slow writing when using the
defaults.
Looking in git history, it seems that qemu used writethrough in the past
to support broken guests that did not flush data properly, or could not
flush due to limitations in qemu. But qemu-nbd clients can use
NBD_CMD_FLUSH to flush data, so using writethrough does not help anyone.
Change the default cache mode to writback, and document the default and
available values properly in the online help and manual.
With this change converting image via qemu-nbd is 3.5 times faster.
$ qemu-img create dst.img 50g
$ qemu-nbd -t -f raw -k /tmp/nbd.sock dst.img
Before this change:
$ hyperfine -r3 "./qemu-img convert -p -f raw -O raw -T none -W
fedora34.img nbd+unix:///?socket=/tmp/nbd.sock"
Benchmark #1: ./qemu-img convert -p -f raw -O raw -T none -W fedora34.img
nbd+unix:///?socket=/tmp/nbd.sock
Time (mean ± σ): 83.639 s ± 5.970 s [User: 2.733 s, System: 6.112
s]
Range (min … max): 76.749 s … 87.245 s 3 runs
After this change:
$ hyperfine -r3 "./qemu-img convert -p -f raw -O raw -T none -W
fedora34.img nbd+unix:///?socket=/tmp/nbd.sock"
Benchmark #1: ./qemu-img convert -p -f raw -O raw -T none -W fedora34.img
nbd+unix:///?socket=/tmp/nbd.sock
Time (mean ± σ): 23.522 s ± 0.433 s [User: 2.083 s, System: 5.475
s]
Range (min … max): 23.234 s … 24.019 s 3 runs
Users can avoid the issue by using --cache=writeback[1] but the defaults
should give good performance for the common use case.
[1] https://bugzilla.redhat.com/1990656
Signed-off-by: Nir Soffer <nsoffer@redhat.com>
Message-Id: <20210813205519.50518-1-nsoffer@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
CC: qemu-stable@nongnu.org
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 09615257058a0ae87b837bb041f56f7312d9ead8)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: f22c225e2359429508d65f581b9bdf457a0ac069
https://github.com/qemu/qemu/commit/f22c225e2359429508d65f581b9bdf457a0ac069
Author: Markus Armbruster <armbru@redhat.com>
Date: 2021-10-15 (Fri, 15 Oct 2021)
Changed paths:
M monitor/hmp-cmds.c
Log Message:
-----------
hmp: Unbreak "change vnc"
HMP command "change vnc" can take the password as argument, or prompt
for it:
(qemu) change vnc password 123
(qemu) change vnc password
Password: ***
(qemu)
This regressed in commit cfb5387a1d "hmp: remove "change vnc TARGET"
command", v6.0.0.
(qemu) change vnc passwd 123
Password: ***
(qemu) change vnc passwd
(qemu)
The latter passes NULL to qmp_change_vnc_password(), which is a no-no.
Looks like it puts the display into "password required, but none set"
state.
The logic error is easy to miss in review, but testing should've
caught it.
Fix the obvious way.
Fixes: cfb5387a1de2acda23fb5c97d2378b9e7ddf8025
Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210909081219.308065-2-armbru@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
(cherry picked from commit 6193344f9337f8b76cd44ce94a32c9900d907d35)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 5a964fe8d93efd9c42c72a6244bd23039380eb59
https://github.com/qemu/qemu/commit/5a964fe8d93efd9c42c72a6244bd23039380eb59
Author: David Hildenbrand <david@redhat.com>
Date: 2021-10-15 (Fri, 15 Oct 2021)
Changed paths:
M hw/virtio/virtio-mem-pci.c
Log Message:
-----------
virtio-mem-pci: Fix memory leak when creating MEMORY_DEVICE_SIZE_CHANGE event
Apparently, we don't have to duplicate the string.
Fixes: 722a3c783ef4 ("virtio-pci: Send qapi events when the virtio-mem size
changes")
Cc: qemu-stable@nongnu.org
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210929162445.64060-2-david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 75b98cb9f6456ccf194211beffcbf93b0a995fa4)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 36403e8788a264dc96174f52584681ebcb4f54b1
https://github.com/qemu/qemu/commit/36403e8788a264dc96174f52584681ebcb4f54b1
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M hw/usb/dev-uas.c
Log Message:
-----------
uas: add stream number sanity checks.
The device uses the guest-supplied stream number unchecked, which can
lead to guest-triggered out-of-band access to the UASDevice->data3 and
UASDevice->status3 fields. Add the missing checks.
Fixes: CVE-2021-3713
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reported-by: Chen Zhe <chenzhe@huawei.com>
Reported-by: Tan Jingguo <tanjingguo@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210818120505.1258262-2-kraxel@redhat.com>
(cherry picked from commit 13b250b12ad3c59114a6a17d59caf073ce45b33a)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 606f618b3c1d517edaf145cd8648a9b5ae3fc941
https://github.com/qemu/qemu/commit/606f618b3c1d517edaf145cd8648a9b5ae3fc941
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M hw/usb/redirect.c
Log Message:
-----------
usb/redir: avoid dynamic stack allocation (CVE-2021-3527)
Use autofree heap allocation instead.
Fixes: 4f4321c11ff ("usb: use iovecs in USBPacket")
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210503132915.2335822-3-kraxel@redhat.com>
(cherry picked from commit 7ec54f9eb62b5d177e30eb8b1cad795a5f8d8986)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: e204dca909ed2fe5aa18f03c973e3ad6cff98595
https://github.com/qemu/qemu/commit/e204dca909ed2fe5aa18f03c973e3ad6cff98595
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M hw/usb/combined-packet.c
Log Message:
-----------
usb: limit combined packets to 1 MiB (CVE-2021-3527)
usb-host and usb-redirect try to batch bulk transfers by combining many
small usb packets into a single, large transfer request, to reduce the
overhead and improve performance.
This patch adds a size limit of 1 MiB for those combined packets to
restrict the host resources the guest can bind that way.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210503132915.2335822-6-kraxel@redhat.com>
(cherry picked from commit 05a40b172e4d691371534828078be47e7fff524c)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 168299eb7ddcee4b337d4e635ef98784ca9a5804
https://github.com/qemu/qemu/commit/168299eb7ddcee4b337d4e635ef98784ca9a5804
Author: Li Qiang <liq3ea@163.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M contrib/vhost-user-gpu/virgl.c
Log Message:
-----------
vhost-user-gpu: fix memory disclosure in virgl_cmd_get_capset_info
(CVE-2021-3545)
Otherwise some of the 'resp' will be leaked to guest.
Fixes: CVE-2021-3545
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 42a8dadc74 ("virtio-gpu: fix information leak
in getting capset info dispatch")
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-2-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 121841b25d72d13f8cad554363138c360f1250ea)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: c5300b8a94105dee1c44ac49d2bb3b35412b5ae6
https://github.com/qemu/qemu/commit/c5300b8a94105dee1c44ac49d2bb3b35412b5ae6
Author: Li Qiang <liq3ea@163.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M contrib/vhost-user-gpu/vhost-user-gpu.c
Log Message:
-----------
vhost-user-gpu: fix resource leak in 'vg_resource_create_2d' (CVE-2021-3544)
Call 'vugbm_buffer_destroy' in error path to avoid resource leak.
Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-3-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 86dd8fac2acc366930a5dc08d3fb1b1e816f4e1e)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 6ae68dfd10e53466e341f8330e0c8f9f10bd5d54
https://github.com/qemu/qemu/commit/6ae68dfd10e53466e341f8330e0c8f9f10bd5d54
Author: Li Qiang <liq3ea@163.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M contrib/vhost-user-gpu/vhost-user-gpu.c
Log Message:
-----------
vhost-user-gpu: fix memory leak in vg_resource_attach_backing (CVE-2021-3544)
Check whether the 'res' has already been attach_backing to avoid
memory leak.
Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 204f01b309 ("virtio-gpu: fix memory leak
in resource attach backing")
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-4-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit b9f79858a614d95f5de875d0ca31096eaab72c3b)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 457053998df9ab77fa82360bbe3115263063e17a
https://github.com/qemu/qemu/commit/457053998df9ab77fa82360bbe3115263063e17a
Author: Li Qiang <liq3ea@163.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M contrib/vhost-user-gpu/vhost-user-gpu.c
Log Message:
-----------
vhost-user-gpu: fix memory leak while calling 'vg_resource_unref'
(CVE-2021-3544)
If the guest trigger following sequences, the attach_backing will be leaked:
vg_resource_create_2d
vg_resource_attach_backing
vg_resource_unref
This patch fix this by freeing 'res->iov' in vg_resource_destroy.
Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 5e8e3c4c75 ("virtio-gpu: fix resource leak
in virgl_cmd_resource_unref")
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-5-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit b7afebcf9e6ecf3cf9b5a9b9b731ed04bca6aa3e)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 4dda63d7edea4374dd3f5ec9982c255a6ec54d37
https://github.com/qemu/qemu/commit/4dda63d7edea4374dd3f5ec9982c255a6ec54d37
Author: Li Qiang <liq3ea@163.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M contrib/vhost-user-gpu/virgl.c
Log Message:
-----------
vhost-user-gpu: fix memory leak in 'virgl_cmd_resource_unref' (CVE-2021-3544)
The 'res->iov' will be leaked if the guest trigger following sequences:
virgl_cmd_create_resource_2d
virgl_resource_attach_backing
virgl_cmd_resource_unref
This patch fixes this.
Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 5e8e3c4c75 ("virtio-gpu: fix resource leak
in virgl_cmd_resource_unref"
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-6-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit f6091d86ba9ea05f4e111b9b42ee0005c37a6779)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 07daff4a9a5f9dd6e79e3aa4a9664aee3156bd7d
https://github.com/qemu/qemu/commit/07daff4a9a5f9dd6e79e3aa4a9664aee3156bd7d
Author: Li Qiang <liq3ea@163.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M contrib/vhost-user-gpu/virgl.c
Log Message:
-----------
vhost-user-gpu: fix memory leak in 'virgl_resource_attach_backing'
(CVE-2021-3544)
If 'virgl_renderer_resource_attach_iov' failed, the 'res_iovs' will
be leaked.
Fixes: CVE-2021-3544
Reported-by: Li Qiang <liq3ea@163.com>
virtio-gpu fix: 33243031da ("virtio-gpu-3d: fix memory leak
in resource attach backing")
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-7-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 63736af5a6571d9def93769431e0d7e38c6677bf)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 4787501893f8b18e84f4d72ccbea4854ad9f5c9b
https://github.com/qemu/qemu/commit/4787501893f8b18e84f4d72ccbea4854ad9f5c9b
Author: Li Qiang <liq3ea@163.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M contrib/vhost-user-gpu/virgl.c
Log Message:
-----------
vhost-user-gpu: fix OOB write in 'virgl_cmd_get_capset' (CVE-2021-3546)
If 'virgl_cmd_get_capset' set 'max_size' to 0,
the 'virgl_renderer_fill_caps' will write the data after the 'resp'.
This patch avoid this by checking the returned 'max_size'.
virtio-gpu fix: abd7f08b23 ("display: virtio-gpu-3d: check
virgl capabilities max_size")
Fixes: CVE-2021-3546
Reported-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Li Qiang <liq3ea@163.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20210516030403.107723-8-liq3ea@163.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 9f22893adcb02580aee5968f32baa2cd109b3ec2)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: d25db58213557663140afb57bf3416b93a93a3e6
https://github.com/qemu/qemu/commit/d25db58213557663140afb57bf3416b93a93a3e6
Author: Marcel Apfelbaum <marcel@redhat.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M hw/rdma/vmw/pvrdma_cmd.c
Log Message:
-----------
hw/rdma: Fix possible mremap overflow in the pvrdma device (CVE-2021-3582)
Ensure mremap boundaries not trusting the guest kernel to
pass the correct buffer length.
Fixes: CVE-2021-3582
Reported-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Tested-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <20210616110600.20889-1-marcel.apfelbaum@gmail.com>
Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Reviewed-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
(cherry picked from commit 284f191b4abad213aed04cb0458e1600fd18d7c4)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 46d3c9e9f5b067a784f24a40134ed9a97e145094
https://github.com/qemu/qemu/commit/46d3c9e9f5b067a784f24a40134ed9a97e145094
Author: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M hw/rdma/vmw/pvrdma_main.c
Log Message:
-----------
pvrdma: Ensure correct input on ring init (CVE-2021-3607)
Check the guest passed a non zero page count
for pvrdma device ring buffers.
Fixes: CVE-2021-3607
Reported-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Reviewed-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <20210630114634.2168872-1-marcel@redhat.com>
Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
(cherry picked from commit 32e5703cfea07c91e6e84bcb0313f633bb146534)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Commit: 27c6f20d9d8725ddd4d0744022c4a66ec4878c6d
https://github.com/qemu/qemu/commit/27c6f20d9d8725ddd4d0744022c4a66ec4878c6d
Author: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Date: 2021-10-17 (Sun, 17 Oct 2021)
Changed paths:
M hw/rdma/vmw/pvrdma_dev_ring.c
Log Message:
-----------
pvrdma: Fix the ring init error flow (CVE-2021-3608)
Do not unmap uninitialized dma addresses.
Fixes: CVE-2021-3608
Reviewed-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Tested-by: VictorV (Kunlun Lab) <vv474172261@gmail.com>
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <20210630115246.2178219-1-marcel@redhat.com>
Tested-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Reviewed-by: Yuval Shaia <yuval.shaia.ml@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
(cherry picked from commit 66ae37d8cc313f89272e711174a846a229bcdbd3)
Signed-off-by: Michael Roth <michael.roth@amd.com>
Compare: https://github.com/qemu/qemu/compare/1513997aa2aa%5E...27c6f20d9d87
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 151399: multi-process: Initialize variables declared with ...,
Marcel Apfelbaum <=