[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 85df33: block/nbd: extract the common cleanup
|
From: |
Michael Roth |
|
Subject: |
[Qemu-commits] [qemu/qemu] 85df33: block/nbd: extract the common cleanup code |
|
Date: |
Thu, 25 Jun 2020 18:00:28 -0700 |
Branch: refs/heads/stable-4.2
Home: https://github.com/qemu/qemu
Commit: 85df33073ae957ebe744d1f6eeabc7fe6151c301
https://github.com/qemu/qemu/commit/85df33073ae957ebe744d1f6eeabc7fe6151c301
Author: Pan Nengyuan <pannengyuan@huawei.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M block/nbd.c
Log Message:
-----------
block/nbd: extract the common cleanup code
The BDRVNBDState cleanup code is common in two places, add
nbd_clear_bdrvstate() function to do these cleanups.
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <1575517528-44312-2-git-send-email-pannengyuan@huawei.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: fix compilation error and commit message]
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 7f493662be4045146a8f45119d8834c9088a0ad6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: a115daadf63a3c5d7f37d6e5864a3e8a247dbe32
https://github.com/qemu/qemu/commit/a115daadf63a3c5d7f37d6e5864a3e8a247dbe32
Author: Pan Nengyuan <pannengyuan@huawei.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M block/nbd.c
Log Message:
-----------
block/nbd: fix memory leak in nbd_open()
In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to
reproduce:
1. run qemu-iotests as follow and check the result with asan:
./check -raw 143
Following is the asan output backtrack:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7f6295e7e015 in g_malloc0 (/usr/lib64/libglib-2.0.so.0+0x50015)
#2 0x56281dab4642 in qobject_input_start_struct
/mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
#3 0x56281dab1a04 in visit_start_struct
/mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
#4 0x56281dad1827 in visit_type_SocketAddress qapi/qapi-visit-sockets.c:386
#5 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#6 0x56281da8062f in nbd_process_options
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#7 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Direct leak of 15 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281da804ac in nbd_process_options
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
#4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281dab41a3 in qobject_input_type_str_keyval
/mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
#4 0x56281dab2ee9 in visit_type_str
/mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
#5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members
qapi/qapi-visit-sockets.c:141
#6 0x56281dad17b6 in visit_type_SocketAddress_members
qapi/qapi-visit-sockets.c:366
#7 0x56281dad186a in visit_type_SocketAddress qapi/qapi-visit-sockets.c:393
#8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#9 0x56281da8062f in nbd_process_options
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
Fixes: 8f071c9db506e03ab
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <1575517528-44312-3-git-send-email-pannengyuan@huawei.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 8198cf5ef0ef98118b4176970d1cd998d93ec849)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: bed590f2b849ad548d659942771d824c288c6a50
https://github.com/qemu/qemu/commit/bed590f2b849ad548d659942771d824c288c6a50
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M qemu-deprecated.texi
M target/i386/cpu.c
Log Message:
-----------
i386: Resolve CPU models to v1 by default
When using `query-cpu-definitions` using `-machine none`,
QEMU is resolving all CPU models to their latest versions. The
actual CPU model version being used by another machine type (e.g.
`pc-q35-4.0`) might be different.
In theory, this was OK because the correct CPU model
version is returned when using the correct `-machine` argument.
Except that in practice, this breaks libvirt expectations:
libvirt always use `-machine none` when checking if a CPU model
is runnable, because runnability is not expected to be affected
when the machine type is changed.
For example, when running on a Haswell host without TSX,
Haswell-v4 is runnable, but Haswell-v1 is not. On those hosts,
`query-cpu-definitions` says Haswell is runnable if using
`-machine none`, but Haswell is actually not runnable using any
of the `pc-*` machine types (because they resolve Haswell to
Haswell-v1). In other words, we're breaking the "runnability
guarantee" we promised to not break for a few releases (see
qemu-deprecated.texi).
To address this issue, change the default CPU model version to v1
on all machine types, so we make `query-cpu-definitions` output
when using `-machine none` match the results when using `pc-*`.
This will change in the future (the plan is to always return the
latest CPU model version if using `-machine none`), but only
after giving libvirt the opportunity to adapt.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1779078
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20191205223339.764534-1-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit ad18392892c04637fb56956d997f4bc600224356)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: d636d64b3509ae1cd93931ca3b1ab13afe72ff62
https://github.com/qemu/qemu/commit/d636d64b3509ae1cd93931ca3b1ab13afe72ff62
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M qapi/block-core.json
Log Message:
-----------
qapi: better document NVMe blockdev @device parameter
Mention that this is a PCI device address & give the format it is
expected in. Also mention that it must be first unbound from any
host kernel driver.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit ecaf647f300d69271c245a67adca9c3a89d9463a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: da0948d13ccc4553fec74002c8fc39392a11d5e4
https://github.com/qemu/qemu/commit/da0948d13ccc4553fec74002c8fc39392a11d5e4
Author: Alex Bennée <alex.bennee@linaro.org>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M target/arm/cpu.h
M target/arm/helper.c
M target/arm/helper.h
M target/arm/translate.c
Log Message:
-----------
target/arm: ensure we use current exception state after SCR update
A write to the SCR can change the effective EL by droppping the system
from secure to non-secure mode. However if we use a cached current_el
from before the change we'll rebuild the flags incorrectly. To fix
this we introduce the ARM_CP_NEWEL CP flag to indicate the new EL
should be used when recomputing the flags.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20191212114734.6962-1-alex.bennee@linaro.org
Cc: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20191209143723.6368-1-alex.bennee@linaro.org>
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit f80741d107673f162e3b097fc76a1590036cc9d1)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 52a02834e0d54d59d9665e2d39c2259345df2335
https://github.com/qemu/qemu/commit/52a02834e0d54d59d9665e2d39c2259345df2335
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M block.c
Log Message:
-----------
block: Activate recursively even for already active nodes
bdrv_invalidate_cache_all() assumes that all nodes in a given subtree
are either active or inactive when it starts. Therefore, as soon as it
arrives at an already active node, it stops.
However, this assumption is wrong. For example, it's possible to take a
snapshot of an inactive node, which results in an active overlay over an
inactive backing file. The active overlay is probably also the root node
of an inactive BlockBackend (blk->disable_perm == true).
In this case, bdrv_invalidate_cache_all() does not need to do anything
to activate the overlay node, but it still needs to recurse into the
children and the parents to make sure that after returning success,
really everything is activated.
Cc: qemu-stable@nongnu.org
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 7bb4941ace471fc7dd6ded4749b95b9622baa6ed)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: def30090ad7917c9a6c68065922759dd83900d6f
https://github.com/qemu/qemu/commit/def30090ad7917c9a6c68065922759dd83900d6f
Author: Li Hangjing <lihangjing@baidu.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M hw/block/dataplane/virtio-blk.c
Log Message:
-----------
virtio-blk: fix out-of-bounds access to bitmap in notify_guest_bh
When the number of a virtio-blk device's virtqueues is larger than
BITS_PER_LONG, the out-of-bounds access to bitmap[ ] will occur.
Fixes: e21737ab15 ("virtio-blk: multiqueue batch notify")
Cc: qemu-stable@nongnu.org
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Li Hangjing <lihangjing@baidu.com>
Reviewed-by: Xie Yongji <xieyongji@baidu.com>
Reviewed-by: Chai Wen <chaiwen@baidu.com>
Message-id: 20191216023050.48620-1-lihangjing@baidu.com
Message-Id: <20191216023050.48620-1-lihangjing@baidu.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 725fe5d10dbd4259b1853b7d253cef83a3c0d22a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 89eebb016dcedf08c26940dcecdab3db026e9e2c
https://github.com/qemu/qemu/commit/89eebb016dcedf08c26940dcecdab3db026e9e2c
Author: Igor Mammedov <imammedo@redhat.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M hw/core/numa.c
Log Message:
-----------
numa: remove not needed check
Currently parse_numa_node() is always called from already numa
enabled context.
Drop unnecessary check if numa is supported.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1576154936-178362-2-git-send-email-imammedo@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit 5275db59aa7ff8a26bd6aa5d07cb4d53de5cfab5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: cbdfd3865bce5ca48ae4916d9a54461dbe99f49d
https://github.com/qemu/qemu/commit/cbdfd3865bce5ca48ae4916d9a54461dbe99f49d
Author: Igor Mammedov <imammedo@redhat.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M hw/arm/sbsa-ref.c
M hw/core/machine.c
Log Message:
-----------
numa: properly check if numa is supported
Commit aa57020774b, by mistake used MachineClass::numa_mem_supported
to check if NUMA is supported by machine and also as unrelated change
set it to true for sbsa-ref board.
Luckily change didn't break machines that support NUMA, as the field
is set to true for them.
But the field is not intended for checking if NUMA is supported and
will be flipped to false within this release for new machine types.
Fix it:
- by using previously used condition
!mc->cpu_index_to_instance_props || !mc->get_default_cpu_node_id
the first time and then use MachineState::numa_state down the road
to check if NUMA is supported
- dropping stray sbsa-ref chunk
Fixes: aa57020774b690a22be72453b8e91c9b5a68c516
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <1576154936-178362-3-git-send-email-imammedo@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit fcd3f2cc124600385dba46c69a80626985c15b50)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 2215837fe235af0f92246cc03be1782cdf35d724
https://github.com/qemu/qemu/commit/2215837fe235af0f92246cc03be1782cdf35d724
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M block/backup-top.c
Log Message:
-----------
backup-top: Begin drain earlier
When dropping backup-top, we need to drain the node before freeing the
BlockCopyState. Otherwise, requests may still be in flight and then the
assertion in shres_destroy() will fail.
(This becomes visible in intermittent failure of 056.)
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20191219182638.104621-1-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 503ca1262bab2c11c533a4816d1ff4297d4f58a6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: a5f815514ae21216962baf3c3f9730ab0a2318c0
https://github.com/qemu/qemu/commit/a5f815514ae21216962baf3c3f9730ab0a2318c0
Author: Niek Linnenbank <nieklinnenbank@gmail.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M target/arm/arm-powerctl.c
Log Message:
-----------
arm/arm-powerctl: set NSACR.{CP11, CP10} bits in arm_set_cpu_on()
This change ensures that the FPU can be accessed in Non-Secure mode
when the CPU core is reset using the arm_set_cpu_on() function call.
The NSACR.{CP11,CP10} bits define the exception level required to
access the FPU in Non-Secure mode. Without these bits set, the CPU
will give an undefined exception trap on the first FPU access for the
secondary cores under Linux.
This is necessary because in this power-control codepath QEMU
is effectively emulating a bit of EL3 firmware, and has to set
the CPU up as the EL3 firmware would.
Fixes: fc1120a7f5
Cc: qemu-stable@nongnu.org
Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com>
[PMM: added clarifying para to commit message]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 0c7f8c43daf6556078e51de98aa13f069e505985)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: ba6a94e64e9602ab9539a6464405b73b8b50ffda
https://github.com/qemu/qemu/commit/ba6a94e64e9602ab9539a6464405b73b8b50ffda
Author: Niek Linnenbank <nieklinnenbank@gmail.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M target/arm/arm-powerctl.c
Log Message:
-----------
arm/arm-powerctl: rebuild hflags after setting CP15 bits in arm_set_cpu_on()
After setting CP15 bits in arm_set_cpu_on() the cached hflags must
be rebuild to reflect the changed processor state. Without rebuilding,
the cached hflags would be inconsistent until the next call to
arm_rebuild_hflags(). When QEMU is compiled with debugging enabled
(--enable-debug), this problem is captured shortly after the first
call to arm_set_cpu_on() for CPUs running in ARM 32-bit non-secure mode:
qemu-system-arm: target/arm/helper.c:11359: cpu_get_tb_cpu_state:
Assertion `flags == rebuild_hflags_internal(env)' failed.
Aborted (core dumped)
Fixes: 0c7f8c43daf65
Cc: qemu-stable@nongnu.org
Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit c8fa6079eb35888587f1be27c1590da4edcc5098)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 0cfa46da8f175fbe16c1ad362282d59ccd9f026d
https://github.com/qemu/qemu/commit/0cfa46da8f175fbe16c1ad362282d59ccd9f026d
Author: Peter Wu <peter@lekensteyn.nl>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M hw/i386/x86.c
Log Message:
-----------
hw/i386/pc: fix regression in parsing vga cmdline parameter
When the 'vga=' parameter is succeeded by another parameter, QEMU 4.2.0
would refuse to start with a rather cryptic message:
$ qemu-system-x86_64 -kernel /boot/vmlinuz-linux -append 'vga=792 quiet'
qemu: can't parse 'vga' parameter: Invalid argument
It was not clear whether this applied to the '-vga std' parameter or the
'-append' one. Fix the parsing regression and clarify the error.
Fixes: 133ef074bd ("hw/i386/pc: replace use of strtol with qemu_strtoui in
x86_load_linux()")
Cc: Sergio Lopez <slp@redhat.com>
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Message-Id: <20191221162124.1159291-1-peter@lekensteyn.nl>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit a88c40f02ace88f09b2a85a64831b277b2ebc88c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 3a94a8b7fd5cb500ee604b5aa609c238cea07a7c
https://github.com/qemu/qemu/commit/3a94a8b7fd5cb500ee604b5aa609c238cea07a7c
Author: Alexander Popov <alex.popov@linux.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M tests/ide-test.c
Log Message:
-----------
tests/ide-test: Create a single unit-test covering more PRDT cases
Fuzzing the Linux kernel with syzkaller allowed to find how to crash qemu
using a special SCSI_IOCTL_SEND_COMMAND. It hits the assertion in
ide_dma_cb() introduced in the commit a718978ed58a in July 2015.
Currently this bug is not reproduced by the unit tests.
Let's improve the ide-test to cover more PRDT cases including one
that causes this particular qemu crash.
The test is developed according to the Programming Interface for
Bus Master IDE Controller (Revision 1.0 5/16/94).
Signed-off-by: Alexander Popov <alex.popov@linux.com>
Message-id: 20191223175117.508990-3-alex.popov@linux.com
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 59805ae92dfe4f67105e36b539d567caec4f8304)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4412cb3bcaf5b0cccf88f881c18be5dfd395e934
https://github.com/qemu/qemu/commit/4412cb3bcaf5b0cccf88f881c18be5dfd395e934
Author: Alexander Popov <alex.popov@linux.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M hw/ide/core.c
Log Message:
-----------
ide: Fix incorrect handling of some PRDTs in ide_dma_cb()
The commit a718978ed58a from July 2015 introduced the assertion which
implies that the size of successful DMA transfers handled in ide_dma_cb()
should be multiple of 512 (the size of a sector). But guest systems can
initiate DMA transfers that don't fit this requirement.
For fixing that let's check the number of bytes prepared for the transfer
by the prepare_buf() handler. The code in ide_dma_cb() must behave
according to the Programming Interface for Bus Master IDE Controller
(Revision 1.0 5/16/94):
1. If PRDs specified a smaller size than the IDE transfer
size, then the Interrupt and Active bits in the Controller
status register are not set (Error Condition).
2. If the size of the physical memory regions was equal to
the IDE device transfer size, the Interrupt bit in the
Controller status register is set to 1, Active bit is set to 0.
3. If PRDs specified a larger size than the IDE transfer size,
the Interrupt and Active bits in the Controller status register
are both set to 1.
Signed-off-by: Alexander Popov <alex.popov@linux.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 20191223175117.508990-2-alex.popov@linux.com
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit ed78352a59ea7acf7520d4d47a96b9911bae7fc3)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 77d9c84d9fd9f846a2ee5ba04bf2e3b33354e3e2
https://github.com/qemu/qemu/commit/77d9c84d9fd9f846a2ee5ba04bf2e3b33354e3e2
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Set ISSIs16Bit in make_issinfo
During the conversion to decodetree, the setting of
ISSIs16Bit got lost. This causes the guest os to
incorrectly adjust trapping memory operations.
Cc: qemu-stable@nongnu.org
Fixes: 46beb58efbb8a2a32 ("target/arm: Convert T16, load (literal)")
Reported-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200117004618.2742-3-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 1a1fbc6cbb34c26d43d8360c66c1d21681af14a9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 2f4affb7213ab0003bc2fa8f0d467399059106de
https://github.com/qemu/qemu/commit/2f4affb7213ab0003bc2fa8f0d467399059106de
Author: Michael S. Tsirkin <mst@redhat.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M hw/virtio/virtio-pci.c
Log Message:
-----------
virtio: update queue size on guest write
Some guests read back queue size after writing it.
Update the size immediatly upon write otherwise
they get confused.
In particular this is the case for seabios.
Reported-by: Roman Kagan <rkagan@virtuozzo.com>
Suggested-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d0c5f643383b9e84316f148affff368ac33d75b9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 0253531824d1a0ef39cba3da3bdb1bb161834fd4
https://github.com/qemu/qemu/commit/0253531824d1a0ef39cba3da3bdb1bb161834fd4
Author: Denis Plotnikov <dplotnikov@virtuozzo.com>
Date: 2020-05-11 (Mon, 11 May 2020)
Changed paths:
M hw/virtio/virtio-mmio.c
Log Message:
-----------
virtio-mmio: update queue size on guest write
Some guests read back queue size after writing it.
Always update the on size write otherwise they might be confused.
Cc: qemu-stable@nongnu.org
Signed-off-by: Denis Plotnikov <dplotnikov@virtuozzo.com>
Message-Id: <20191224081446.17003-1-dplotnikov@virtuozzo.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 1049f4c62c4070618cc5defc9963c6a17ae7a5ae)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: d5a5d43e27308df63f4c7be4ec988c969ac45d1d
https://github.com/qemu/qemu/commit/d5a5d43e27308df63f4c7be4ec988c969ac45d1d
Author: Michael S. Tsirkin <mst@redhat.com>
Date: 2020-05-12 (Tue, 12 May 2020)
Changed paths:
M hw/virtio/virtio.c
M include/hw/virtio/virtio.h
Log Message:
-----------
virtio: add ability to delete vq through a pointer
Devices tend to maintain vq pointers, allow deleting them trough a vq pointer.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
(cherry picked from commit 722f8c51d8af223751dfb1d02de40043e8ba067e)
*prereq for 421afd2fe8
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: a843731d7f09ca102833a06adaf358abb524a86b
https://github.com/qemu/qemu/commit/a843731d7f09ca102833a06adaf358abb524a86b
Author: Michael S. Tsirkin <mst@redhat.com>
Date: 2020-05-12 (Tue, 12 May 2020)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: make virtio_delete_queue idempotent
Let's make sure calling this twice is harmless -
no known instances, but seems safer.
Suggested-by: Pan Nengyuan <pannengyuan@huawei.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 8cd353ea0fbf0e334e015d833f612799be642296)
*prereq for 421afd2fe8
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: a474197f113cf2e799755859d81e051e24e7c80c
https://github.com/qemu/qemu/commit/a474197f113cf2e799755859d81e051e24e7c80c
Author: Yuri Benditovich <yuri.benditovich@daynix.com>
Date: 2020-05-12 (Tue, 12 May 2020)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: reset region cache when on queue deletion
https://bugzilla.redhat.com/show_bug.cgi?id=1708480
Fix leak of region reference that prevents complete
device deletion on hot unplug.
Cc: qemu-stable@nongnu.org
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Message-Id: <20191226043649.14481-2-yuri.benditovich@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 421afd2fe8dd4603216cbf36081877c391f5a2a4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 7042922dd77333af256a4232c8f5e8d0ae17f275
https://github.com/qemu/qemu/commit/7042922dd77333af256a4232c8f5e8d0ae17f275
Author: Yuri Benditovich <yuri.benditovich@daynix.com>
Date: 2020-05-12 (Tue, 12 May 2020)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
virtio-net: delete also control queue when TX/RX deleted
https://bugzilla.redhat.com/show_bug.cgi?id=1708480
If the control queue is not deleted together with TX/RX, it
later will be ignored in freeing cache resources and hot
unplug will not be completed.
Cc: qemu-stable@nongnu.org
Signed-off-by: Yuri Benditovich <yuri.benditovich@daynix.com>
Message-Id: <20191226043649.14481-3-yuri.benditovich@daynix.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d945d9f1731244ef341f74ede93120fc9de35913)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 98c74fe49aacea4d80d853cb8c398576470f023e
https://github.com/qemu/qemu/commit/98c74fe49aacea4d80d853cb8c398576470f023e
Author: Liu Yi L <yi.l.liu@intel.com>
Date: 2020-05-12 (Tue, 12 May 2020)
Changed paths:
M hw/i386/intel_iommu.c
Log Message:
-----------
intel_iommu: a fix to vtd_find_as_from_bus_num()
Ensure the return value of vtd_find_as_from_bus_num() is NULL by
enforcing vtd_bus=NULL. This would help caller of vtd_find_as_from_bus_num()
to decide if any further operation on the returned vtd_bus.
Cc: qemu-stable@nongnu.org
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Yi Sun <yi.y.sun@linux.intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Signed-off-by: Yi Sun <yi.y.sun@linux.intel.com>
Message-Id: <1578058086-4288-2-git-send-email-yi.l.liu@intel.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit a2e1cd41ccfe796529abfd1b6aeb1dd4393762a2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 742195db1746f6c8527ee30a030c0295d7a1eaed
https://github.com/qemu/qemu/commit/742195db1746f6c8527ee30a030c0295d7a1eaed
Author: Liu Yi L <yi.l.liu@intel.com>
Date: 2020-05-12 (Tue, 12 May 2020)
Changed paths:
M hw/i386/intel_iommu.c
M hw/i386/intel_iommu_internal.h
Log Message:
-----------
intel_iommu: add present bit check for pasid table entries
The present bit check for pasid entry (pe) and pasid directory
entry (pdire) were missed in previous commits as fpd bit check
doesn't require present bit as "Set". This patch adds the present
bit check for callers which wants to get a valid pe/pdire.
Cc: qemu-stable@nongnu.org
Cc: Kevin Tian <kevin.tian@intel.com>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Yi Sun <yi.y.sun@linux.intel.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Message-Id: <1578058086-4288-3-git-send-email-yi.l.liu@intel.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 56fc1e6ac6bde95bc0369d358587f2234d4dddad)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 3fb2521040478adbec767eac83ec6a78ad0c610d
https://github.com/qemu/qemu/commit/3fb2521040478adbec767eac83ec6a78ad0c610d
Author: Peter Xu <peterx@redhat.com>
Date: 2020-06-01 (Mon, 01 Jun 2020)
Changed paths:
M hw/vfio/pci.c
Log Message:
-----------
vfio/pci: Don't remove irqchip notifier if not registered
The kvm irqchip notifier is only registered if the device supports
INTx, however it's unconditionally removed. If the assigned device
does not support INTx, this will cause QEMU to crash when unplugging
the device from the system. Change it to conditionally remove the
notifier only if the notify hook is setup.
CC: Eduardo Habkost <ehabkost@redhat.com>
CC: David Gibson <david@gibson.dropbear.id.au>
CC: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-stable@nongnu.org # v4.2
Reported-by: yanghliu@redhat.com
Debugged-by: Eduardo Habkost <ehabkost@redhat.com>
Fixes: c5478fea27ac ("vfio/pci: Respond to KVM irqchip change notifier")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1782678
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
(cherry picked from commit 0446f8121723b134ca1d1ed0b73e96d4a0a8689d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: fa446ae444d7daa24971f74888771120de0b5f97
https://github.com/qemu/qemu/commit/fa446ae444d7daa24971f74888771120de0b5f97
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-01 (Mon, 01 Jun 2020)
Changed paths:
M block/qcow2-bitmap.c
Log Message:
-----------
qcow2-bitmaps: fix qcow2_can_store_new_dirty_bitmap
qcow2_can_store_new_dirty_bitmap works wrong, as it considers only
bitmaps already stored in the qcow2 image and ignores persistent
BdrvDirtyBitmap objects.
So, let's instead count persistent BdrvDirtyBitmaps. We load all qcow2
bitmaps on open, so there should not be any bitmap in the image for
which we don't have BdrvDirtyBitmaps version. If it is - it's a kind of
corruption, and no reason to check for corruptions here (open() and
close() are better places for it).
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20191014115126.15360-2-vsementsov@virtuozzo.com
Reviewed-by: Max Reitz <mreitz@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit a1db8733d28d615bc0daeada6c406a6dd5c5d5ef)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: eb54a2f9cee10cf1c7832a3536a8d5980ec313e9
https://github.com/qemu/qemu/commit/eb54a2f9cee10cf1c7832a3536a8d5980ec313e9
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-01 (Mon, 01 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Mask EOL bit from descriptor addresses
The Least Significant bit of a descriptor address register is used as
an EOL flag. It has to be masked when the register value is to be used
as an actual address for copying memory around. But when the registers
are to be updated the EOL bit should not be masked.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 88f632fbb1b3d31d5b6978d28f8735a6ed18b8f5)
Conflicts:
hw/net/dp8393x.c
*drop context dep. on 19f70347731
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 956e1b2d977f8743d58c97994c27d6c848ae3b7d
https://github.com/qemu/qemu/commit/956e1b2d977f8743d58c97994c27d6c848ae3b7d
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-01 (Mon, 01 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Always use 32-bit accesses
The DP83932 and DP83934 have 32 data lines. The datasheet says,
Data Bus: These bidirectional lines are used to transfer data on the
system bus. When the SONIC is a bus master, 16-bit data is transferred
on D15-D0 and 32-bit data is transferred on D31-D0. When the SONIC is
accessed as a slave, register data is driven onto lines D15-D0.
D31-D16 are held TRI-STATE if SONIC is in 16-bit mode. If SONIC is in
32-bit mode, they are driven, but invalid.
Always use 32-bit accesses both as bus master and bus slave.
Force the MSW to zero in bus master mode.
This gets the Linux 'jazzsonic' driver working, and avoids the need for
prior hacks to make the NetBSD 'sn' driver work.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 3fe9a838ec3eae1374ced16b63bf56894b2ffbe6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: bf3f12ac8c34e4856f48c5f7ee7d23c042097797
https://github.com/qemu/qemu/commit/bf3f12ac8c34e4856f48c5f7ee7d23c042097797
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Clean up endianness hacks
According to the datasheet, section 3.4.4, "in 32-bit mode ... the SONIC
always writes long words".
Therefore, use the same technique for the 'in_use' field that is used
everywhere else, and write the full long word.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 46ffee9ad43185cbee4182c208bbd534814086ca)
Conflicts:
hw/net/dp8393x.c
*roll in local dependencies on b7cbebf2b9d
*drop functional dep. on 19f70347731
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 153c3320e77cfcafc5a44d01d6fb7905121a8fd7
https://github.com/qemu/qemu/commit/153c3320e77cfcafc5a44d01d6fb7905121a8fd7
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Have dp8393x_receive() return the packet size
This function re-uses its 'size' argument as a scratch variable.
Instead, declare a local 'size' variable for that purpose so that the
function result doesn't get messed up.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 9e3cd456d85ad45e72bdba99203302342ce29b3b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: edd67a61f499982bcc2098962c8e04c5210f2f80
https://github.com/qemu/qemu/commit/edd67a61f499982bcc2098962c8e04c5210f2f80
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Update LLFA and CRDA registers from rx descriptor
Follow the algorithm given in the National Semiconductor DP83932C
datasheet in section 3.4.7:
At the next reception, the SONIC re-reads the last RXpkt.link field,
and updates its CRDA register to point to the next descriptor.
The chip is designed to allow the host to provide a new list of
descriptors in this way.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 5b0c98fcb7ac006bd8efe0e0fecba52c43a9d028)
*drop context dep on 19f70347731
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 5f08c382caee86109585111b240c36371738b00d
https://github.com/qemu/qemu/commit/5f08c382caee86109585111b240c36371738b00d
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Clear RRRA command register bit only when appropriate
It doesn't make sense to clear the command register bit unless the
command was actually issued.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit a3cce2825a0b12bb717a5106daaca245557cc9ae)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 3a8068f4ebb9f9500cf3d1805f5cfbd42e15ab12
https://github.com/qemu/qemu/commit/3a8068f4ebb9f9500cf3d1805f5cfbd42e15ab12
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Implement packet size limit and RBAE interrupt
Add a bounds check to prevent a large packet from causing a buffer
overflow. This is defensive programming -- I haven't actually tried
sending an oversized packet or a jumbo ethernet frame.
The SONIC handles packets that are too big for the buffer by raising
the RBAE interrupt and dropping them. Linux uses that interrupt to
count dropped packets.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit ada74315270d1dcabf4c9d4fece19df7ef5b9577)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: d50aa8acbc6f4bd83d0d0b5958d49ac6baf254a5
https://github.com/qemu/qemu/commit/d50aa8acbc6f4bd83d0d0b5958d49ac6baf254a5
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Don't clobber packet checksum
A received packet consumes pkt_size bytes in the buffer and the frame
checksum that's appended to it consumes another 4 bytes. The Receive
Buffer Address register takes the former quantity into account but
not the latter. So the next packet written to the buffer overwrites
the frame checksum. Fix this.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit bae112b80c9c42cea21ee7623c283668c3451c2e)
*drop context dep. on 19f70347731
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e7cad754fd0bf00c671a1509acc2981f11736ee8
https://github.com/qemu/qemu/commit/e7cad754fd0bf00c671a1509acc2981f11736ee8
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Use long-word-aligned RRA pointers in 32-bit mode
Section 3.4.1 of the datasheet says,
The alignment of the RRA is confined to either word or long word
boundaries, depending upon the data width mode. In 16-bit mode,
the RRA must be aligned to a word boundary (A0 is always zero)
and in 32-bit mode, the RRA is aligned to a long word boundary
(A0 and A1 are always zero).
This constraint has been implemented for 16-bit mode; implement it
for 32-bit mode too.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit ea2270279bc2e1635cb6e909e22e17e630198773)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: cbc8277051f76f8131f5d4c787862a16a5fa1707
https://github.com/qemu/qemu/commit/cbc8277051f76f8131f5d4c787862a16a5fa1707
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Pad frames to word or long word boundary
The existing code has a bug where the Remaining Buffer Word Count (RBWC)
is calculated with a truncating division, which gives the wrong result
for odd-sized packets.
Section 1.4.1 of the datasheet says,
Once the end of the packet has been reached, the serializer will
fill out the last word (16-bit mode) or long word (32-bit mode)
if the last byte did not end on a word or long word boundary
respectively. The fill byte will be 0FFh.
Implement buffer padding so that buffer limits are correctly enforced.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 350e7d9a77d3b9ac74d240e4b232db1ebe5c05bc)
*drop context dependencies from b7cbebf2b9d, 1ccda935d4f, and
19f70347731
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 8d61b1e2c4e2ad8310ca957decf26b0b82d37148
https://github.com/qemu/qemu/commit/8d61b1e2c4e2ad8310ca957decf26b0b82d37148
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Clear descriptor in_use field to release packet
When the SONIC receives a packet into the last available descriptor, it
retains ownership of that descriptor for as long as necessary.
Section 3.4.7 of the datasheet says,
When the system appends more descriptors, the SONIC releases ownership
of the descriptor after writing 0000h to the RXpkt.in_use field.
The packet can now be processed by the host, so raise a PKTRX interrupt,
just like the normal case.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit d9fae13196a31716f45dcddcdd958fbb8e59b35a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 1190026fe415ce29605bdadbb68956a3315714e8
https://github.com/qemu/qemu/commit/1190026fe415ce29605bdadbb68956a3315714e8
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Always update RRA pointers and sequence numbers
These operations need to take place regardless of whether or not
rx descriptors have been used up (that is, EOL flag was observed).
The algorithm is now the same for a packet that was withheld as for
a packet that was not.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 80b60673ea598869050c66d95d8339480e4cefd0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 735cd8ddab7d2e8b3cb693295067d2c8a9098f86
https://github.com/qemu/qemu/commit/735cd8ddab7d2e8b3cb693295067d2c8a9098f86
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Don't reset Silicon Revision register
The jazzsonic driver in Linux uses the Silicon Revision register value
to probe the chip. The driver fails unless the SR register contains 4.
Unfortunately, reading this register in QEMU usually returns 0 because
the s->regs[] array gets wiped after a software reset.
Fixes: bd8f1ebce4 ("net/dp8393x: fix hardware reset")
Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 083e21bbdde7dbd326baf29d21f49fc3f5614496)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 3e1d95301e8c00d8a8a2ec03ed941f019c8fd2b3
https://github.com/qemu/qemu/commit/3e1d95301e8c00d8a8a2ec03ed941f019c8fd2b3
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Don't stop reception upon RBE interrupt assertion
Section 3.4.7 of the datasheet explains that,
The RBE bit in the Interrupt Status register is set when the
SONIC finishes using the second to last receive buffer and reads
the last RRA descriptor. Actually, the SONIC is not truly out of
resources, but gives the system an early warning of an impending
out of resources condition.
RBE does not mean actual receive buffer exhaustion, and reception should
not be stopped. This is important because Linux will not check and clear
the RBE interrupt until it receives another packet. But that won't
happen if can_receive returns false. This bug causes the SONIC to become
deaf (until reset).
Fix this with a new flag to indicate actual receive buffer exhaustion.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Laurent Vivier <laurent@vivier.eu>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit c2279bd0a19b35057f2e4c3b4df9a915717d1142)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 2a7569e75194bf0d14f4d8cbd12c4ee332c1ad21
https://github.com/qemu/qemu/commit/2a7569e75194bf0d14f4d8cbd12c4ee332c1ad21
Author: Christian Borntraeger <borntraeger@de.ibm.com>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M target/s390x/helper.c
Log Message:
-----------
s390/sclp: improve special wait psw logic
There is a special quiesce PSW that we check for "shutdown". Otherwise disabled
wait is detected as "crashed". Architecturally we must only check PSW bits
116-127. Fix this.
Cc: qemu-stable@nongnu.org
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <1582204582-22995-1-git-send-email-borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Acked-by: Janosch Frank <frankja@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 8b51c0961cc13e55b26bb6665ec3a341abdc7658)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 0319118bcfbbfb91bac8d83e5908c0fec7e11307
https://github.com/qemu/qemu/commit/0319118bcfbbfb91bac8d83e5908c0fec7e11307
Author: Emilio G. Cota <cota@braap.org>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M plugins/core.c
Log Message:
-----------
plugins/core: add missing break in cb_to_tcg_flags
Fixes: 54cb65d8588
Reported-by: Robert Henry <robhenry@microsoft.com>
Signed-off-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20200105072940.32204-1-cota@braap.org>
Cc: qemu-stable@nongnu.org
Message-Id: <20200225124710.14152-12-alex.bennee@linaro.org>
(cherry picked from commit dcc474c69e6a59044b9bb54624bd636cbfd98aa9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e49ae74a248fb8d4a90b8376ee2188f2b7cc5992
https://github.com/qemu/qemu/commit/e49ae74a248fb8d4a90b8376ee2188f2b7cc5992
Author: Alex Bennée <alex.bennee@linaro.org>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M tcg/tcg-op.c
Log Message:
-----------
tcg: save vaddr temp for plugin usage
While do_gen_mem_cb does copy (via extu_tl_i64) vaddr into a new temp
this won't help if the vaddr temp gets clobbered by the actual
load/store op. To avoid this clobbering we explicitly copy vaddr
before the op to ensure it is live my the time we do the
instrumentation.
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Emilio G. Cota <cota@braap.org>
Cc: qemu-stable@nongnu.org
Message-Id: <20200225124710.14152-18-alex.bennee@linaro.org>
(cherry picked from commit fcc54ab5c7ca84ae72e8bf3781c33c9193a911aa)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: f9854de0d815b0c38a16201e9e11ec61ef84fcf9
https://github.com/qemu/qemu/commit/f9854de0d815b0c38a16201e9e11ec61ef84fcf9
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M block/qcow2-refcount.c
Log Message:
-----------
qcow2: update_refcount(): Reset old_table_index after qcow2_cache_put()
In the case that update_refcount() frees a refcount block, it evicts it
from the metadata cache. Before doing so, however, it returns the
currently used refcount block to the cache because it might be the same.
Returning the refcount block early means that we need to reset
old_table_index so that we reload the refcount block in the next
iteration if it is actually still in use.
Fixes: f71c08ea8e60f035485a512fd2af8908567592f0
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20200211094900.17315-2-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit dea9052ef1ba12c83f17d394c70d7d710ea1dec9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: ab7f6eaa5bc9f5cd95274089ab869680dddc77f8
https://github.com/qemu/qemu/commit/ab7f6eaa5bc9f5cd95274089ab869680dddc77f8
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M block/qcow2-cluster.c
Log Message:
-----------
qcow2: Fix qcow2_alloc_cluster_abort() for external data file
For external data file, cluster allocations return an offset in the data
file and are not refcounted. In this case, there is nothing to do for
qcow2_alloc_cluster_abort(). Freeing the same offset in the qcow2 file
is wrong and causes crashes in the better case or image corruption in
the worse case.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20200211094900.17315-3-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit c3b6658c1a5a3fb24d6c27b2594cf86146f75b22)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 373fd948ab33b6e74b227cd62d4ccc4c17417473
https://github.com/qemu/qemu/commit/373fd948ab33b6e74b227cd62d4ccc4c17417473
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M tests/qemu-iotests/244
M tests/qemu-iotests/244.out
Log Message:
-----------
iotests: Test copy offloading with external data file
This adds a test for 'qemu-img convert' with copy offloading where the
target image has an external data file. If the test hosts supports it,
it tests both the case where copy offloading is supported and the case
where it isn't (otherwise we just test unsupported twice).
More specifically, the case with unsupported copy offloading tests
qcow2_alloc_cluster_abort() with external data files.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20200211094900.17315-4-kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit a0cf8daf77548786ced84d773f06fc70571c5d38)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 382b9f09bd358f8dd302158b326cbdffba1e2b2d
https://github.com/qemu/qemu/commit/382b9f09bd358f8dd302158b326cbdffba1e2b2d
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M block/qcow2-cluster.c
Log Message:
-----------
qcow2: Fix alloc_cluster_abort() for pre-existing clusters
handle_alloc() reuses preallocated zero clusters. If anything goes
wrong during the data write, we do not change their L2 entry, so we
must not let qcow2_alloc_cluster_abort() free them.
Fixes: 8b24cd141549b5b264baeddd4e72902cfb5de23b
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200225143130.111267-2-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 3ede935fdbbd5f7b24b4724bbfb8938acb5956d8)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 30aa0ea6c578b51a71d8cbb9578cc7f7bfeb56aa
https://github.com/qemu/qemu/commit/30aa0ea6c578b51a71d8cbb9578cc7f7bfeb56aa
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M tests/qemu-iotests/026
M tests/qemu-iotests/026.out
M tests/qemu-iotests/026.out.nocache
Log Message:
-----------
iotests/026: Test EIO on preallocated zero cluster
Test what happens when writing data to a preallocated zero cluster, but
the data write fails.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200225143130.111267-3-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 31ab00f3747c00fdbb9027cea644b40dd1405480)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4540aa4a8d2c59ec42af0ea58ca1794124ce47dd
https://github.com/qemu/qemu/commit/4540aa4a8d2c59ec42af0ea58ca1794124ce47dd
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-06-02 (Tue, 02 Jun 2020)
Changed paths:
M tests/qemu-iotests/026
M tests/qemu-iotests/026.out
M tests/qemu-iotests/026.out.nocache
Log Message:
-----------
iotests/026: Test EIO on allocation in a data-file
Test what happens when writing data to an external data file, where the
write requires an L2 entry to be allocated, but the data write fails.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200225143130.111267-4-mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 81311255f217859413c94f2cd9cebf2684bbda94)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 2dc540e40df4d3b588d118b811b0a716ddec5c7d
https://github.com/qemu/qemu/commit/2dc540e40df4d3b588d118b811b0a716ddec5c7d
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: gracefully handle invalid region caches
The virtqueue code sets up MemoryRegionCaches to access the virtqueue
guest RAM data structures. The code currently assumes that
VRingMemoryRegionCaches is initialized before device emulation code
accesses the virtqueue. An assertion will fail in
vring_get_region_caches() when this is not true. Device fuzzing found a
case where this assumption is false (see below).
Virtqueue guest RAM addresses can also be changed from a vCPU thread
while an IOThread is accessing the virtqueue. This breaks the same
assumption but this time the caches could become invalid partway through
the virtqueue code. The code fetches the caches RCU pointer multiple
times so we will need to validate the pointer every time it is fetched.
Add checks each time we call vring_get_region_caches() and treat invalid
caches as a nop: memory stores are ignored and memory reads return 0.
The fuzz test failure is as follows:
$ qemu -M pc -device virtio-blk-pci,id=drv0,drive=drive0,addr=4.0 \
-drive if=none,id=drive0,file=null-co://,format=raw,auto-read-only=off
\
-drive
if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw \
-display none \
-qtest stdio
endianness
outl 0xcf8 0x80002020
outl 0xcfc 0xe0000000
outl 0xcf8 0x80002004
outw 0xcfc 0x7
write 0xe0000000 0x24
0x00ffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffab5cffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffabffffffab0000000001
inb 0x4
writew 0xe000001c 0x1
write 0xe0000014 0x1 0x0d
The following error message is produced:
qemu-system-x86_64: /home/stefanha/qemu/hw/virtio/virtio.c:286:
vring_get_region_caches: Assertion `caches != NULL' failed.
The backtrace looks like this:
#0 0x00007ffff5520625 in raise () at /lib64/libc.so.6
#1 0x00007ffff55098d9 in abort () at /lib64/libc.so.6
#2 0x00007ffff55097a9 in _nl_load_domain.cold () at /lib64/libc.so.6
#3 0x00007ffff5518a66 in annobin_assert.c_end () at /lib64/libc.so.6
#4 0x00005555559073da in vring_get_region_caches (vq=<optimized out>) at
qemu/hw/virtio/virtio.c:286
#5 vring_get_region_caches (vq=<optimized out>) at
qemu/hw/virtio/virtio.c:283
#6 0x000055555590818d in vring_used_flags_set_bit (mask=1,
vq=0x5555575ceea0) at qemu/hw/virtio/virtio.c:398
#7 virtio_queue_split_set_notification (enable=0, vq=0x5555575ceea0) at
qemu/hw/virtio/virtio.c:398
#8 virtio_queue_set_notification (vq=vq@entry=0x5555575ceea0,
enable=enable@entry=0) at qemu/hw/virtio/virtio.c:451
#9 0x0000555555908512 in virtio_queue_set_notification
(vq=vq@entry=0x5555575ceea0, enable=enable@entry=0) at
qemu/hw/virtio/virtio.c:444
#10 0x00005555558c697a in virtio_blk_handle_vq (s=0x5555575c57e0,
vq=0x5555575ceea0) at qemu/hw/block/virtio-blk.c:775
#11 0x0000555555907836 in virtio_queue_notify_aio_vq (vq=0x5555575ceea0) at
qemu/hw/virtio/virtio.c:2244
#12 0x0000555555cb5dd7 in aio_dispatch_handlers
(ctx=ctx@entry=0x55555671a420) at util/aio-posix.c:429
#13 0x0000555555cb67a8 in aio_dispatch (ctx=0x55555671a420) at
util/aio-posix.c:460
#14 0x0000555555cb307e in aio_ctx_dispatch (source=<optimized out>,
callback=<optimized out>, user_data=<optimized out>) at util/async.c:260
#15 0x00007ffff7bbc510 in g_main_context_dispatch () at
/lib64/libglib-2.0.so.0
#16 0x0000555555cb5848 in glib_pollfds_poll () at util/main-loop.c:219
#17 os_host_main_loop_wait (timeout=<optimized out>) at util/main-loop.c:242
#18 main_loop_wait (nonblocking=<optimized out>) at util/main-loop.c:518
#19 0x00005555559b20c9 in main_loop () at vl.c:1683
#20 0x0000555555838115 in main (argc=<optimized out>, argv=<optimized out>,
envp=<optimized out>) at vl.c:4441
Reported-by: Alexander Bulekov <alxndr@bu.edu>
Cc: Michael Tsirkin <mst@redhat.com>
Cc: Cornelia Huck <cohuck@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200207104619.164892-1-stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit abdd16f4681cc4d6bf84990227b5c9b98e869ccd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4a1c5955e7b02a5f6782a7f2219a193e70844fdf
https://github.com/qemu/qemu/commit/4a1c5955e7b02a5f6782a7f2219a193e70844fdf
Author: Christophe de Dinechin <dinechin@redhat.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M scsi/qemu-pr-helper.c
Log Message:
-----------
scsi/qemu-pr-helper: Fix out-of-bounds access to trnptid_list[]
Compile error reported by gcc 10.0.1:
scsi/qemu-pr-helper.c: In function ‘multipath_pr_out’:
scsi/qemu-pr-helper.c:523:32: error: array subscript <unknown> is outside array
bounds of ‘struct transportid *[0]’ [-Werror=array-bounds]
523 | paramp.trnptid_list[paramp.num_transportid++] = id;
| ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from scsi/qemu-pr-helper.c:36:
/usr/include/mpath_persist.h:168:22: note: while referencing ‘trnptid_list’
168 | struct transportid *trnptid_list[];
| ^~~~~~~~~~~~
scsi/qemu-pr-helper.c:424:35: note: defined here ‘paramp’
424 | struct prout_param_descriptor paramp;
| ^~~~~~
This highlights an actual implementation issue in function multipath_pr_out.
The variable paramp is declared with type `struct prout_param_descriptor`,
which is a struct terminated by an empty array in mpath_persist.h:
struct transportid *trnptid_list[];
That empty array was filled with code that looked like that:
trnptid_list[paramp.descr.num_transportid++] = id;
This is an actual out-of-bounds access.
The fix is to malloc `paramp`.
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 4ce1e15fbc7266a108a7c77a3962644b3935346e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e0ccde388779ae22a1070c180c8e4df09888f77e
https://github.com/qemu/qemu/commit/e0ccde388779ae22a1070c180c8e4df09888f77e
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M block/qcow2-threads.c
Log Message:
-----------
block/qcow2-threads: fix qcow2_decompress
On success path we return what inflate() returns instead of 0. And it
most probably works for Z_STREAM_END as it is positive, but is
definitely broken for Z_BUF_ERROR.
While being here, switch to errno return code, to be closer to
qcow2_compress API (and usual expectations).
Revert condition in if to be more positive. Drop dead initialization of
ret.
Cc: qemu-stable@nongnu.org # v4.0
Fixes: 341926ab83e2b
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200302150930.16218-1-vsementsov@virtuozzo.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit e7266570f2cf7b3ca2a156c677ee0a59d563458b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: a0dc4d24950ca2cf16eafb7a08df4f534a696623
https://github.com/qemu/qemu/commit/a0dc4d24950ca2cf16eafb7a08df4f534a696623
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M blockjob.c
M include/qemu/job.h
A include/qemu/progress_meter.h
M job-qmp.c
M job.c
M qemu-img.c
Log Message:
-----------
job: refactor progress to separate object
We need it in separate to pass to the block-copy object in the next
commit.
Cc: qemu-stable@nongnu.org
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200311103004.7649-2-vsementsov@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 01fe1ca945345d3dc420d70c69488143dc0451b1)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: c44c4f7229a4c5d2d10efaede2570537cb1e3285
https://github.com/qemu/qemu/commit/c44c4f7229a4c5d2d10efaede2570537cb1e3285
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M block/backup.c
M block/block-copy.c
M include/block/block-copy.h
Log Message:
-----------
block/block-copy: fix progress calculation
Assume we have two regions, A and B, and region B is in-flight now,
region A is not yet touched, but it is unallocated and should be
skipped.
Correspondingly, as progress we have
total = A + B
current = 0
If we reset unallocated region A and call progress_reset_callback,
it will calculate 0 bytes dirty in the bitmap and call
job_progress_set_remaining, which will set
total = current + 0 = 0 + 0 = 0
So, B bytes are actually removed from total accounting. When job
finishes we'll have
total = 0
current = B
, which doesn't sound good.
This is because we didn't considered in-flight bytes, actually when
calculating remaining, we should have set (in_flight + dirty_bytes)
as remaining, not only dirty_bytes.
To fix it, let's refactor progress calculation, moving it to block-copy
itself instead of fixing callback. And, of course, track in_flight
bytes count.
We still have to keep one callback, to maintain backup job bytes_read
calculation, but it will go on soon, when we turn the whole backup
process into one block_copy call.
Cc: qemu-stable@nongnu.org
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Message-Id: <20200311103004.7649-3-vsementsov@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit d0ebeca14a585f352938062ef8ddde47fe4d39f9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4a9486a02d17e81a54bc4b631fec7112a1850a9d
https://github.com/qemu/qemu/commit/4a9486a02d17e81a54bc4b631fec7112a1850a9d
Author: Vitaly Chikunov <vt@altlinux.org>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M target/ppc/translate.c
Log Message:
-----------
target/ppc: Fix rlwinm on ppc64
rlwinm cannot just AND with Mask if shift value is zero on ppc64 when
Mask Begin is greater than Mask End and high bits are set to 1.
Note that PowerISA 3.0B says that for `rlwinm' ROTL32 is used, and
ROTL32 is defined (in 3.3.14) so that rotated value should have two
copies of lower word of the source value.
This seems to be another incarnation of the fix from 820724d170
("target-ppc: Fix rlwimi, rlwinm, rlwnm again"), except I leave
optimization when Mask value is less than 32 bits.
Fixes: 7b4d326f47 ("target-ppc: Use the new deposit and extract ops")
Cc: qemu-stable@nongnu.org
Signed-off-by: Vitaly Chikunov <vt@altlinux.org>
Message-Id: <20200309204557.14836-1-vt@altlinux.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 94f040aaecf4e41cc68991b80204b1b6886bbdd0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 8fc4aa4822c55c9dbf7061a6fa4d9b3b8471800d
https://github.com/qemu/qemu/commit/8fc4aa4822c55c9dbf7061a6fa4d9b3b8471800d
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M block/io.c
Log Message:
-----------
block/io: fix bdrv_co_do_copy_on_readv
Prior to 1143ec5ebf4 it was OK to qemu_iovec_from_buf() from aligned-up
buffer to original qiov, as qemu_iovec_from_buf() will stop at qiov end
anyway.
But after 1143ec5ebf4 we assume that bdrv_co_do_copy_on_readv works on
part of original qiov, defined by qiov_offset and bytes. So we must not
touch qiov behind qiov_offset+bytes bound. Fix it.
Cc: qemu-stable@nongnu.org # v4.2
Fixes: 1143ec5ebf4
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 20200312081949.5350-1-vsementsov@virtuozzo.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 4ab78b19189a81038e744728ed949d09aa477550)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 219362f9655859056e8f15cf96fc3169d4dc80de
https://github.com/qemu/qemu/commit/219362f9655859056e8f15cf96fc3169d4dc80de
Author: Cornelia Huck <cohuck@redhat.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M hw/core/machine.c
Log Message:
-----------
compat: disable edid on correct virtio-gpu device
Commit bb15791166c1 ("compat: disable edid on virtio-gpu base
device") tried to disable 'edid' on the virtio-gpu base device.
However, that device is not 'virtio-gpu', but 'virtio-gpu-device'.
Fix it.
Fixes: bb15791166c1 ("compat: disable edid on virtio-gpu base device")
Reported-by: Lukáš Doktor <ldoktor@redhat.com>
Tested-by: Lukáš Doktor <ldoktor@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Message-id: 20200318093919.24942-1-cohuck@redhat.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 02501fc39381c4dabaf6becdd12c2a4754c3847c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 7cc217b30d0270c9688f627e0bb377043067a442
https://github.com/qemu/qemu/commit/7cc217b30d0270c9688f627e0bb377043067a442
Author: Basil Salman <basil@daynix.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M qga/installer/qemu-ga.wxs
Log Message:
-----------
qga: Installer: Wait for installation to finish
Installation might fail if we don't wait for the provider
unregisteration process to finish.
Signed-off-by: Sameeh Jubran <sjubran@redhat.com>
Signed-off-by: Basil Salman <basil@daynix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit bb1ce44b15f159b67fafc5f4b285bbf20a1961e9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 3c3e1653c5c09391c154c5f36bf8646ce2bde9f9
https://github.com/qemu/qemu/commit/3c3e1653c5c09391c154c5f36bf8646ce2bde9f9
Author: Sameeh Jubran <sjubran@redhat.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M qga/vss-win32/install.cpp
Log Message:
-----------
qga-win: Handle VSS_E_PROVIDER_ALREADY_REGISTERED error
This patch handles the case where VSS Provider is already registered,
where in such case qga uninstalls the provider and registers it again.
Signed-off-by: Sameeh Jubran <sjubran@redhat.com>
Signed-off-by: Basil Salman <basil@daynix.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit b2413df83348acf371c03bced9a3845bba883ed5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4996bd71611c756681bf3dc410957946b5f7083f
https://github.com/qemu/qemu/commit/4996bd71611c756681bf3dc410957946b5f7083f
Author: Basil Salman <basil@daynix.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M qga/commands-win32.c
Log Message:
-----------
qga-win: prevent crash when executing guest-file-read with large count
guest-file-read command is currently implemented to read from a
file handle count number of bytes. when executed with a very large count number
qemu-ga crashes.
after some digging turns out that qemu-ga crashes after trying to allocate
a buffer large enough to save the data read in it, the buffer was allocated
using
g_malloc0 which is not fail safe, and results a crash in case of failure.
g_malloc0 was replaced with g_try_malloc0() which returns NULL on failure,
A check was added for that case in order to prevent qemu-ga from crashing
and to send a response to the qemu-ga client accordingly.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1594054
Signed-off-by: Basil Salman <basil@daynix.com>
Reported-by: Fakhri Zulkifli <mohdfakhrizulkifli@gmail.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit 807e2b6fce022707418bc8f61c069d91c613b3d2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e3531619f1431f029c2d09238f404bee0d3e9091
https://github.com/qemu/qemu/commit/e3531619f1431f029c2d09238f404bee0d3e9091
Author: Eric Blake <eblake@redhat.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M qga/commands.c
Log Message:
-----------
qga: Fix undefined C behavior
The QAPI struct GuestFileWhence has a comment about how we are
exploiting equivalent values between two different integer types
shared in a union. But C says behavior is undefined on assignments to
overlapping storage when the two types are not the same width, and
indeed, 'int64_t value' and 'enum QGASeek name' are very likely to be
different in width. Utilize a temporary variable to fix things.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Fixes: 0b4b49387
Fixes: Coverity CID 1421990
Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit a23f38a72921fa915536a981a4f8a9134512f120)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 8f5728cb97f25c9bfe86dc4b2eaa2156ebcc0c15
https://github.com/qemu/qemu/commit/8f5728cb97f25c9bfe86dc4b2eaa2156ebcc0c15
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date: 2020-06-03 (Wed, 03 Jun 2020)
Changed paths:
M docs/interop/qemu-ga.rst
M qga/main.c
Log Message:
-----------
qemu-ga: document vsock-listen in the man page
Although qemu-ga has supported vsock since 2016 it was not documented on
the man page.
Also add the socket address representation to the qga --help output.
Fixes: 586ef5dee77180fc32e33bc08051600030630239
("qga: add vsock-listen method")
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit 7b46aadbbfb7b06cd45a3b113b1f7c003c68f603)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 33be7aa9b6bea692e7ba615db1c97820051dc435
https://github.com/qemu/qemu/commit/33be7aa9b6bea692e7ba615db1c97820051dc435
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M hw/i386/amd_iommu.c
Log Message:
-----------
hw/i386/amd_iommu.c: Fix corruption of log events passed to guest
In the function amdvi_log_event(), we write an event log buffer
entry into guest ram, whose contents are passed to the function
via the "uint64_t *evt" argument. Unfortunately, a spurious
'&' in the call to dma_memory_write() meant that instead of
writing the event to the guest we would write the literal value
of the pointer, plus whatever was in the following 8 bytes
on the stack. This error was spotted by Coverity.
Fix the bug by removing the '&'.
Fixes: CID 1421945
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20200326105349.24588-1-peter.maydell@linaro.org>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 32a2d6b1f6b4405f0fc20c031e61d5d48e3d9cd1)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: aabd9ddd2de63cdd0189fb00fad1012abfc46d12
https://github.com/qemu/qemu/commit/aabd9ddd2de63cdd0189fb00fad1012abfc46d12
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M tcg/i386/tcg-target.inc.c
Log Message:
-----------
tcg/i386: Fix INDEX_op_dup2_vec
We were only constructing the 64-bit element, and not
replicating the 64-bit element across the rest of the vector.
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit e20cb81d9c5a3d0f9c08f3642728a210a1c162c9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 25fcaed9a366314c21793e14624c89db75224b50
https://github.com/qemu/qemu/commit/25fcaed9a366314c21793e14624c89db75224b50
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M dump/dump.c
Log Message:
-----------
dump: Fix writing of ELF section
In write_elf_section() we set the 'shdr' pointer to point to local
structures shdr32 or shdr64, which we fill in to be written out to
the ELF dump. Unfortunately the address we pass to fd_write_vmcore()
has a spurious '&' operator, so instead of writing out the section
header we write out the literal pointer value followed by whatever is
on the stack after the 'shdr' local variable.
Pass the correct address into fd_write_vmcore().
Spotted by Coverity: CID 1421970.
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id: 20200324173630.12221-1-peter.maydell@linaro.org
(cherry picked from commit 174d2d6856bf435f4f58e9303ba30dd0e1279d3f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: c5feb392195c0c6dc0d769d3c5a5c51e1b831792
https://github.com/qemu/qemu/commit/c5feb392195c0c6dc0d769d3c5a5c51e1b831792
Author: Anthony PERARD <anthony.perard@citrix.com>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M hw/block/dataplane/xen-block.c
Log Message:
-----------
xen-block: Fix double qlist remove and request leak
Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on
remove") revealed that a request was removed twice from a list, once
in xen_block_finish_request() and a second time in
xen_block_release_request() when both function are called from
xen_block_complete_aio(). But also, the `requests_inflight' counter is
decreased twice, and thus became negative.
This is a bug that was introduced in bfd0d6366043 ("xen-block: improve
response latency"), where a `finished' list was removed.
That commit also introduced a leak of request in xen_block_do_aio().
That function calls xen_block_finish_request() but the request is
never released after that.
To fix both issue, we do two changes:
- we squash finish_request() and release_request() together as we want
to remove a request from 'inflight' list to add it to 'freelist'.
- before releasing a request, we need to let the other end know the
result, thus we should call xen_block_send_response() before
releasing a request.
The first change fixes the double QLIST_REMOVE() as we remove the extra
call. The second change makes the leak go away because if we want to
call finish_request(), we need to call a function that does all of
finish, send response, and release.
Fixes: bfd0d6366043 ("xen-block: improve response latency")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200406140217.1441858-1-anthony.perard@citrix.com>
Reviewed-by: Paul Durrant <paul@xen.org>
[mreitz: Amended commit message as per Paul's suggestions]
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 36d883ba0de8a281072ded2b51e0a711fd002139)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: ea1518bb5e3e89bea4774646f49573c1a9e3cda6
https://github.com/qemu/qemu/commit/ea1518bb5e3e89bea4774646f49573c1a9e3cda6
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M contrib/vhost-user-gpu/main.c
M contrib/vhost-user-gpu/virgl.c
Log Message:
-----------
vhost-user-gpu: Release memory returned by vu_queue_pop() with free()
vu_queue_pop() returns memory that must be freed with free().
Cc: qemu-stable@nongnu.org
Reported-by: Coverity (CID 1421887 ALLOC_FREE_MISMATCH)
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 4ff97121a3ee631971aadc87e3d4e7fb66f15aa8)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 8d127b4be723837a8e33fbc9173bc5cd95b4242f
https://github.com/qemu/qemu/commit/8d127b4be723837a8e33fbc9173bc5cd95b4242f
Author: Nicholas Piggin <npiggin@gmail.com>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M target/ppc/translate.c
Log Message:
-----------
target/ppc: Fix mtmsr(d) L=1 variant that loses interrupts
If mtmsr L=1 sets MSR[EE] while there is a maskable exception pending,
it does not cause an interrupt. This causes the test case to hang:
https://lists.gnu.org/archive/html/qemu-ppc/2019-10/msg00826.html
More recently, Linux reduced the occurance of operations (e.g., rfi)
which stop translation and allow pending interrupts to be processed.
This started causing hangs in Linux boot in long-running kernel tests,
running with '-d int' shows the decrementer stops firing despite DEC
wrapping and MSR[EE]=1.
https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-April/208301.html
The cause is the broken mtmsr L=1 behaviour, which is contrary to the
architecture. From Power ISA v3.0B, p.977, Move To Machine State Register,
Programming Note states:
If MSR[EE]=0 and an External, Decrementer, or Performance Monitor
exception is pending, executing an mtmsrd instruction that sets
MSR[EE] to 1 will cause the interrupt to occur before the next
instruction is executed, if no higher priority exception exists
Fix this by handling L=1 exactly the same way as L=0, modulo the MSR
bits altered.
The confusion arises from L=0 being "context synchronizing" whereas L=1
is "execution synchronizing", which is a weaker semantic. However this
is not a relaxation of the requirement that these exceptions cause
interrupts when MSR[EE]=1 (e.g., when mtmsr executes to completion as
TCG is doing here), rather it specifies how a pipelined processor can
have multiple instructions in flight where one may influence how another
behaves.
Cc: qemu-stable@nongnu.org
Reported-by: Anton Blanchard <anton@ozlabs.org>
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Message-Id: <20200414111131.465560-1-npiggin@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Tested-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 5ed195065cc6895f61b9d59bfa0a0536ed5ed51e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 34c78a4100c967cc385fcfd4c2295b2b0ebd8786
https://github.com/qemu/qemu/commit/34c78a4100c967cc385fcfd4c2295b2b0ebd8786
Author: Igor Mammedov <imammedo@redhat.com>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M backends/hostmem.c
Log Message:
-----------
hostmem: don't use mbind() if host-nodes is empty
Since 5.0 QEMU uses hostmem backend for allocating main guest RAM.
The backend however calls mbind() which is typically NOP
in case of default policy/absent host-nodes bitmap.
However when runing in container with black-listed mbind()
syscall, QEMU fails to start with error
"cannot bind memory to host NUMA nodes: Operation not permitted"
even when user hasn't provided host-nodes to pin to explictly
(which is the case with -m option)
To fix issue, call mbind() only in case when user has provided
host-nodes explicitly (i.e. host_nodes bitmap is not empty).
That should allow to run QEMU in containers with black-listed
mbind() without memory pinning. If QEMU provided memory-pinning
is required user still has to white-list mbind() in container
configuration.
Reported-by: Manuel Hohmann <mhohmann@physnet.uni-hamburg.de>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20200430154606.6421-1-imammedo@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit 70b6d525dfb51d5e523d568d1139fc051bc223c5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: d5691a6373a4998b69c234bddacdf74b40a422fd
https://github.com/qemu/qemu/commit/d5691a6373a4998b69c234bddacdf74b40a422fd
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M target/arm/vec_helper.c
Log Message:
-----------
target/arm: Clear tail in gvec_fmul_idx_*, gvec_fmla_idx_*
Must clear the tail for AdvSIMD when SVE is enabled.
Fixes: ca40a6e6e39
Cc: qemu-stable@nongnu.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200513163245.17915-15-richard.henderson@linaro.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 525d9b6d42844e187211d25b69be8b378785bc24)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: ad56aecb2101ce751e2e2f39afb60682045068a1
https://github.com/qemu/qemu/commit/ad56aecb2101ce751e2e2f39afb60682045068a1
Author: Raphael Pour <raphael.pour@hetzner.com>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M qemu-nbd.c
Log Message:
-----------
qemu-nbd: Close inherited stderr
Close inherited stderr of the parent if fork_process is false.
Otherwise no one will close it. (introduced by e6df58a5)
This only affected 'qemu-nbd -c /dev/nbd0'.
Signed-off-by: Raphael Pour <raphael.pour@hetzner.com>
Message-Id: <d8ddc993-9816-836e-a3de-c6edab9d9c49@hetzner.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
[eblake: Enhance commit message]
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 0eaf453ebf6788885fbb5d40426b154ef8805407)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: dad6d5e7e613e51b2584c447378a044ccc2fdc81
https://github.com/qemu/qemu/commit/dad6d5e7e613e51b2584c447378a044ccc2fdc81
Author: Greg Kurz <groug@kaod.org>
Date: 2020-06-09 (Tue, 09 Jun 2020)
Changed paths:
M hw/9pfs/9p.h
Log Message:
-----------
9p: Lock directory streams with a CoMutex
Locking was introduced in QEMU 2.7 to address the deprecation of
readdir_r(3) in glibc 2.24. It turns out that the frontend code is
the worst place to handle a critical section with a pthread mutex:
the code runs in a coroutine on behalf of the QEMU mainloop and then
yields control, waiting for the fsdev backend to process the request
in a worker thread. If the client resends another readdir request for
the same fid before the previous one finally unlocked the mutex, we're
deadlocked.
This never bit us because the linux client serializes readdir requests
for the same fid, but it is quite easy to demonstrate with a custom
client.
A good solution could be to narrow the critical section in the worker
thread code and to return a copy of the dirent to the frontend, but
this causes quite some changes in both 9p.c and codir.c. So, instead
of that, in order for people to easily backport the fix to older QEMU
versions, let's simply use a CoMutex since all the users for this
sit in coroutines.
Fixes: 7cde47d4a89d ("9p: add locking to V9fsDir")
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <158981894794.109297.3530035833368944254.stgit@bahia.lan>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit ed463454efd0ac3042ff772bfe1b1d846dc281a5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 252d614ea2b07134155959b987efd68bd7b7100c
https://github.com/qemu/qemu/commit/252d614ea2b07134155959b987efd68bd7b7100c
Author: Thomas Huth <thuth@redhat.com>
Date: 2020-06-15 (Mon, 15 Jun 2020)
Changed paths:
M net/net.c
Log Message:
-----------
net: Do not include a newline in the id of -nic devices
The '\n' sneaked in by accident here, an "id" string should really
not contain a newline character at the end.
Fixes: 78cd6f7bf6b ('net: Add a new convenience option "--nic" ...')
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200518074352.23125-1-thuth@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
(cherry picked from commit 0561dfac082becdd9e89110249a27b309b62aa9f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 0c1d805360a5b8590614471388f8bbb6d5697db5
https://github.com/qemu/qemu/commit/0c1d805360a5b8590614471388f8bbb6d5697db5
Author: Eric Blake <eblake@redhat.com>
Date: 2020-06-15 (Mon, 15 Jun 2020)
Changed paths:
M nbd/server.c
M tests/qemu-iotests/143
M tests/qemu-iotests/143.out
Log Message:
-----------
nbd/server: Avoid long error message assertions CVE-2020-10761
Ever since commit 36683283 (v2.8), the server code asserts that error
strings sent to the client are well-formed per the protocol by not
exceeding the maximum string length of 4096. At the time the server
first started sending error messages, the assertion could not be
triggered, because messages were completely under our control.
However, over the years, we have added latent scenarios where a client
could trigger the server to attempt an error message that would
include the client's information if it passed other checks first:
- requesting NBD_OPT_INFO/GO on an export name that is not present
(commit 0cfae925 in v2.12 echoes the name)
- requesting NBD_OPT_LIST/SET_META_CONTEXT on an export name that is
not present (commit e7b1948d in v2.12 echoes the name)
At the time, those were still safe because we flagged names larger
than 256 bytes with a different message; but that changed in commit
93676c88 (v4.2) when we raised the name limit to 4096 to match the NBD
string limit. (That commit also failed to change the magic number
4096 in nbd_negotiate_send_rep_err to the just-introduced named
constant.) So with that commit, long client names appended to server
text can now trigger the assertion, and thus be used as a denial of
service attack against a server. As a mitigating factor, if the
server requires TLS, the client cannot trigger the problematic paths
unless it first supplies TLS credentials, and such trusted clients are
less likely to try to intentionally crash the server.
We may later want to further sanitize the user-supplied strings we
place into our error messages, such as scrubbing out control
characters, but that is less important to the CVE fix, so it can be a
later patch to the new nbd_sanitize_name.
Consideration was given to changing the assertion in
nbd_negotiate_send_rep_verr to instead merely log a server error and
truncate the message, to avoid leaving a latent path that could
trigger a future CVE DoS on any new error message. However, this
merely complicates the code for something that is already (correctly)
flagging coding errors, and now that we are aware of the long message
pitfall, we are less likely to introduce such errors in the future,
which would make such error handling dead code.
Reported-by: Xueqiang Wei <xuwei@redhat.com>
CC: qemu-stable@nongnu.org
Fixes: https://bugzilla.redhat.com/1843684 CVE-2020-10761
Fixes: 93676c88d7
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200610163741.3745251-2-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
(cherry picked from commit 5c4fe018c025740fef4a0a4421e8162db0c3eefd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e27f334fdc25fd3b3587881091f9cafdd1022ae8
https://github.com/qemu/qemu/commit/e27f334fdc25fd3b3587881091f9cafdd1022ae8
Author: David Hildenbrand <david@redhat.com>
Date: 2020-06-15 (Mon, 15 Jun 2020)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: fix free page hinting without an iothread
In case we don't have an iothread, we mark the feature as abscent but
still add the queue. 'free_page_bh' remains set to NULL.
qemu-system-i386 \
-M microvm \
-nographic \
-device virtio-balloon-device,free-page-hint=true \
-nographic \
-display none \
-monitor none \
-serial none \
-qtest stdio
Doing a "write 0xc0000e30 0x24
0x030000000300000003000000030000000300000003000000030000000300000003000000"
We will trigger a SEGFAULT. Let's move the check and bail out.
While at it, move the static initializations to instance_init().
free_page_report_status and block_iothread are implicitly set to the
right values (0/false) already, so drop the initialization.
Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: c13c4153f76d ("virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT")
Reported-by: Alexander Bulekov <alxndr@bu.edu>
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>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20200520100439.19872-2-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 12fc8903a8ee09fb5f642de82699a0b211e1b5a7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 2a7c80d82e452cdb4f32ad9891d43e9cfa0bd1d6
https://github.com/qemu/qemu/commit/2a7c80d82e452cdb4f32ad9891d43e9cfa0bd1d6
Author: David Hildenbrand <david@redhat.com>
Date: 2020-06-15 (Mon, 15 Jun 2020)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: fix free page hinting check on unrealize
Checking against guest features is wrong. We allocated data structures
based on host features. We can rely on "free_page_bh" as an indicator
whether to un-do stuff instead.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.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>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20200520100439.19872-3-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 49b01711b8eb3796c6904c7f85d2431572cfe54f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: d6d45d9ed1754dea6827f98d8487b3aa0bb56714
https://github.com/qemu/qemu/commit/d6d45d9ed1754dea6827f98d8487b3aa0bb56714
Author: David Hildenbrand <david@redhat.com>
Date: 2020-06-15 (Mon, 15 Jun 2020)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: unref the iothread when unrealizing
We took a reference when realizing, so let's drop that reference when
unrealizing.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alexander Duyck <alexander.h.duyck@linux.intel.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: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20200520100439.19872-4-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 105aef9c9479786d27c1c45c9b0b1fa03dc46be3)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 6c75ddf4a9f317f038a4d94da1b2989fef5dd93b
https://github.com/qemu/qemu/commit/6c75ddf4a9f317f038a4d94da1b2989fef5dd93b
Author: Eric Blake <eblake@redhat.com>
Date: 2020-06-15 (Mon, 15 Jun 2020)
Changed paths:
M block.c
M block/nbd.c
Log Message:
-----------
block: Call attention to truncation of long NBD exports
Commit 93676c88 relaxed our NBD client code to request export names up
to the NBD protocol maximum of 4096 bytes without NUL terminator, even
though the block layer can't store anything longer than 4096 bytes
including NUL terminator for display to the user. Since this means
there are some export names where we have to truncate things, we can
at least try to make the truncation a bit more obvious for the user.
Note that in spite of the truncated display name, we can still
communicate with an NBD server using such a long export name; this was
deemed nicer than refusing to even connect to such a server (since the
server may not be under our control, and since determining our actual
length limits gets tricky when nbd://host:port/export and
nbd+unix:///export?socket=/path are themselves variable-length
expansions beyond the export name but count towards the block layer
name length).
Reported-by: Xueqiang Wei <xuwei@redhat.com>
Fixes: https://bugzilla.redhat.com/1843684
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200610163741.3745251-3-eblake@redhat.com>
(cherry picked from commit 5c86bdf1208916ece0b87e1151c9b48ee54faa3e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 18f6b13e085fdb81f5385bffce35364ab8535303
https://github.com/qemu/qemu/commit/18f6b13e085fdb81f5385bffce35364ab8535303
Author: Jiajun Chen <chenjiajun8@huawei.com>
Date: 2020-06-16 (Tue, 16 Jun 2020)
Changed paths:
M hw/9pfs/9p-local.c
Log Message:
-----------
9pfs: local: Fix possible memory leak in local_link()
There is a possible memory leak while local_link return -1 without free
odirpath and oname.
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Jaijun Chen <chenjiajun8@huawei.com>
Signed-off-by: Xiang Zheng <zhengxiang9@huawei.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 841b8d099c462cd4282c4ced8c2a6512899fd8d9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 03afe9c035884c5901258967cf906de64eff25de
https://github.com/qemu/qemu/commit/03afe9c035884c5901258967cf906de64eff25de
Author: Daniel Henrique Barboza <danielhb413@gmail.com>
Date: 2020-06-16 (Tue, 16 Jun 2020)
Changed paths:
M hw/9pfs/9p-local.c
Log Message:
-----------
9p: local: always return -1 on error in local_unlinkat_common
local_unlinkat_common() is supposed to always return -1 on error.
This is being done by jumps to the 'err_out' label, which is
a 'return ret' call, and 'ret' is initialized with -1.
Unfortunately there is a condition in which the function will
return 0 on error: in a case where flags == AT_REMOVEDIR, 'ret'
will be 0 when reaching
map_dirfd = openat_dir(...)
And, if map_dirfd == -1 and errno != ENOENT, the existing 'err_out'
jump will execute 'return ret', when ret is still set to zero
at that point.
This patch fixes it by changing all 'err_out' labels by
'return -1' calls, ensuring that the function will always
return -1 on error conditions. 'ret' can be left unintialized
since it's now being used just to store the result of 'unlinkat'
calls.
CC: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
[groug: changed prefix in title to be "9p: local:"]
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 846cf408a4c8055063f4a5a71ccf7ed030cdad30)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 603cda272d2590e53039d8fc5317e9f5fb8fffb7
https://github.com/qemu/qemu/commit/603cda272d2590e53039d8fc5317e9f5fb8fffb7
Author: Pan Nengyuan <pannengyuan@huawei.com>
Date: 2020-06-16 (Tue, 16 Jun 2020)
Changed paths:
M hw/9pfs/virtio-9p-device.c
Log Message:
-----------
virtio-9p-device: fix memleak in virtio_9p_device_unrealize
v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak
stack is as follow:
Direct leak of 14336 byte(s) in 2 object(s) allocated from:
#0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970) ??:?
#1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d) ??:?
#2 0x55a3a58da624 (./x86_64-softmmu/qemu-system-x86_64+0x2c14624)
/mnt/sdb/qemu/hw/virtio/virtio.c:2327
#3 0x55a3a571bac7 (./x86_64-softmmu/qemu-system-x86_64+0x2a55ac7)
/mnt/sdb/qemu/hw/9pfs/virtio-9p-device.c:209
#4 0x55a3a58e7bc6 (./x86_64-softmmu/qemu-system-x86_64+0x2c21bc6)
/mnt/sdb/qemu/hw/virtio/virtio.c:3504
#5 0x55a3a5ebfb37 (./x86_64-softmmu/qemu-system-x86_64+0x31f9b37)
/mnt/sdb/qemu/hw/core/qdev.c:876
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200117060927.51996-2-pannengyuan@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Acked-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 9580d60e66d1543a0d79265c0085ee09b8782987)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 410252fc5b2aaef65b793edd37289284c1a4eb91
https://github.com/qemu/qemu/commit/410252fc5b2aaef65b793edd37289284c1a4eb91
Author: Greg Kurz <groug@kaod.org>
Date: 2020-06-16 (Tue, 16 Jun 2020)
Changed paths:
M hw/9pfs/9p-proxy.c
Log Message:
-----------
9p/proxy: Fix export_flags
The common fsdev options are set by qemu_fsdev_add() before it calls
the backend specific option parsing code. In the case of "proxy" this
means "writeout" or "readonly" were simply ignored. This has been
broken from the beginning.
Reported-by: Stéphane Graber <stgraber@ubuntu.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <158349633705.1237488.8895481990204796135.stgit@bahia.lan>
(cherry picked from commit 659f1953281bcfa5ac217e42877d7d3c32eeea38)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 17216bc04494825600b58ebb8a3a6fe0d8052125
https://github.com/qemu/qemu/commit/17216bc04494825600b58ebb8a3a6fe0d8052125
Author: Omar Sandoval <osandov@fb.com>
Date: 2020-06-16 (Tue, 16 Jun 2020)
Changed paths:
M hw/9pfs/9p-util.h
Log Message:
-----------
9pfs: local: ignore O_NOATIME if we don't have permissions
QEMU's local 9pfs server passes through O_NOATIME from the client. If
the QEMU process doesn't have permissions to use O_NOATIME (namely, it
does not own the file nor have the CAP_FOWNER capability), the open will
fail. This causes issues when from the client's point of view, it
believes it has permissions to use O_NOATIME (e.g., a process running as
root in the virtual machine). Additionally, overlayfs on Linux opens
files on the lower layer using O_NOATIME, so in this case a 9pfs mount
can't be used as a lower layer for overlayfs (cf.
https://github.com/osandov/drgn/blob/dabfe1971951701da13863dbe6d8a1d172ad9650/vmtest/onoatimehack.c
and https://github.com/NixOS/nixpkgs/issues/54509).
Luckily, O_NOATIME is effectively a hint, and is often ignored by, e.g.,
network filesystems. open(2) notes that O_NOATIME "may not be effective
on all filesystems. One example is NFS, where the server maintains the
access time." This means that we can honor it when possible but fall
back to ignoring it.
Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Message-Id:
<e9bee604e8df528584693a4ec474ded6295ce8ad.1587149256.git.osandov@fb.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit a5804fcf7b22fc7d1f9ec794dd284c7d504bd16b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 0c6499ff2b1f9614195f31a24f1cf3888ce5d079
https://github.com/qemu/qemu/commit/0c6499ff2b1f9614195f31a24f1cf3888ce5d079
Author: Dan Robertson <dan@dlrobertson.com>
Date: 2020-06-16 (Tue, 16 Jun 2020)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
9pfs: include linux/limits.h for XATTR_SIZE_MAX
linux/limits.h should be included for the XATTR_SIZE_MAX definition used
by v9fs_xattrcreate.
Fixes: 3b79ef2cf488 ("9pfs: limit xattr size in xattrcreate")
Signed-off-by: Dan Robertson <dan@dlrobertson.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <20200515203015.7090-2-dan@dlrobertson.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 03556ea920b23c466ce7c1283199033de33ee671)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 2367c7235b074d816db4b261e472272aa081c76f
https://github.com/qemu/qemu/commit/2367c7235b074d816db4b261e472272aa081c76f
Author: Stefano Stabellini <stefano.stabellini@xilinx.com>
Date: 2020-06-16 (Tue, 16 Jun 2020)
Changed paths:
M hw/9pfs/xen-9p-backend.c
Log Message:
-----------
xen/9pfs: yield when there isn't enough room on the ring
Instead of truncating replies, which is problematic, wait until the
client reads more data and frees bytes on the reply ring.
Do that by calling qemu_coroutine_yield(). The corresponding
qemu_coroutine_enter_if_inactive() is called from xen_9pfs_bh upon
receiving the next notification from the client.
We need to be careful to avoid races in case xen_9pfs_bh and the
coroutine are both active at the same time. In xen_9pfs_bh, wait until
either the critical section is over (ring->co == NULL) or until the
coroutine becomes inactive (qemu_coroutine_yield() was called) before
continuing. Then, simply wake up the coroutine if it is inactive.
Signed-off-by: Stefano Stabellini <stefano.stabellini@xilinx.com>
Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Message-Id: <20200521192627.15259-2-sstabellini@kernel.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit a4c4d462729466c4756bac8a0a8d77eb63b21ef7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 3729ff3032599510600475f3dfd4e30d34923976
https://github.com/qemu/qemu/commit/3729ff3032599510600475f3dfd4e30d34923976
Author: Cole Robinson <crobinso@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M tests/modules-test.c
Log Message:
-----------
tests: fix modules-test 'duplicate test case' error
./configure --enable-sdl --audio-drv-list=sdl --enable-modules
Will generate two identical test names: /$arch/module/load/sdl
Which generates an error like:
(tests/modules-test:23814): GLib-ERROR **: 18:23:06.359: duplicate test case
path: /aarch64//module/load/sdl
Add the subsystem prefix in the name as well, so instead we get:
/$arch/module/load/audio-sdl
/$arch/module/load/ui-sdl
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Message-Id:
<d64c9aa098cc6e5c0b638438c4959eddfa7e24e2.1573679311.git.crobinso@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit eca3a945234a5f0a499860dd11df64b5f1a2e0a5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: a6e44eee6c6567b1cbf0365bd95f9f199d8f2764
https://github.com/qemu/qemu/commit/a6e44eee6c6567b1cbf0365bd95f9f199d8f2764
Author: Pan Nengyuan <pannengyuan@huawei.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/riscv/sifive_u.c
Log Message:
-----------
riscv/sifive_u: fix a memory leak in soc_realize()
Fix a minor memory leak in riscv_sifive_u_soc_realize()
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
(cherry picked from commit bb8136df698bd565ee4f6c18d26c50dee320bfe4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: c1cad76dcd7630333738393625399b8ca0b71e43
https://github.com/qemu/qemu/commit/c1cad76dcd7630333738393625399b8ca0b71e43
Author: Yiting Wang <yiting.wang@windriver.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/riscv/op_helper.c
Log Message:
-----------
riscv: Set xPIE to 1 after xRET
When executing an xRET instruction, supposing xPP holds the
value y, xIE is set to xPIE; the privilege mode is changed to y;
xPIE is set to 1. But QEMU sets xPIE to 0 incorrectly.
Signed-off-by: Yiting Wang <yiting.wang@windriver.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
(cherry picked from commit a37f21c27d3e2342c2080aafd4cfe7e949612428)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: a918ea2ec342cf51bb4a069f6d97f9e704cb048b
https://github.com/qemu/qemu/commit/a918ea2ec342cf51bb4a069f6d97f9e704cb048b
Author: ShihPo Hung <shihpo.hung@sifive.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/riscv/cpu.h
Log Message:
-----------
target/riscv: Fix tb->flags FS status
It was found that running libquantum on riscv-linux qemu produced an
incorrect result. After investigation, FP registers are not saved
during context switch due to incorrect mstatus.FS.
In current implementation tb->flags merges all non-disabled state to
dirty. This means the code in mark_fs_dirty in translate.c that
handles initial and clean states is unreachable.
This patch fixes it and is successfully tested with:
libquantum
Thanks to Richard for pointing out the actual bug.
v3: remove the redundant condition
v2: root cause FS problem
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
(cherry picked from commit 613fa160e19abe8e1fe44423fcfa8ec73d3d48e5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 690e3004aec5601e5f3b1a37962171ab3bb40c6b
https://github.com/qemu/qemu/commit/690e3004aec5601e5f3b1a37962171ab3bb40c6b
Author: ShihPo Hung <shihpo.hung@sifive.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/riscv/insn_trans/trans_rvd.inc.c
M target/riscv/insn_trans/trans_rvf.inc.c
Log Message:
-----------
target/riscv: fsd/fsw doesn't dirty FP state
Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
(cherry picked from commit a59796eb6d59bbd74ce28ddbddb1b83e60674e96)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e727aa1a7b34fcaffb3bf0b4c64aae488f007b15
https://github.com/qemu/qemu/commit/e727aa1a7b34fcaffb3bf0b4c64aae488f007b15
Author: ShihPo Hung <shihpo.hung@sifive.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/riscv/csr.c
M target/riscv/translate.c
Log Message:
-----------
target/riscv: update mstatus.SD when FS is set dirty
remove the check becuase SD bit should summarize FS and XS fields
unconditionally.
Signed-off-by: ShihPo Hung <shihpo.hung@sifive.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
(cherry picked from commit 82f014671cf057de51c4a577c9e2ad637dcec6f9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 54bcaf08d66f9675e5662e061f5c4c0d8f3a2506
https://github.com/qemu/qemu/commit/54bcaf08d66f9675e5662e061f5c4c0d8f3a2506
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
target/i386: do not set unsupported VMX secondary execution controls
Commit 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for
secondary execution controls") added a workaround for KVM pre-dating
commit 6defc591846d ("KVM: nVMX: include conditional controls in /dev/kvm
KVM_GET_MSRS") which wasn't setting certain available controls. The
workaround uses generic CPUID feature bits to set missing VMX controls.
It was found that in some cases it is possible to observe hosts which
have certain CPUID features but lack the corresponding VMX control.
In particular, it was reported that Azure VMs have RDSEED but lack
VMX_SECONDARY_EXEC_RDSEED_EXITING; attempts to enable this feature
bit result in QEMU abort.
Resolve the issue but not applying the workaround when we don't have
to. As there is no good way to find out if KVM has the fix itself, use
95c5c7c77c ("KVM: nVMX: list VMX MSRs in KVM_GET_MSR_INDEX_LIST") instead
as these [are supposed to] come together.
Fixes: 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary
execution controls")
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20200331162752.1209928-1-vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 4a910e1f6ab4155ec8b24c49b2585cc486916985)
Conflicts:
target/i386/kvm.c
*drop context dep. on 6702514814c
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4e98c388d6b07a7b8b760491b07bcfd887c35e23
https://github.com/qemu/qemu/commit/4e98c388d6b07a7b8b760491b07bcfd887c35e23
Author: Felipe Franciosi <felipe@nutanix.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/iscsi.c
Log Message:
-----------
iscsi: Cap block count from GET LBA STATUS (CVE-2020-1711)
When querying an iSCSI server for the provisioning status of blocks (via
GET LBA STATUS), Qemu only validates that the response descriptor zero's
LBA matches the one requested. Given the SCSI spec allows servers to
respond with the status of blocks beyond the end of the LUN, Qemu may
have its heap corrupted by clearing/setting too many bits at the end of
its allocmap for the LUN.
A malicious guest in control of the iSCSI server could carefully program
Qemu's heap (by selectively setting the bitmap) and then smash it.
This limits the number of bits that iscsi_co_block_status() will try to
update in the allocmap so it can't overflow the bitmap.
Fixes: CVE-2020-1711
Cc: qemu-stable@nongnu.org
Signed-off-by: Felipe Franciosi <felipe@nutanix.com>
Signed-off-by: Peter Turschmid <peter.turschm@nutanix.com>
Signed-off-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 693fd2acdf14dd86c0bf852610f1c2cca80a74dc)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 01392ae31a38294c1771eeed0dada1e224493492
https://github.com/qemu/qemu/commit/01392ae31a38294c1771eeed0dada1e224493492
Author: BALATON Zoltan <balaton@eik.bme.hu>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/display/ati_2d.c
Log Message:
-----------
ati-vga: Fix checks in ati_2d_blt() to avoid crash
In some corner cases (that never happen during normal operation but a
malicious guest could program wrong values) pixman functions were
called with parameters that result in a crash. Fix this and add more
checks to disallow such cases.
Reported-by: Ziming Zhang <ezrakiez@gmail.com>
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Message-id: 20200406204029.19559747D5D@zero.eik.bme.hu
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit ac2071c3791b67fc7af78b8ceb320c01ca1b5df7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 69a6048e1ef24a65da45a0c6802ace95066f0f37
https://github.com/qemu/qemu/commit/69a6048e1ef24a65da45a0c6802ace95066f0f37
Author: Prasad J Pandit <pjp@fedoraproject.org>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/display/ati.c
Log Message:
-----------
ati-vga: check mm_index before recursive call (CVE-2020-13800)
While accessing VGA registers via ati_mm_read/write routines,
a guest may set 's->regs.mm_index' such that it leads to infinite
recursion. Check mm_index value to avoid such recursion. Log an
error message for wrong values.
Reported-by: Ren Ding <rding@gatech.edu>
Reported-by: Hanqing Zhao <hanqing@gatech.edu>
Reported-by: Yi Ren <c4tren@gmail.com>
Message-id: 20200604090830.33885-1-ppandit@redhat.com
Suggested-by: BALATON Zoltan <balaton@eik.bme.hu>
Suggested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit a98610c429d52db0937c1e48659428929835c455)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: c436692c6a229f35db1fe24ba60fe04013d92b25
https://github.com/qemu/qemu/commit/c436692c6a229f35db1fe24ba60fe04013d92b25
Author: Prasad J Pandit <pjp@fedoraproject.org>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/audio/es1370.c
Log Message:
-----------
es1370: check total frame count against current frame
A guest user may set channel frame count via es1370_write()
such that, in es1370_transfer_audio(), total frame count
'size' is lesser than the number of frames that are processed
'cnt'.
int cnt = d->frame_cnt >> 16;
int size = d->frame_cnt & 0xffff;
if (size < cnt), it results in incorrect calculations leading
to OOB access issue(s). Add check to avoid it.
Reported-by: Ren Ding <rding@gatech.edu>
Reported-by: Hanqing Zhao <hanqing@gatech.edu>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-id: 20200514200608.1744203-1-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 369ff955a8497988d079c4e3fa1e93c2570c1c69)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 1343d333714e9ff5482d31950cc87890e391ab7b
https://github.com/qemu/qemu/commit/1343d333714e9ff5482d31950cc87890e391ab7b
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M accel/kvm/kvm-all.c
Log Message:
-----------
kvm: Reallocate dirty_bmap when we change a slot
kvm_set_phys_mem can be called to reallocate a slot by something the
guest does (e.g. writing to PAM and other chipset registers).
This can happen in the middle of a migration, and if we're unlucky
it can now happen between the split 'sync' and 'clear'; the clear
asserts if there's no bmap to clear. Recreate the bmap whenever
we change the slot, keeping the clear path happy.
Typically this is triggered by the guest rebooting during a migrate.
Corresponds to:
https://bugzilla.redhat.com/show_bug.cgi?id=1772774
https://bugzilla.redhat.com/show_bug.cgi?id=1771032
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 9b3a31c745b61758aaa5466a3a9fc0526d409188)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 862240852be8ddb6fa720e84e83e234cee848b2f
https://github.com/qemu/qemu/commit/862240852be8ddb6fa720e84e83e234cee848b2f
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M slirp
Log Message:
-----------
slirp: update to fix CVE-2020-1983
This is an update on the stable-4.2 branch of libslirp.git:
git shortlog 55ab21c9a3..2faae0f778f81
Marc-André Lureau (1):
Fix use-afte-free in ip_reass() (CVE-2020-1983)
CVE-2020-1983 is actually a follow up fix for commit
126c04acbabd7ad32c2b018fe10dfac2a3bc1210 ("Fix heap overflow in
ip_reass on big packet input") which was was included in qemu
v4.1 (commit e1a4a24d262ba5ac74ea1795adb3ab1cd574c7fb "slirp: update
with CVE-2019-14378 fix").
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20200421170227.843555-1-marcandre.lureau@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 7769c23774d1278f60b9e40d2c0b98784de6425f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: f127d163979255c35158d1c8c41020e684261e42
https://github.com/qemu/qemu/commit/f127d163979255c35158d1c8c41020e684261e42
Author: Finn Thain <fthain@telegraphics.com.au>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/net/dp8393x.c
Log Message:
-----------
dp8393x: Mask EOL bit from descriptor addresses, take 2
A portion of a recent patch got lost due to a merge snafu. That patch is
now commit 88f632fbb1 ("dp8393x: Mask EOL bit from descriptor addresses").
This patch restores the portion that got lost.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <alpine.LNX.2.22.394.2003041421280.12@nippy.intranet>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
(cherry picked from commit a0cf4297d6b8d88047ab00c467f14aecf9c2a8eb)
Conflicts:
hw/net/dp8393x.c
*drop context dep. on 19f70347
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 2f7597fbc2727eeb4f16c579c9dc0b115a8e5e93
https://github.com/qemu/qemu/commit/2f7597fbc2727eeb4f16c579c9dc0b115a8e5e93
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M tests/qemu-iotests/026
M tests/qemu-iotests/026.out
M tests/qemu-iotests/026.out.nocache
A tests/qemu-iotests/289
A tests/qemu-iotests/289.out
M tests/qemu-iotests/group
Log Message:
-----------
iotests/026: Move v3-exclusive test to new file
data_file does not work with v2, and we probably want 026 to keep
working for v2 images. Thus, open a new file for v3-exclusive error
path test cases.
Fixes: 81311255f217859413c94f2cd9cebf2684bbda94
(“iotests/026: Test EIO on allocation in a data-file”)
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200311140707.1243218-1-mreitz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Tested-by: John Snow <jsnow@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit c264e5d2f9f5d73977eac8e5d084f727b3d07ea9)
Conflicts:
tests/qemu-iotests/group
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: aea7a50fb5e38ccfda741848286a548b72877dfa
https://github.com/qemu/qemu/commit/aea7a50fb5e38ccfda741848286a548b72877dfa
Author: Han Han <hhan@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M qemu-options.hx
Log Message:
-----------
Revert "qemu-options.hx: Update for reboot-timeout parameter"
This reverts commit bbd9e6985ff342cbe15b9cb7eb30e842796fbbe8.
In 20a1922032 we allowed reboot-timeout=-1 again, so update the doc
accordingly.
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20191205024821.245435-1-hhan@redhat.com>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
(cherry picked from commit 8937a39da22e5d5689c516a2d4ce4f2bb6a378fc)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 45b65bf8dfb46a03ff67c36424986e2450c5203e
https://github.com/qemu/qemu/commit/45b65bf8dfb46a03ff67c36424986e2450c5203e
Author: Robert Foley <robert.foley@linaro.org>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M util/log.c
Log Message:
-----------
Fix double free issue in qemu_set_log_filename().
After freeing the logfilename, we set logfilename to NULL, in case of an
error which returns without setting logfilename.
Signed-off-by: Robert Foley <robert.foley@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20191118211528.3221-2-robert.foley@linaro.org>
(cherry picked from commit 0f516ca4767042aec8716369d6d62436fa10593a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 6772bba8a45cda8ab96f124bb148c3ec1f7a4234
https://github.com/qemu/qemu/commit/6772bba8a45cda8ab96f124bb148c3ec1f7a4234
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M tests/qemu-iotests/common.rc
Log Message:
-----------
iotests: Fix IMGOPTSSYNTAX for nbd
There is no $SOCKDIR, only $SOCK_DIR.
Fixes: f3923a72f199b2c63747a7032db74730546f55c6
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit eb4ea9aaa0051054b3c148ad8631be7510851681)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 8d151ab5c2a0b75e8ce7ef9173209cfc41713b44
https://github.com/qemu/qemu/commit/8d151ab5c2a0b75e8ce7ef9173209cfc41713b44
Author: Cole Robinson <crobinso@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M contrib/vhost-user-gpu/50-qemu-gpu.json.in
Log Message:
-----------
vhost-user-gpu: Drop trailing json comma
Trailing comma is not valid json:
$ cat contrib/vhost-user-gpu/50-qemu-gpu.json.in | jq
parse error: Expected another key-value pair at line 5, column 1
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-id:
7f5dd2ac9f3504e2699f23e69bc3d8051b729832.1568925097.git.crobinso@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit ca26b032e5a0e8a190c763ce828a8740d24b9b65)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 7e1bc51f3f606e758b2600555ddc99f643a3697d
https://github.com/qemu/qemu/commit/7e1bc51f3f606e758b2600555ddc99f643a3697d
Author: Cameron Esfahani <dirty@apple.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/display/bochs-display.c
Log Message:
-----------
display/bochs-display: fix memory leak
Fix memory leak in bochs_display_update(). Leaks 304 bytes per frame.
Fixes: 33ebad54056
Signed-off-by: Cameron Esfahani <dirty@apple.com>
Message-Id:
<d6c26e68db134c7b0c7ce8b61596ca2e65e01e12.1576013209.git.dirty@apple.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 0d82411d0e38a0de7829f97d04406765c8d2210d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e8ae3a4e2bb72ae636ecbf201b0f74d4bf7d5aeb
https://github.com/qemu/qemu/commit/e8ae3a4e2bb72ae636ecbf201b0f74d4bf7d5aeb
Author: Simon Veith <sveith@amazon.de>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/arm/smmuv3.c
Log Message:
-----------
hw/arm/smmuv3: Apply address mask to linear strtab base address
In the SMMU_STRTAB_BASE register, the stream table base address only
occupies bits [51:6]. Other bits, such as RA (bit [62]), must be masked
out to obtain the base address.
The branch for 2-level stream tables correctly applies this mask by way
of SMMU_BASE_ADDR_MASK, but the one for linear stream tables does not.
Apply the missing mask in that case as well so that the correct stream
base address is used by guests which configure a linear stream table.
Linux guests are unaffected by this change because they choose a 2-level
stream table layout for the QEMU SMMUv3, based on the size of its stream
ID space.
ref. ARM IHI 0070C, section 6.3.23.
Signed-off-by: Simon Veith <sveith@amazon.de>
Acked-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 1576509312-13083-2-git-send-email-sveith@amazon.de
Cc: Eric Auger <eric.auger@redhat.com>
Cc: qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org
Acked-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 3d44c60500785f18bb469c9de0aeba7415c0f28f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 606a6bf788d37a524c89e2627a44693afb5cb6a1
https://github.com/qemu/qemu/commit/606a6bf788d37a524c89e2627a44693afb5cb6a1
Author: Simon Veith <sveith@amazon.de>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/arm/smmuv3-internal.h
Log Message:
-----------
hw/arm/smmuv3: Correct SMMU_BASE_ADDR_MASK value
There are two issues with the current value of SMMU_BASE_ADDR_MASK:
- At the lower end, we are clearing bits [4:0]. Per the SMMUv3 spec,
we should also be treating bit 5 as zero in the base address.
- At the upper end, we are clearing bits [63:48]. Per the SMMUv3 spec,
only bits [63:52] must be explicitly treated as zero.
Update the SMMU_BASE_ADDR_MASK value to mask out bits [63:52] and [5:0].
ref. ARM IHI 0070C, section 6.3.23.
Signed-off-by: Simon Veith <sveith@amazon.de>
Acked-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 1576509312-13083-3-git-send-email-sveith@amazon.de
Cc: Eric Auger <eric.auger@redhat.com>
Cc: qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 3293b9f514a413e019b7dbc9d543458075b4849e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 256ecc06eb534e7d851fcdf667132a8721b5ad61
https://github.com/qemu/qemu/commit/256ecc06eb534e7d851fcdf667132a8721b5ad61
Author: Simon Veith <sveith@amazon.de>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/arm/smmuv3.c
Log Message:
-----------
hw/arm/smmuv3: Check stream IDs against actual table LOG2SIZE
When checking whether a stream ID is in range of the stream table, we
have so far been only checking it against our implementation limit
(SMMU_IDR1_SIDSIZE). However, the guest can program the
STRTAB_BASE_CFG.LOG2SIZE field to a size that is smaller than this
limit.
Check the stream ID against this limit as well to match the hardware
behavior of raising C_BAD_STREAMID events in case the limit is exceeded.
Also, ensure that we do not go one entry beyond the end of the table by
checking that its index is strictly smaller than the table size.
ref. ARM IHI 0070C, section 6.3.24.
Signed-off-by: Simon Veith <sveith@amazon.de>
Acked-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 1576509312-13083-4-git-send-email-sveith@amazon.de
Cc: Eric Auger <eric.auger@redhat.com>
Cc: qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 05ff2fb80ce4ca85d8a39d48ff8156de739b4f51)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 65fad28d85f137edd895ac90a83b42bb36aad481
https://github.com/qemu/qemu/commit/65fad28d85f137edd895ac90a83b42bb36aad481
Author: Simon Veith <sveith@amazon.de>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/arm/smmuv3.c
Log Message:
-----------
hw/arm/smmuv3: Align stream table base address to table size
Per the specification, and as observed in hardware, the SMMUv3 aligns
the SMMU_STRTAB_BASE address to the size of the table by masking out the
respective least significant bits in the ADDR field.
Apply this masking logic to our smmu_find_ste() lookup function per the
specification.
ref. ARM IHI 0070C, section 6.3.23.
Signed-off-by: Simon Veith <sveith@amazon.de>
Acked-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 1576509312-13083-5-git-send-email-sveith@amazon.de
Cc: Eric Auger <eric.auger@redhat.com>
Cc: qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 41678c33aac61261522b74f08595ccf2221a430a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: ec3bd881e2e5942f835094b2da06ca415f7b27b3
https://github.com/qemu/qemu/commit/ec3bd881e2e5942f835094b2da06ca415f7b27b3
Author: Simon Veith <sveith@amazon.de>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/arm/smmuv3-internal.h
Log Message:
-----------
hw/arm/smmuv3: Use correct bit positions in EVT_SET_ADDR2 macro
The bit offsets in the EVT_SET_ADDR2 macro do not match those specified
in the ARM SMMUv3 Architecture Specification. In all events that use
this macro, e.g. F_WALK_EABT, the faulting fetch address or IPA actually
occupies the 32-bit words 6 and 7 in the event record contiguously, with
the upper and lower unused bits clear due to alignment or maximum
supported address bits. How many bits are clear depends on the
individual event type.
Update the macro to write to the correct words in the event record so
that guest drivers can obtain accurate address information on events.
ref. ARM IHI 0070C, sections 7.3.12 through 7.3.16.
Signed-off-by: Simon Veith <sveith@amazon.de>
Acked-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 1576509312-13083-6-git-send-email-sveith@amazon.de
Cc: Eric Auger <eric.auger@redhat.com>
Cc: qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org
Acked-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit a7f65ceb851af5a5b639c6e30801076d848db2c2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 9b59fdf47822acb6f2f6be5629829f27ffb08d41
https://github.com/qemu/qemu/commit/9b59fdf47822acb6f2f6be5629829f27ffb08d41
Author: Simon Veith <sveith@amazon.de>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/arm/smmuv3.c
Log Message:
-----------
hw/arm/smmuv3: Report F_STE_FETCH fault address in correct word position
The smmuv3_record_event() function that generates the F_STE_FETCH error
uses the EVT_SET_ADDR macro to record the fetch address, placing it in
32-bit words 4 and 5.
The correct position for this address is in words 6 and 7, per the
SMMUv3 Architecture Specification.
Update the function to use the EVT_SET_ADDR2 macro instead, which is the
macro intended for writing to these words.
ref. ARM IHI 0070C, section 7.3.4.
Signed-off-by: Simon Veith <sveith@amazon.de>
Acked-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Message-id: 1576509312-13083-7-git-send-email-sveith@amazon.de
Cc: Eric Auger <eric.auger@redhat.com>
Cc: qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org
Acked-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit b255cafb59578d16716186ed955717bc8f87bdb7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 0972fbf353e436088bbc4180bc13e93245cd7add
https://github.com/qemu/qemu/commit/0972fbf353e436088bbc4180bc13e93245cd7add
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block.c
M include/block/block.h
Log Message:
-----------
block: Add bdrv_qapi_perm_to_blk_perm()
We need some way to correlate QAPI BlockPermission values with
BLK_PERM_* flags. We could:
(1) have the same order in the QAPI definition as the the BLK_PERM_*
flags are in LSb-first order. However, then there is no guarantee
that they actually match (e.g. when someone modifies the QAPI schema
without thinking of the BLK_PERM_* definitions).
We could add static assertions, but these would break what’s good
about this solution, namely its simplicity.
(2) define the BLK_PERM_* flags based on the BlockPermission values.
But this way whenever someone were to modify the QAPI order
(perfectly sensible in theory), the BLK_PERM_* values would change.
Because these values are used for file locking, this might break
file locking between different qemu versions.
Therefore, go the slightly more cumbersome way: Add a function to
translate from the QAPI constants to the BLK_PERM_* flags.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20191108123455.39445-2-mreitz@redhat.com
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 7b1d9c4df0603fbc526226a9c5ef91118aa6c957)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 9a30621d3d5de76f865dc804a1dd16cc517461b6
https://github.com/qemu/qemu/commit/9a30621d3d5de76f865dc804a1dd16cc517461b6
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/blkdebug.c
M qapi/block-core.json
Log Message:
-----------
blkdebug: Allow taking/unsharing permissions
Sometimes it is useful to be able to add a node to the block graph that
takes or unshare a certain set of permissions for debugging purposes.
This patch adds this capability to blkdebug.
(Note that you cannot make blkdebug release or share permissions that it
needs to take or cannot share, because this might result in assertion
failures in the block layer. But if the blkdebug node has no parents,
it will not take any permissions and share everything by default, so you
can then freely choose what permissions to take and share.)
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20191108123455.39445-4-mreitz@redhat.com
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 69c6449ff10fe4e3219e960549307096d5366bd0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e8a286010c4dc5f3965c80d5c66e71bc69e762bf
https://github.com/qemu/qemu/commit/e8a286010c4dc5f3965c80d5c66e71bc69e762bf
Author: Laurent Vivier <lvivier@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M tests/migration-test.c
Log Message:
-----------
migration-test: ppc64: fix FORTH test program
Commit e51e711b1bef has moved the initialization of start_address and
end_address after the definition of the command line argument,
where the nvramrc is initialized, and thus the loop is between 0 and 0
rather than 1 MiB and 100 MiB.
It doesn't affect the result of the test if all the tests are run in
sequence because the two first tests don't run the loop, so the
values are correctly initialized when we actually need them.
But it hangs when we ask to run only one test, for instance:
QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 \
tests/migration-test -m=quick -p /ppc64/migration/validate_uuid_error
Fixes: e51e711b1bef ("tests/migration: Add migration-test header file")
Cc: wei@redhat.com
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Message-Id: <20200107163437.52139-1-lvivier@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 16c5c6928ff53bd95e6504301ef6c285501531e7)
Conflicts:
tests/migration-test.c
*drop context dep. on 68d95609
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: f3ef98874e2b8ea5656cd7026eaf4e150b228426
https://github.com/qemu/qemu/commit/f3ef98874e2b8ea5656cd7026eaf4e150b228426
Author: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/arm/tlb_helper.c
Log Message:
-----------
target/arm: Return correct IL bit in merge_syn_data_abort
The IL bit is set for 32-bit instructions, thus passing false
with the is_16bit parameter to syn_data_abort_with_iss() makes
a syn mask that always has the IL bit set.
Pass is_16bit as true to make the initial syn mask have IL=0,
so that the final IL value comes from or'ing template_syn.
Cc: qemu-stable@nongnu.org
Fixes: aaa1f954d4ca ("target-arm: A64: Create Instruction Syndromes for Data
Aborts")
Signed-off-by: Jeff Kubascik <jeff.kubascik@dornerworks.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20200117004618.2742-2-richard.henderson@linaro.org
[rth: Extracted this as a self-contained bug fix from a larger patch]
Signed-off-by: Richard Henderson <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 30d544839e278dc76017b9a42990c41e84a34377)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: d306348fd65a57c32e36558f450d90d4ed6a03d9
https://github.com/qemu/qemu/commit/d306348fd65a57c32e36558f450d90d4ed6a03d9
Author: Laurent Vivier <lvivier@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M vl.c
Log Message:
-----------
runstate: ignore finishmigrate -> prelaunch transition
Commit 1bd71dce4bf2 tries to prevent a finishmigrate -> prelaunch
transition by exiting at the beginning of the main_loop_should_exit()
function if the state is already finishmigrate.
As the finishmigrate state is set in the migration thread it can
happen concurrently to the function. The migration thread and the
function are normally protected by the iothread mutex and thus the
state should no evolve between the start of the function and its end.
Unfortunately during the function life the lock is released by
pause_all_vcpus() just before the point we need to be sure we are
not in finishmigrate state and if the migration thread is waiting
for the lock it will take the opportunity to change the state
to finishmigrate.
The only way to be sure we are not in the finishmigrate state when
we need is to check the state after the pause_all_vcpus() function.
Fixes: 1bd71dce4bf2 ("runstate: ignore exit request in finish migrate state")
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
(cherry picked from commit ddad81bd28de665475a87693a93e6cf5d6fd8bab)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 52771abbfa6775db8843f2ee365d45be169887cd
https://github.com/qemu/qemu/commit/52771abbfa6775db8843f2ee365d45be169887cd
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M migration/migration.c
M migration/migration.h
M migration/ram.c
M migration/trace-events
Log Message:
-----------
migration: Rate limit inside host pages
When using hugepages, rate limiting is necessary within each huge
page, since a 1G huge page can take a significant time to send, so
you end up with bursty behaviour.
Fixes: 4c011c37ecb3 ("postcopy: Send whole huge pages")
Reported-by: Lin Ma <LMa@suse.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
(cherry picked from commit 97e1e06780e70f6e98a0d2df881e0c0927d3aeb6)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: b5ba361d8f8908ab37a104b0110910926d94d57f
https://github.com/qemu/qemu/commit/b5ba361d8f8908ab37a104b0110910926d94d57f
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M ui/vnc.c
Log Message:
-----------
Revert "vnc: allow fall back to RAW encoding"
This reverts commit de3f7de7f4e257ce44cdabb90f5f17ee99624557.
Remove VNC optimization to reencode framebuffer update as raw if it's
smaller than the default encoding.
QEMU's implementation was naive and didn't account for the ZLIB z_stream
mutating with each compression. Because of the mutation, simply
resetting the output buffer's offset wasn't sufficient to "rewind" the
operation. The mutated z_stream would generate future zlib blocks which
referred to symbols in past blocks which weren't sent. This would lead
to artifacting.
Considering that ZRLE is never larger than raw and even though ZLIB can
occasionally be fractionally larger than raw, the overhead of
implementing this optimization correctly isn't worth it.
Signed-off-by: Cameron Esfahani <dirty@apple.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 0780ec7be82dd4781e9fd216b5d99a125882ff5a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: c44015c50c741ebc267e022542fc110ea97197a0
https://github.com/qemu/qemu/commit/c44015c50c741ebc267e022542fc110ea97197a0
Author: Laurent Vivier <laurent@vivier.eu>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/m68k/translate.c
Log Message:
-----------
m68k: Fix regression causing Single-Step via GDB/RSP to not single step
A regression that was introduced, with the refactor to TranslatorOps,
drops two lines that update the PC when single-stepping is being performed.
Fixes: 11ab74b01e0a ("target/m68k: Convert to TranslatorOps")
Reported-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com>
Suggested-by: Lucien Murray-Pitts <lucienmp_antispam@yahoo.com>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20200116165454.2076265-1-laurent@vivier.eu>
(cherry picked from commit 322f244aaa80a5208090d41481c1c09c6face66b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: abf9ffa7b3dd0d621c0cf5596cd59949ad66d81a
https://github.com/qemu/qemu/commit/abf9ffa7b3dd0d621c0cf5596cd59949ad66d81a
Author: Vincent Dehors <vincent.dehors@smile.fr>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/arm/pauth_helper.c
Log Message:
-----------
target/arm: Fix PAuth sbox functions
In the PAC computation, sbox was applied over wrong bits.
As this is a 4-bit sbox, bit index should be incremented by 4 instead of 16.
Test vector from QARMA paper (https://eprint.iacr.org/2016/444.pdf) was
used to verify one computation of the pauth_computepac() function which
uses sbox2.
Launchpad: https://bugs.launchpad.net/bugs/1859713
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Vincent DEHORS <vincent.dehors@smile.fr>
Signed-off-by: Adrien GRASSEIN <adrien.grassein@smile.fr>
Message-id: 20200116230809.19078-2-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 de0b1bae6461f67243282555475f88b2384a1eb9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: cd8ecfb19cbbdd13f2b2e210c88485bf5f15c51c
https://github.com/qemu/qemu/commit/cd8ecfb19cbbdd13f2b2e210c88485bf5f15c51c
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/i386/kvm.c
M target/i386/kvm_i386.h
Log Message:
-----------
target/i386: kvm: initialize feature MSRs very early
Some read-only MSRs affect the behavior of ioctls such as
KVM_SET_NESTED_STATE. We can initialize them once and for all
right after the CPU is realized, since they will never be modified
by the guest.
Reported-by: Qingua Cheng <qcheng@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1579544504-3616-2-git-send-email-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 420ae1fc51c99abfd03b1c590f55617edd2a2bed)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: bc509b2a5baedb7112afba4dd2ad5f1f67f300a9
https://github.com/qemu/qemu/commit/bc509b2a5baedb7112afba4dd2ad5f1f67f300a9
Author: Cornelia Huck <cohuck@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/intc/s390_flic_kvm.c
M hw/s390x/virtio-ccw.c
Log Message:
-----------
s390x: adapter routes error handling
If the kernel irqchip has been disabled, we don't want the
{add,release}_adapter_routes routines to call any kvm_irqchip_*
interfaces, as they may rely on an irqchip actually having been
created. Just take a quick exit in that case instead. If you are
trying to use irqfd without a kernel irqchip, we will fail with
an error.
Also initialize routes->gsi[] with -1 in the virtio-ccw handling,
to make sure we don't trip over other errors, either. (Nobody
else uses the gsi array in that structure.)
Fixes: d426d9fba8ea ("s390x/virtio-ccw: wire up irq routing and irqfds")
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Message-Id: <20200117111147.5006-1-cohuck@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 3c5fd8074335c67777d9391b84f97070c35d9c63)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: dc6bdba433246e55c930fad38c1267242fae888c
https://github.com/qemu/qemu/commit/dc6bdba433246e55c930fad38c1267242fae888c
Author: Eiichi Tsukata <devel@etsukata.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/backup-top.c
Log Message:
-----------
block/backup: fix memory leak in bdrv_backup_top_append()
bdrv_open_driver() allocates bs->opaque according to drv->instance_size.
There is no need to allocate it and overwrite opaque in
bdrv_backup_top_append().
Reproducer:
$ QTEST_QEMU_BINARY=./x86_64-softmmu/qemu-system-x86_64 valgrind -q
--leak-check=full tests/test-replication -p /replication/secondary/start
==29792== 24 bytes in 1 blocks are definitely lost in loss record 52 of 226
==29792== at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==29792== by 0x4B07CE0: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6000.7)
==29792== by 0x12BAB9: bdrv_open_driver (block.c:1289)
==29792== by 0x12BEA9: bdrv_new_open_driver (block.c:1359)
==29792== by 0x1D15CB: bdrv_backup_top_append (backup-top.c:190)
==29792== by 0x1CC11A: backup_job_create (backup.c:439)
==29792== by 0x1CD542: replication_start (replication.c:544)
==29792== by 0x1401B9: replication_start_all (replication.c:52)
==29792== by 0x128B50: test_secondary_start (test-replication.c:427)
...
Fixes: 7df7868b9640 ("block: introduce backup-top filter driver")
Signed-off-by: Eiichi Tsukata <devel@etsukata.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit fb574de81bfdd71fdb0315105a3a7761efb68395)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: b1b362aa8e4809d85c682f9da100473dd22f28c7
https://github.com/qemu/qemu/commit/b1b362aa8e4809d85c682f9da100473dd22f28c7
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/tpm/tpm_ppi.c
Log Message:
-----------
tpm-ppi: page-align PPI RAM
post-copy migration fails on destination with error such as:
2019-12-26T10:22:44.714644Z qemu-kvm: ram_block_discard_range:
Unaligned start address: 0x559d2afae9a0
Use qemu_memalign() to constrain the PPI RAM memory alignment.
Cc: qemu-stable@nongnu.org
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Message-id: 20200103074000.1006389-3-marcandre.lureau@redhat.com
(cherry picked from commit 71e415c8a75c130875f14d6b2136825789feb297)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 9adb6569bf71808e76a7b71766e73a6da103741e
https://github.com/qemu/qemu/commit/9adb6569bf71808e76a7b71766e73a6da103741e
Author: Zenghui Yu <yuzenghui@huawei.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/intc/arm_gicv3_kvm.c
Log Message:
-----------
hw/intc/arm_gicv3_kvm: Stop wrongly programming GICR_PENDBASER.PTZ bit
If LPIs are disabled, KVM will just ignore the GICR_PENDBASER.PTZ bit when
restoring GICR_CTLR. Setting PTZ here makes littlt sense in "reduce GIC
initialization time".
And what's worse, PTZ is generally programmed by guest to indicate to the
Redistributor whether the LPI Pending table is zero when enabling LPIs.
If migration is triggered when the PTZ has just been cleared by guest (and
before enabling LPIs), we will see PTZ==1 on the destination side, which
is not as expected. Let's just drop this hackish userspace behavior.
Also take this chance to refine the comment a bit.
Fixes: 367b9f527bec ("hw/intc/arm_gicv3_kvm: Implement get/put functions")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Message-id: 20200119133051.642-1-yuzenghui@huawei.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 618bacabd3c8c3360be795cd8763bacdf5bec101)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4b34c6d7248d4e78203db94c79abfed7b0549076
https://github.com/qemu/qemu/commit/4b34c6d7248d4e78203db94c79abfed7b0549076
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M audio/ossaudio.c
Log Message:
-----------
audio/oss: fix buffer pos calculation
Fixes: 3ba4066d085f ("ossaudio: port to the new audio backend api")
Reported-by: ziming zhang <ezrakiez@gmail.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20200120101804.29578-1-kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
(cherry picked from commit 7a4ede0047a8613b0e3b72c9d351038f013dd357)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: aacf6bfb7edc5aaab2bc2fddfd6fd481cb877bc6
https://github.com/qemu/qemu/commit/aacf6bfb7edc5aaab2bc2fddfd6fd481cb877bc6
Author: Alex Bennée <alex.bennee@linaro.org>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/arm/translate-a64.c
Log Message:
-----------
target/arm: fix TCG leak for fcvt half->double
When support for the AHP flag was added we inexplicably only freed the
new temps in one of the two legs. Move those tcg_temp_free to the same
level as the allocation to fix that leak.
Fixes: 486624fcd3eac
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20200131153439.26027-1-alex.bennee@linaro.org
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit aeab8e5eb220cc5ff84b0b68b9afccc611bf0fcd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: a967e75f3a65ccfca3e793e4cb8223449f20a9c5
https://github.com/qemu/qemu/commit/a967e75f3a65ccfca3e793e4cb8223449f20a9c5
Author: Pan Nengyuan <pannengyuan@huawei.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block.c
Log Message:
-----------
block: fix memleaks in bdrv_refresh_filename
If we call the qmp 'query-block' while qemu is working on
'block-commit', it will cause memleaks, the memory leak stack is as
follow:
Indirect leak of 12360 byte(s) in 3 object(s) allocated from:
#0 0x7f80f0b6d970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970)
#1 0x7f80ee86049d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d)
#2 0x55ea95b5bb67 in qdict_new /mnt/sdb/qemu-4.2.0-rc0/qobject/qdict.c:29
#3 0x55ea956cd043 in bdrv_refresh_filename
/mnt/sdb/qemu-4.2.0-rc0/block.c:6427
#4 0x55ea956cc950 in bdrv_refresh_filename
/mnt/sdb/qemu-4.2.0-rc0/block.c:6399
#5 0x55ea956cc950 in bdrv_refresh_filename
/mnt/sdb/qemu-4.2.0-rc0/block.c:6399
#6 0x55ea956cc950 in bdrv_refresh_filename
/mnt/sdb/qemu-4.2.0-rc0/block.c:6399
#7 0x55ea958818ea in bdrv_block_device_info
/mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:56
#8 0x55ea958879de in bdrv_query_info
/mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:392
#9 0x55ea9588b58f in qmp_query_block
/mnt/sdb/qemu-4.2.0-rc0/block/qapi.c:578
#10 0x55ea95567392 in qmp_marshal_query_block
qapi/qapi-commands-block-core.c:95
Indirect leak of 4120 byte(s) in 1 object(s) allocated from:
#0 0x7f80f0b6d970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970)
#1 0x7f80ee86049d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d)
#2 0x55ea95b5bb67 in qdict_new /mnt/sdb/qemu-4.2.0-rc0/qobject/qdict.c:29
#3 0x55ea956cd043 in bdrv_refresh_filename
/mnt/sdb/qemu-4.2.0-rc0/block.c:6427
#4 0x55ea956cc950 in bdrv_refresh_filename
/mnt/sdb/qemu-4.2.0-rc0/block.c:6399
#5 0x55ea956cc950 in bdrv_refresh_filename
/mnt/sdb/qemu-4.2.0-rc0/block.c:6399
#6 0x55ea9569f301 in bdrv_backing_attach
/mnt/sdb/qemu-4.2.0-rc0/block.c:1064
#7 0x55ea956a99dd in bdrv_replace_child_noperm
/mnt/sdb/qemu-4.2.0-rc0/block.c:2283
#8 0x55ea956b9b53 in bdrv_replace_node /mnt/sdb/qemu-4.2.0-rc0/block.c:4196
#9 0x55ea956b9e49 in bdrv_append /mnt/sdb/qemu-4.2.0-rc0/block.c:4236
#10 0x55ea958c3472 in commit_start
/mnt/sdb/qemu-4.2.0-rc0/block/commit.c:306
#11 0x55ea94b68ab0 in qmp_block_commit
/mnt/sdb/qemu-4.2.0-rc0/blockdev.c:3459
#12 0x55ea9556a7a7 in qmp_marshal_block_commit
qapi/qapi-commands-block-core.c:407
Fixes: bb808d5f5c0978828a974d547e6032402c339555
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-id: 20200116085600.24056-1-pannengyuan@huawei.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit cb8956144ccaccf23d5cc4167677e2c84fa5a9f8)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e92b21ffc402b0feec5703a718affd9453a2a196
https://github.com/qemu/qemu/commit/e92b21ffc402b0feec5703a718affd9453a2a196
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/backup-top.c
Log Message:
-----------
block/backup-top: fix failure path
We can't access top after call bdrv_backup_top_drop, as it is already
freed at this time.
Also, no needs to unref target child by hand, it will be unrefed on
bdrv_close() automatically.
So, just do bdrv_backup_top_drop if append succeed and one bdrv_unref
otherwise.
Note, that in !appended case bdrv_unref(top) moved into drained section
on source. It doesn't really matter, but just for code simplicity.
Fixes: 7df7868b96404
Cc: qemu-stable@nongnu.org # v4.2.0
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 20200121142802.21467-2-vsementsov@virtuozzo.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 0df62f45c1de6c020f1e6fba4eeafd248209b003)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 8952da32c36b8d457d0ebe28c252a7eeab68f127
https://github.com/qemu/qemu/commit/8952da32c36b8d457d0ebe28c252a7eeab68f127
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
A tests/qemu-iotests/283
A tests/qemu-iotests/283.out
M tests/qemu-iotests/group
Log Message:
-----------
iotests: add test for backup-top failure on permission activation
This test checks that bug is really fixed by previous commit.
Cc: qemu-stable@nongnu.org # v4.2.0
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20200121142802.21467-3-vsementsov@virtuozzo.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit a541fcc27c98b96da187c7d4573f3270f3ddd283)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: ee9f37f3e5377dfd91045afd2b6ec8e9c75cb191
https://github.com/qemu/qemu/commit/ee9f37f3e5377dfd91045afd2b6ec8e9c75cb191
Author: Liang Yan <lyan@suse.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/arm/monitor.c
Log Message:
-----------
target/arm/monitor: query-cpu-model-expansion crashed qemu when using machine
type none
Commit e19afd566781 mentioned that target-arm only supports queryable
cpu models 'max', 'host', and the current type when KVM is in use.
The logic works well until using machine type none.
For machine type none, cpu_type will be null if cpu option is not
set by command line, strlen(cpu_type) will terminate process.
So We add a check above it.
This won't affect i386 and s390x since they do not use current_cpu.
Signed-off-by: Liang Yan <lyan@suse.com>
Message-id: 20200203134251.12986-1-lyan@suse.com
Reviewed-by: Andrew Jones <drjones@redhat.com>
Tested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 0999a4ba8718aa96105b978d3567fc7e90244c7e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 3dd28c8ecc2fe3907fe0b096b4b715c106989542
https://github.com/qemu/qemu/commit/3dd28c8ecc2fe3907fe0b096b4b715c106989542
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/io.c
Log Message:
-----------
block: fix crash on zero-length unaligned write and read
Commit 7a3f542fbd "block/io: refactor padding" occasionally dropped
aligning for zero-length request: bdrv_init_padding() blindly return
false if bytes == 0, like there is nothing to align.
This leads the following command to crash:
./qemu-io --image-opts -c 'write 1 0' \
driver=blkdebug,align=512,image.driver=null-co,image.size=512
>> qemu-io: block/io.c:1955: bdrv_aligned_pwritev: Assertion
`(offset & (align - 1)) == 0' failed.
>> Aborted (core dumped)
Prior to 7a3f542fbd we does aligning of such zero requests. Instead of
recovering this behavior let's just do nothing on such requests as it
is useless.
Note that driver may have special meaning of zero-length reqeusts, like
qcow2_co_pwritev_compressed_part, so we can't skip any zero-length
operation. But for unaligned ones, we can't pass it to driver anyway.
This commit also fixes crash in iotest 80 running with -nocache:
./check -nocache -qcow2 80
which crashes on same assertion due to trying to read empty extra data
in qcow2_do_read_snapshots().
Cc: qemu-stable@nongnu.org # v4.2
Fixes: 7a3f542fbd
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 20200206164245.17781-1-vsementsov@virtuozzo.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit ac9d00bf7b47acae6b0e42910d9ed55fef3af5b8)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 0b487ea66409be1984ed55d3de71000ac363644f
https://github.com/qemu/qemu/commit/0b487ea66409be1984ed55d3de71000ac363644f
Author: Max Reitz <mreitz@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/qapi.c
Log Message:
-----------
block: Fix VM size field width in snapshot dump
When printing the snapshot list (e.g. with qemu-img snapshot -l), the VM
size field is only seven characters wide. As of de38b5005e9, this is
not necessarily sufficient: We generally print three digits, and this
may require a decimal point. Also, the unit field grew from something
as plain as "M" to " MiB". This means that number and unit may take up
eight characters in total; but we also want spaces in front.
Considering previously the maximum width was four characters and the
field width was chosen to be three characters wider, let us adjust the
field width to be eleven now.
Fixes: de38b5005e946aa3714963ea4c501e279e7d3666
Buglink: https://bugs.launchpad.net/qemu/+bug/1859989
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200117105859.241818-2-mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 804359b8b90f76d9d8fbe8d85a6544b68f107f10)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 1509a1324048d90913de11674d68c0b43a3a555e
https://github.com/qemu/qemu/commit/1509a1324048d90913de11674d68c0b43a3a555e
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/arm/helper.c
Log Message:
-----------
target/arm: Correct definition of PMCRDP
The PMCR_EL0.DP bit is bit 5, which is 0x20, not 0x10. 0x10 is 'X'.
Correct our #define of PMCRDP and add the missing PMCRX.
We do have the correct behaviour for handling the DP bit being
set, so this fixes a guest-visible bug.
Fixes: 033614c47de
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20200214175116.9164-17-peter.maydell@linaro.org
(cherry picked from commit a1ed04dd79aabb9dbeeb5fa7d49f1a3de0357553)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 5e063a5846e5f2d85646a8019e7c8b8de8f25015
https://github.com/qemu/qemu/commit/5e063a5846e5f2d85646a8019e7c8b8de8f25015
Author: Pan Nengyuan <pannengyuan@huawei.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/virtio/virtio-pmem.c
Log Message:
-----------
virtio-pmem: do delete rq_vq in virtio_pmem_unrealize
Similar to other virtio-devices, rq_vq forgot to delete in
virtio_pmem_unrealize, this patch fix it. This device has already
maintained a vq pointer, thus we use the new virtio_delete_queue
function directly to do the cleanup.
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Message-Id: <20200225075554.10835-4-pannengyuan@huawei.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 9861546e1dae05c5152de7d3bd14e341ecadc972)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: e08de99abe4f3da8df01fa478a23b96c04b1001c
https://github.com/qemu/qemu/commit/e08de99abe4f3da8df01fa478a23b96c04b1001c
Author: Pan Nengyuan <pannengyuan@huawei.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/virtio/virtio-crypto.c
Log Message:
-----------
virtio-crypto: do delete ctrl_vq in virtio_crypto_device_unrealize
Similar to other virtio-deivces, ctrl_vq forgot to delete in
virtio_crypto_device_unrealize, this patch fix it.
This device has aleardy maintained vq pointers. Thus, we use the new
virtio_delete_queue function directly to do the cleanup.
The leak stack:
Direct leak of 10752 byte(s) in 3 object(s) allocated from:
#0 0x7f4c024b1970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970)
#1 0x7f4c018be49d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d)
#2 0x55a2f8017279 in virtio_add_queue
/mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:2333
#3 0x55a2f8057035 in virtio_crypto_device_realize
/mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio-crypto.c:814
#4 0x55a2f8005d80 in virtio_device_realize
/mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio.c:3531
#5 0x55a2f8497d1b in device_set_realized
/mnt/sdb/qemu-new/qemu_test/qemu/hw/core/qdev.c:891
#6 0x55a2f8b48595 in property_set_bool
/mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:2238
#7 0x55a2f8b54fad in object_property_set_qobject
/mnt/sdb/qemu-new/qemu_test/qemu/qom/qom-qobject.c:26
#8 0x55a2f8b4de2c in object_property_set_bool
/mnt/sdb/qemu-new/qemu_test/qemu/qom/object.c:1390
#9 0x55a2f80609c9 in virtio_crypto_pci_realize
/mnt/sdb/qemu-new/qemu_test/qemu/hw/virtio/virtio-crypto-pci.c:58
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Cc: "Gonglei (Arei)" <arei.gonglei@huawei.com>
Message-Id: <20200225075554.10835-5-pannengyuan@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit d56e1c8256cb37e68f9b5d98c6cc4e6ca463f1fd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4e258da94a18a6738e2378aa63e96e14f553e6ab
https://github.com/qemu/qemu/commit/4e258da94a18a6738e2378aa63e96e14f553e6ab
Author: Pan Nengyuan <pannengyuan@huawei.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/block/vhost-user-blk.c
Log Message:
-----------
vhost-user-blk: delete virtioqueues in unrealize to fix memleaks
virtio queues forgot to delete in unrealize, and aslo error path in
realize, this patch fix these memleaks, the leak stack is as follow:
Direct leak of 114688 byte(s) in 16 object(s) allocated from:
#0 0x7f24024fdbf0 in calloc (/lib64/libasan.so.3+0xcabf0)
#1 0x7f2401642015 in g_malloc0 (/lib64/libglib-2.0.so.0+0x50015)
#2 0x55ad175a6447 in virtio_add_queue /mnt/sdb/qemu/hw/virtio/virtio.c:2327
#3 0x55ad17570cf9 in vhost_user_blk_device_realize
/mnt/sdb/qemu/hw/block/vhost-user-blk.c:419
#4 0x55ad175a3707 in virtio_device_realize
/mnt/sdb/qemu/hw/virtio/virtio.c:3509
#5 0x55ad176ad0d1 in device_set_realized /mnt/sdb/qemu/hw/core/qdev.c:876
#6 0x55ad1781ff9d in property_set_bool /mnt/sdb/qemu/qom/object.c:2080
#7 0x55ad178245ae in object_property_set_qobject
/mnt/sdb/qemu/qom/qom-qobject.c:26
#8 0x55ad17821eb4 in object_property_set_bool
/mnt/sdb/qemu/qom/object.c:1338
#9 0x55ad177aeed7 in virtio_pci_realize
/mnt/sdb/qemu/hw/virtio/virtio-pci.c:1801
Reported-by: Euler Robot <euler.robot@huawei.com>
Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-Id: <20200224041336.30790-2-pannengyuan@huawei.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 13e5468127111bf44c5dc314d1dd2ec5a65dfec4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 9dd68ac26b5a413dc948efe9bbf414702bc200da
https://github.com/qemu/qemu/commit/9dd68ac26b5a413dc948efe9bbf414702bc200da
Author: Niek Linnenbank <nieklinnenbank@gmail.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/arm/cubieboard.c
Log Message:
-----------
hw/arm/cubieboard: use ARM Cortex-A8 as the default CPU in machine definition
The Cubieboard is a singleboard computer with an Allwinner A10 System-on-Chip
[1].
As documented in the Allwinner A10 User Manual V1.5 [2], the SoC has an ARM
Cortex-A8 processor. Currently the Cubieboard machine definition specifies the
ARM Cortex-A9 in its description and as the default CPU.
This patch corrects the Cubieboard machine definition to use the ARM Cortex-A8.
The only user-visible effect is that our textual description of the
machine was wrong, because hw/arm/allwinner-a10.c always creates a
Cortex-A8 CPU regardless of the default value in the MachineClass struct.
[1] http://docs.cubieboard.org/products/start#cubieboard1
[2] https://linux-sunxi.org/File:Allwinner_A10_User_manual_V1.5.pdf
Fixes: 8a863c8120994981a099
Signed-off-by: Niek Linnenbank <nieklinnenbank@gmail.com>
Message-id: 20200227220149.6845-2-nieklinnenbank@gmail.com
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[note in commit message that the bug didn't have much visible effect]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 2104df2a1fbf44b2564427aa72fd58d66ce290a7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 580c08b326c1b24f3ad3d1ab0b04fae16807af18
https://github.com/qemu/qemu/commit/580c08b326c1b24f3ad3d1ab0b04fae16807af18
Author: Janosch Frank <frankja@linux.ibm.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M pc-bios/s390-ccw/jump2ipl.c
M pc-bios/s390-ccw/main.c
M pc-bios/s390-ccw/netmain.c
M pc-bios/s390-ccw/s390-arch.h
M pc-bios/s390-ccw/s390-ccw.h
Log Message:
-----------
pc-bios: s390x: Save iplb location in lowcore
The POP states that for a list directed IPL the IPLB is stored into
memory by the machine loader and its address is stored at offset 0x14
of the lowcore.
ZIPL currently uses the address in offset 0x14 to access the IPLB and
acquire flags about secure boot. If the IPLB address points into
memory which has an unsupported mix of flags set, ZIPL will panic
instead of booting the OS.
As the lowcore can have quite a high entropy for a guest that did drop
out of protected mode (i.e. rebooted) we encountered the ZIPL panic
quite often.
Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Tested-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Message-Id: <20200304114231.23493-19-frankja@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
(cherry picked from commit 9bfc04f9ef6802fff0fc77130ff345a541783363)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: c6decabc4a30b841e031a838206286db6ad343bc
https://github.com/qemu/qemu/commit/c6decabc4a30b841e031a838206286db6ad343bc
Author: Eric Blake <eblake@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M tests/qemu-iotests/common.rc
Log Message:
-----------
iotests: Fix nonportable use of od --endian
Tests 261 and 272 fail on RHEL 7 with coreutils 8.22, since od
--endian was not added until coreutils 8.23. Fix this by manually
constructing the final value one byte at a time.
Fixes: fc8ba423
Reported-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200226125424.481840-1-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 69135eb30b9c3fca583737a96df015174dc8e6dd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 745859d5bf33f5ff80f00499c822079d9335d3ed
https://github.com/qemu/qemu/commit/745859d5bf33f5ff80f00499c822079d9335d3ed
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/ppc/ppc405_boards.c
Log Message:
-----------
ppc/ppc405_boards: Remove unnecessary NULL check
This code is inside the "if (dinfo)" condition, so testing
again here whether it is NULL is unnecessary.
Fixes: dd59bcae7 (Don't size flash memory to match backing image)
Reported-by: Coverity (CID 1421917)
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200320155740.5342-1-philmd@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 1583794b9b36911df116cc726750dadbeeac506a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 47e0fa74799c23dc29ff0adb356d82425b166231
https://github.com/qemu/qemu/commit/47e0fa74799c23dc29ff0adb356d82425b166231
Author: Eric Blake <eblake@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/qcow2.c
Log Message:
-----------
block: Avoid memleak on qcow2 image info failure
If we fail to get bitmap info, we must not leak the encryption info.
Fixes: b8968c875f403
Fixes: Coverity CID 1421894
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200320183620.1112123-1-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Tested-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 71eaec2e8c7c8d266137b5c5f42da0bd6d6b5eb7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 5ff78dc9bcf2a81f097f1137e58f9a0759347d91
https://github.com/qemu/qemu/commit/5ff78dc9bcf2a81f097f1137e58f9a0759347d91
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block.c
Log Message:
-----------
block: bdrv_set_backing_bs: fix use-after-free
There is a use-after-free possible: bdrv_unref_child() leaves
bs->backing freed but not NULL. bdrv_attach_child may produce nested
polling loop due to drain, than access of freed pointer is possible.
I've produced the following crash on 30 iotest with modified code. It
does not reproduce on master, but still seems possible:
#0 __strcmp_avx2 () at /lib64/libc.so.6
#1 bdrv_backing_overridden (bs=0x55c9d3cc2060) at block.c:6350
#2 bdrv_refresh_filename (bs=0x55c9d3cc2060) at block.c:6404
#3 bdrv_backing_attach (c=0x55c9d48e5520) at block.c:1063
#4 bdrv_replace_child_noperm
(child=child@entry=0x55c9d48e5520,
new_bs=new_bs@entry=0x55c9d3cc2060) at block.c:2290
#5 bdrv_replace_child
(child=child@entry=0x55c9d48e5520,
new_bs=new_bs@entry=0x55c9d3cc2060) at block.c:2320
#6 bdrv_root_attach_child
(child_bs=child_bs@entry=0x55c9d3cc2060,
child_name=child_name@entry=0x55c9d241d478 "backing",
child_role=child_role@entry=0x55c9d26ecee0 <child_backing>,
ctx=<optimized out>, perm=<optimized out>, shared_perm=21,
opaque=0x55c9d3c5a3d0, errp=0x7ffd117108e0) at block.c:2424
#7 bdrv_attach_child
(parent_bs=parent_bs@entry=0x55c9d3c5a3d0,
child_bs=child_bs@entry=0x55c9d3cc2060,
child_name=child_name@entry=0x55c9d241d478 "backing",
child_role=child_role@entry=0x55c9d26ecee0 <child_backing>,
errp=errp@entry=0x7ffd117108e0) at block.c:5876
#8 in bdrv_set_backing_hd
(bs=bs@entry=0x55c9d3c5a3d0,
backing_hd=backing_hd@entry=0x55c9d3cc2060,
errp=errp@entry=0x7ffd117108e0)
at block.c:2576
#9 stream_prepare (job=0x55c9d49d84a0) at block/stream.c:150
#10 job_prepare (job=0x55c9d49d84a0) at job.c:761
#11 job_txn_apply (txn=<optimized out>, fn=<optimized out>) at
job.c:145
#12 job_do_finalize (job=0x55c9d49d84a0) at job.c:778
#13 job_completed_txn_success (job=0x55c9d49d84a0) at job.c:832
#14 job_completed (job=0x55c9d49d84a0) at job.c:845
#15 job_completed (job=0x55c9d49d84a0) at job.c:836
#16 job_exit (opaque=0x55c9d49d84a0) at job.c:864
#17 aio_bh_call (bh=0x55c9d471a160) at util/async.c:117
#18 aio_bh_poll (ctx=ctx@entry=0x55c9d3c46720) at util/async.c:117
#19 aio_poll (ctx=ctx@entry=0x55c9d3c46720,
blocking=blocking@entry=true)
at util/aio-posix.c:728
#20 bdrv_parent_drained_begin_single (poll=true, c=0x55c9d3d558f0)
at block/io.c:121
#21 bdrv_parent_drained_begin_single (c=c@entry=0x55c9d3d558f0,
poll=poll@entry=true)
at block/io.c:114
#22 bdrv_replace_child_noperm
(child=child@entry=0x55c9d3d558f0,
new_bs=new_bs@entry=0x55c9d3d27300) at block.c:2258
#23 bdrv_replace_child
(child=child@entry=0x55c9d3d558f0,
new_bs=new_bs@entry=0x55c9d3d27300) at block.c:2320
#24 bdrv_root_attach_child
(child_bs=child_bs@entry=0x55c9d3d27300,
child_name=child_name@entry=0x55c9d241d478 "backing",
child_role=child_role@entry=0x55c9d26ecee0 <child_backing>,
ctx=<optimized out>, perm=<optimized out>, shared_perm=21,
opaque=0x55c9d3cc2060, errp=0x7ffd11710c60) at block.c:2424
#25 bdrv_attach_child
(parent_bs=parent_bs@entry=0x55c9d3cc2060,
child_bs=child_bs@entry=0x55c9d3d27300,
child_name=child_name@entry=0x55c9d241d478 "backing",
child_role=child_role@entry=0x55c9d26ecee0 <child_backing>,
errp=errp@entry=0x7ffd11710c60) at block.c:5876
#26 bdrv_set_backing_hd
(bs=bs@entry=0x55c9d3cc2060,
backing_hd=backing_hd@entry=0x55c9d3d27300,
errp=errp@entry=0x7ffd11710c60)
at block.c:2576
#27 stream_prepare (job=0x55c9d495ead0) at block/stream.c:150
...
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200316060631.30052-2-vsementsov@virtuozzo.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 6e57963a77df1e275a73dab4c6a7ec9a9d3468d4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 674d3822250a8830fb8e9720ce499f2e8cef6a88
https://github.com/qemu/qemu/commit/674d3822250a8830fb8e9720ce499f2e8cef6a88
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M monitor/hmp-cmds.c
Log Message:
-----------
hmp/vnc: Fix info vnc list leak
We're iterating the list, and then freeing the iteration pointer rather
than the list head.
Fixes: 0a9667ecdb6d ("hmp: Update info vnc")
Reported-by: Coverity (CID 1421932)
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20200323120822.51266-1-dgilbert@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit d4ff109373ce871928c7e9ef648973eba642b484)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 09397e965739bd7da25bf1739a89fe2f245e8446
https://github.com/qemu/qemu/commit/09397e965739bd7da25bf1739a89fe2f245e8446
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M migration/colo.c
Log Message:
-----------
migration/colo: fix use after free of local_err
local_err is used again in secondary_vm_do_failover() after
replication_stop_all(), so we must zero it. Otherwise try to set
non-NULL local_err will crash.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200324153630.11882-5-vsementsov@virtuozzo.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit 27d07fcfa70c3afa0664288cbce5334ed9595a3a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 1c8d9fb334322762fe2feefa3c6d29571ddea513
https://github.com/qemu/qemu/commit/1c8d9fb334322762fe2feefa3c6d29571ddea513
Author: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M migration/ram.c
Log Message:
-----------
migration/ram: fix use after free of local_err
local_err is used again in migration_bitmap_sync_precopy() after
precopy_notify(), so we must zero it. Otherwise try to set
non-NULL local_err will crash.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200324153630.11882-6-vsementsov@virtuozzo.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit b4a1733c5e6827c72b0dcfa295e07ef7b1ebccff)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 5eca12bbada69fbef88a6557d79f016aaf3ff013
https://github.com/qemu/qemu/commit/5eca12bbada69fbef88a6557d79f016aaf3ff013
Author: Eric Blake <eblake@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/qcow2.c
M docs/interop/qcow2.txt
M tests/qemu-iotests/031.out
M tests/qemu-iotests/036.out
M tests/qemu-iotests/061.out
Log Message:
-----------
qcow2: List autoclear bit names in header
The feature table is supposed to advertise the name of all feature
bits that we support; however, we forgot to update the table for
autoclear bits. While at it, move the table to read-only memory in
code, and tweak the qcow2 spec to name the second autoclear bit.
Update iotests that are affected by the longer header length.
Fixes: 88ddffae
Fixes: 93c24936
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20200324174233.1622067-3-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit bb40ebce2cb0bd4bf37968074d43d5a864fb6dee)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 60c21aa0171f316ab9351951b9dbdd889ab70712
https://github.com/qemu/qemu/commit/60c21aa0171f316ab9351951b9dbdd889ab70712
Author: Eric Blake <eblake@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/sheepdog.c
Log Message:
-----------
sheepdog: Consistently set bdrv_has_zero_init_truncate
block_int.h claims that .bdrv_has_zero_init must return 0 if
.bdrv_has_zero_init_truncate does likewise; but this is violated if
only the former callback is provided if .bdrv_co_truncate also exists.
When adding the latter callback, it was mistakenly added to only one
of the three possible sheepdog instantiations.
Fixes: 1dcaf527
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200324174233.1622067-5-eblake@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit ed049910637be991c88cc25c864115bc5b1e4dab)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: fb6a24fb1ddee56433bd8452375c2790cf087883
https://github.com/qemu/qemu/commit/fb6a24fb1ddee56433bd8452375c2790cf087883
Author: Prasad J Pandit <pjp@fedoraproject.org>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/net/tulip.c
Log Message:
-----------
net: tulip: check frame size and r/w data length
Tulip network driver while copying tx/rx buffers does not check
frame size against r/w data length. This may lead to OOB buffer
access. Add check to avoid it.
Limit iterations over descriptors to avoid potential infinite
loop issue in tulip_xmit_list_update.
Reported-by: Li Qiang <pangpei.lq@antfin.com>
Reported-by: Ziming Zhang <ezrakiez@gmail.com>
Reported-by: Jason Wang <jasowang@redhat.com>
Tested-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 8ffb7265af64ec81748335ec8f20e7ab542c3850)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 9c2e242077f7ea6a558ed5828a83f26098077990
https://github.com/qemu/qemu/commit/9c2e242077f7ea6a558ed5828a83f26098077990
Author: David Gibson <david@gibson.dropbear.id.au>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/ppc/spapr_pci.c
Log Message:
-----------
spapr: Fix failure path for attempting to hot unplug PCI bridges
For various technical reasons we can't currently allow unplug a PCI to PCI
bridge on the pseries machine. spapr_pci_unplug_request() correctly
generates an error message if that's attempted.
But.. if the given errp is not error_abort or error_fatal, it doesn't
actually stop trying to unplug the bridge anyway.
Fixes: 14e714900f6b "spapr: Allow hot plug/unplug of PCI bridges and devices
under PCI bridges"
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
(cherry picked from commit 7aab5899764887f6b0512cb2e5c11bdc2a5d3644)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: ecdb0d5651eb9a9604c23e342cfd993a49140309
https://github.com/qemu/qemu/commit/ecdb0d5651eb9a9604c23e342cfd993a49140309
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M block/vpc.c
Log Message:
-----------
vpc: Don't round up already aligned BAT sizes
As reported on Launchpad, Azure apparently doesn't accept images for
upload that are not both aligned to 1 MB blocks and have a BAT size that
matches the image size exactly.
As far as I can tell, there is no real reason why we create a BAT that
is one entry longer than necessary for aligned image sizes, so change
that.
(Even though the condition is only mentioned as "should" in the spec and
previous products accepted larger BATs - but we'll try to maintain
compatibility with as many of Microsoft's ever-changing interpretations
of the VHD spec as possible.)
Fixes: https://bugs.launchpad.net/bugs/1870098
Reported-by: Tobias Witek
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20200402093603.2369-1-kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 3f6de653b946fe849330208becf79d6af7e876cb)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 97701bc03e0e369efb96c06390df4db6caf675bc
https://github.com/qemu/qemu/commit/97701bc03e0e369efb96c06390df4db6caf675bc
Author: Max Filippov <jcmvbkbc@gmail.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M target/xtensa/translate.c
Log Message:
-----------
target/xtensa: fix pasto in pfwait.r opcode name
Core xtensa opcode table has pfwait.o instead of pfwait.r. Fix that.
Fixes: c884400f2988 ("target/xtensa: implement block prefetch option opcodes")
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 1a03362b14affa4d8ddede55df6e21d7a07b87c2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 27f56b9aa2687a346484aa2108bbb2f70bc2d373
https://github.com/qemu/qemu/commit/27f56b9aa2687a346484aa2108bbb2f70bc2d373
Author: lixinyu <precinct@mail.ustc.edu.cn>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M tcg/mips/tcg-target.inc.c
Log Message:
-----------
tcg/mips: mips sync* encode error
OPC_SYNC_WMB, OPC_SYNC_MB, OPC_SYNC_ACQUIRE, OPC_SYNC_RELEASE and
OPC_SYNC_RMB have wrong encode. According to the mips manual,
their encode should be 'OPC_SYNC | 0x?? << 6' rather than
'OPC_SYNC | 0x?? << 5'. Wrong encode can lead illegal instruction
errors. These instructions often appear with multi-threaded
simulation.
Fixes: 6f0b99104a3 ("tcg/mips: Add support for fence")
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: lixinyu <precinct@mail.ustc.edu.cn>
Message-Id: <20200411124612.12560-1-precinct@mail.ustc.edu.cn>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit a4e57084c16d5b0eff3651693fba04f26b30b551)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 0664ffac4be2673c1c962bb9d010dc964d080ee7
https://github.com/qemu/qemu/commit/0664ffac4be2673c1c962bb9d010dc964d080ee7
Author: Helge Deller <deller@gmx.de>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M hw/net/tulip.c
Log Message:
-----------
Fix tulip breakage
The tulip network driver in a qemu-system-hppa emulation is broken in
the sense that bigger network packages aren't received any longer and
thus even running e.g. "apt update" inside the VM fails.
The breakage was introduced by commit 8ffb7265af ("check frame size and
r/w data length") which added checks to prevent accesses outside of the
rx/tx buffers.
But the new checks were implemented wrong. The variable rx_frame_len
counts backwards, from rx_frame_size down to zero, and the variable len
is never bigger than rx_frame_len, so accesses just can't happen and the
checks are unnecessary.
On the contrary the checks now prevented bigger packages to be moved
into the rx buffers.
This patch reverts the wrong checks and were sucessfully tested with a
qemu-system-hppa emulation.
Fixes: 8ffb7265af ("check frame size and r/w data length")
Buglink: https://bugs.launchpad.net/bugs/1874539
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit d9b69640391618045949f7c500b87fc129f862ed)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 4a0db6ba7d5c524cbbcc684d7448e01e11eacbbd
https://github.com/qemu/qemu/commit/4a0db6ba7d5c524cbbcc684d7448e01e11eacbbd
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2020-06-22 (Mon, 22 Jun 2020)
Changed paths:
M tests/qemu-iotests/283
M tests/qemu-iotests/283.out
Log Message:
-----------
iotests/283: Use consistent size for source and target
The test case forgot to specify the null-co size for the target node.
When adding a check to backup that both sizes match, this would fail
because of the size mismatch and not the behaviour that the test really
wanted to test.
Fixes: a541fcc27c98b96da187c7d4573f3270f3ddd283
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-Id: <20200430142755.315494-2-kwolf@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 813cc2545b82409fd504509f0ba2e96fab6edb9e)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: 6cdf8c4efa073eac7d5f9894329e2d07743c2955
https://github.com/qemu/qemu/commit/6cdf8c4efa073eac7d5f9894329e2d07743c2955
Author: Michael Roth <mdroth@linux.vnet.ibm.com>
Date: 2020-06-25 (Thu, 25 Jun 2020)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 4.2.1 release
Compare: https://github.com/qemu/qemu/compare/85df33073ae9%5E...6cdf8c4efa07
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 85df33: block/nbd: extract the common cleanup code,
Michael Roth <=