file-posix: Handle EINTR in preallocation=full write
Cc: qemu-stable@nongnu.org Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit a1c81f4f16a74d0d544f5d3ac405bcaad83541fd)
Conflicts:
block/file-posix.c
* avoid dep on 93f4e2ff by adding check to raw_regular_truncate instead Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
This is because we reference bs twice in qcow_co_create(..) one time in
bdrv_open_blockdev_ref(..) and in blk_insert_bs(..) but we unref it only once
in blk_unref which leads to the reference leak.
Note that I didn't tested much QCOW after this change as I don't use it much.
Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 41b6513436d2ebb64c7df8f009f630922a8e8990) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
We clamp down ram_size to match the sclp increment size. We do
not do the same for maxram_size, which means for large guests
with some sizes (e.g. -m 50000) maxram_size differs from ram_size.
This can break other code (e.g. CMMA migration) which uses maxram_size
to calculate the number of pages and then throws some errors.
Fixes: 82fab5c5b90e468f3e9d54c ("s390x/sclp: remove memory hotplug support") Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> CC: qemu-stable@nongnu.org CC: David Hildenbrand <david@redhat.com>
Message-Id: <1532959766-53343-1-git-send-email-borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 408e5ace517ff18c9c7cd918fc93358162e6e26d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
json_parser_parse_err() may return something else than a QDict, in
which case we loose the object. Let's keep track of the original
object to avoid leaks.
When an error occurs, "qdict" contains the response, but we still
check the "execute" key there. Untangle a bit this code, by having a
clear error path.
CC: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit ae7da1e5f658ea21d96e565514de20ff2cf24fa1)
* drop context dep on d43b16945a
* drop functional dep on cb3e7f08ae Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
All callers of qmp_build_error_object() duplicate the code to wrap it
in a response object. Replace it by qmp_error_response() that
captures the duplicated code, including error_free().
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180703085358.13941-23-armbru@redhat.com>
(cherry picked from commit cee32796cadc9510ee00f029a933009df7a28ae2)
Conflicts:
include/qapi/qmp/dispatch.h
qapi/qmp-dispatch.c
qga/main.c
* drop context dep on cb3e7f08ae
* prereq for ae7da1e5f6 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Many uses of qobject_from_jsonf() convert JSON objects. Create new
convenience function qdict_from_jsonf_nofail() that includes the
conversion to QDict. The next few commits will put it to use.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180703085358.13941-22-armbru@redhat.com>
(cherry picked from commit a193352ff9c7cd2cd07846118bc49921d0f53af8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Since cc847bfd16d894fd8c1a2ce25f31772f6cdbbc74, CCID card-passthru
fails to intialize, because it changed a debug line to an error,
probably by mistake. Change it back to a DPRINTF debug.
(solves Boxes creating VM with smartcard passthru failing to start)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180515153039.27514-1-marcandre.lureau@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit e58d64a16abc2304c4dcb644411eb9580bf63b1e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
When host vector registers and operations were introduced, I failed
to mark the registers call clobbered as required by the ABI.
Fixes: 770c2fc7bb7 Cc: qemu-stable@nongnu.org Reported-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 672189cd586ea38a2c1d8ab91eb1f9dcff5ceb05) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Lieven [Fri, 13 Jul 2018 07:15:39 +0000 (09:15 +0200)]
qemu-img: avoid overflow of min_sparse parameter
the min_sparse convert parameter can overflow (e.g. -S 1024G)
in the conversion from int64_t to int resulting in a negative
min_sparse parameter. Avoid this by limiting the valid parameters
to sane values. In fact anything exceeding the convert buffer size
is also pointless. While at it also forbid values that are non
multiple of 512 to avoid undesired behaviour. For instance, values
between 1 and 511 were legal, but resulted in full allocation.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Lieven <pl@kamp.de> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 6360ab278cc1ac3e1235e0755e4cba1f918e6f3c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Yunjian Wang [Thu, 31 May 2018 07:28:22 +0000 (15:28 +0800)]
tap: fix memory leak on success to create a tap device
The memory leak on success to create a tap device. And the nfds and
nvhosts may not be the same and need to be processed separately.
Fixes: 07825977 ("tap: fix memory leak on failure to create a multiqueue tap device") Fixes: 264986e2 ("tap: multiqueue support") Cc: qemu-stable@nongnu.org Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 323e7c117754e4d4ce6b4282d74ad01c99d67714) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
The use of GDB breakpoints was broken by b0c2d52 ("target/ppc: convert
to TranslatorOps", 2018-02-16).
Fix it by setting is_jmp, so that we break from the translation loop
as originally intended.
Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Signed-off-by: Emilio G. Cota <cota@braap.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 2a8ceefca23bc2aaafe711f8afd7585be3c27064) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Pankaj Gupta [Wed, 27 Jun 2018 11:25:20 +0000 (16:55 +0530)]
virtio-rng: process pending requests on DRIVER_OK
virtio-rng device causes old guest kernels(2.6.32) to hang on latest qemu.
The driver attempts to read from the virtio-rng device too early in it's
initialization. Qemu detects guest is not ready and returns, resulting in
hang.
To fix handle pending requests when guest is running and driver status is
set to 'VIRTIO_CONFIG_S_DRIVER_OK'.
CC: qemu-stable@nongnu.org Reported-by: Sergio lopez <slopezpa@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Pankaj Gupta <pagupta@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 5d9c9ea22ab4f3b3ee497523e34b6f4d3281f62d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eric Blake [Tue, 8 May 2018 21:27:18 +0000 (16:27 -0500)]
iscsi: Avoid potential for get_status overflow
Detected by Coverity: Multiplying two 32-bit int and assigning
the result to a 64-bit number is a risk of overflow. Prior to
the conversion to byte-based interfaces, the block layer took
care of ensuring that a status request never exceeded 2G in
the driver; but after that conversion, the block layer expects
drivers to deal with any size request (the driver can always
truncate the request size back down, as long as it makes
progress). So, in the off-chance that someone makes a large
request, we are at the mercy of whether iscsi_get_lba_status_task()
will cap things to at most INT_MAX / iscsilun->block_size when
it populates lbasd->num_blocks; since I could not easily audit
that, it's better to be safe than sorry by just forcing a 64-bit
multiply.
Fixes: 92809c36 CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180508212718.1482663-1-eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
(cherry picked from commit 8ee1cef4593a7bda076891470c0620e79333c0d0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eric Blake [Thu, 21 Jun 2018 12:49:37 +0000 (07:49 -0500)]
nbd/server: Reject 0-length block status request
The NBD spec says that behavior is unspecified if the client
requests 0 length for block status; but since the structured
reply is documenting as returning a non-zero length, it's
easier to just diagnose this with an EINVAL error than to
figure out what to return.
CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180621124937.166549-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
(cherry picked from commit d8b20291cba6aa9bb295885a34f2b5f05d59d1b2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Also, assert that we don't overflow any of two different offsets into
the TB. Both unwind and goto_tb both record a uint16_t for later use.
This fixes an arm-softmmu test case utilizing NEON in which there is
a TB generated that runs to 7800 opcodes, and compiles to 96k on an
x86_64 host. This overflows the 16-bit offset in which we record the
goto_tb reset offset. Because of that overflow, we install a jump
destination that goes to neverland. Boom.
With this reduced op count, the same TB compiles to about 48k for
aarch64, ppc64le, and x86_64 hosts, and neither assertion fires.
Cc: qemu-stable@nongnu.org Reported-by: "Jason A. Donenfeld" <Jason@zx2c4.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 9f754620651d3432114f4bb89c7f12cbea814b3e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
dirty_bitmap_load_header return code is obtained but not handled. Fix
this.
Bug was introduced in b35ebdf076d697bc
"migration: add postcopy migration of dirty bitmaps" with the whole
function.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20180530112424.204835-1-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
(cherry picked from commit a36f6ff46f115672cf86d0e1e7cdb1c2fa4d304b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Williamson [Tue, 5 Jun 2018 14:23:18 +0000 (08:23 -0600)]
vfio/pci: Default display option to "off"
Commit a9994687cb9b ("vfio/display: core & wireup") added display
support to vfio-pci with the default being "auto", which breaks
existing VMs when the vGPU requires GL support but had no previous
requirement for a GL compatible configuration. "Off" is the safer
default as we impose no new requirements to VM configurations.
Fixes: a9994687cb9b ("vfio/display: core & wireup") Cc: qemu-stable@nongnu.org Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
(cherry picked from commit 8151a9c56d31eeeea872b8103c8b86d03c411667) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Olaf Hering [Tue, 15 May 2018 06:31:28 +0000 (08:31 +0200)]
replace functions which are only available in glib-2.24
Currently the minimal supported version of glib is 2.22.
Since testing is done with a glib that claims to be 2.22, but in fact
has APIs from newer version of glib, this bug was not caught during
submit of the patch referenced below.
Replace g_realloc_n, which is available only since 2.24, with g_renew.
Kevin Wolf [Wed, 16 May 2018 16:08:16 +0000 (18:08 +0200)]
nfs: Remove processed options from QDict
Commit c22a03454 QAPIfied option parsing in the NFS block driver, but
forgot to remove all the options we processed. Therefore, we get an
error in bdrv_open_inherit(), which thinks the remaining options are
invalid. Trying to open an NFS image will result in an error like this:
Block protocol 'nfs' doesn't support the option 'server.host'
Remove all options from the QDict to make the NFS driver work again.
Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 20180516160816.26259-1-kwolf@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Jeff Cody <jcody@redhat.com>
(cherry picked from commit c82be42cc803b36fd7aed5dceec68312c7056fd5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
hw/isa/superio: Fix inconsistent use of Chardev->be
4c3119a6e3e and cd9526ab7c0 introduced an incorrect and inconsistent
use of Chardev->be. Also, this CharBackend member is private and is
not supposed to be accessible.
Fix it by removing the inconsistent check.
Cc: qemu-stable@nongnu.org Reported-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20180515152500.19460-2-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit d4c8fcd91abba584f2788dfe5fba5245cea380f0)
Conflicts:
hw/isa/isa-superio.c
* avoid context dep on 9bca0edb28 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Bennée [Tue, 15 May 2018 13:58:43 +0000 (14:58 +0100)]
target/arm: Fix sqrt_f16 exception raising
We are meant to explicitly pass fpst, not cpu_env.
Cc: qemu-stable@nongnu.org Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180512003217.9105-12-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 905edee9101c54cda5b72286b7f7607cf1c3c4d1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Bennée [Tue, 15 May 2018 13:58:43 +0000 (14:58 +0100)]
target/arm: Implement FMOV (immediate) for fp16
All the hard work is already done by vfp_expand_imm, we just need to
make sure we pick up the correct size.
Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180512003217.9105-11-richard.henderson@linaro.org
[rth: Merge unallocated_encoding check with TCGMemOp conversion.] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 6ba28ddb9be37bdb67e3e38007a53ccbdcd010df) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Bennée [Tue, 15 May 2018 13:58:43 +0000 (14:58 +0100)]
target/arm: Implement FCSEL for fp16
These were missed out from the rest of the half-precision work.
Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180512003217.9105-10-richard.henderson@linaro.org
[rth: Fix erroneous check vs type] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit ace97feef3613194900d4eb9ffc6819b840fbaeb) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alex Bennée [Tue, 15 May 2018 13:58:43 +0000 (14:58 +0100)]
target/arm: Implement FCMP for fp16
These where missed out from the rest of the half-precision work.
Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180512003217.9105-9-richard.henderson@linaro.org
[rth: Diagnose lack of FP16 before fp_access_check] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 7a1929256ea1a03df12625e75ed571c60dca5bfb) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Implement FP data-processing (3 source) for fp16
We missed all of the scalar fp16 fma operations.
Cc: qemu-stable@nongnu.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180512003217.9105-8-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 95f9864fde6078e2d2c036a07cc4fe44f199be96) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Implement FP data-processing (2 source) for fp16
We missed all of the scalar fp16 binary operations.
Cc: qemu-stable@nongnu.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180512003217.9105-7-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit b8f5171cf01420a9f0ee895c5591e9b9914f391a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180512003217.9105-6-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 3d99d931266eaeaf7e83703a53f32232cd6faad7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Implement FCVT (scalar, fixed-point) for fp16
Cc: qemu-stable@nongnu.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180512003217.9105-5-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 2752728016bef06e7c9cfb961019272859beeca4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Implement FCVT (scalar, integer) for fp16
Cc: qemu-stable@nongnu.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180512003217.9105-4-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 564a0632504fad840491aa9a59453f4e64a316c4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-stable@nongnu.org Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180512003217.9105-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 68130236e30a1ec64363f4915349feee181bfbc1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Petr Tesarik [Fri, 11 May 2018 07:10:52 +0000 (09:10 +0200)]
fpu/softfloat: Fix conversion from uint64 to float128
The significand is passed to normalizeRoundAndPackFloat128() as high
first, low second. The current code passes the integer first, so the
result is incorrectly shifted left by 64 bits.
This bug affects the emulation of s390x instruction CXLGBR (convert
from logical 64-bit binary-integer operand to extended BFP result).
Cc: qemu-stable@nongnu.org Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Message-Id: <20180511071052.1443-1-ptesarik@suse.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 6603d50648901e8b9e6d66ec1142accf0b1df1e6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Use write_fp_dreg and clear_vec_high to zero the bits
that need zeroing for these cases.
Cc: qemu-stable@nongnu.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180502221552.3873-5-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 9a9f1f59521f46e8ff4527d9a2b52f83577e2aa3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
The instruction "ucvtf v0.4h, v04h, #2", with input 0x8000u,
overflows the intermediate float16 to infinity before we have a
chance to scale the output. Use float64 as the intermediate type
so that no input argument (uint32_t in this case) can overflow
or round before scaling. Given the declared argument, the signed
int32_t function has the same problem.
When converting from float16 to integer, using u/int32_t instead
of u/int16_t means that the bounding is incorrect.
Cc: qemu-stable@nongnu.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180502221552.3873-4-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 88808a022c06f98d81cd3f2d105a5734c5614839) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Implement vector shifted FCVT for fp16
While we have some of the scalar paths for FCVT for fp16,
we failed to decode the fp16 version of these instructions.
Cc: qemu-stable@nongnu.org Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180502221552.3873-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 d0ba8e74acd299b092786ffc30b306638d395a9e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target/arm: Implement vector shifted SCVF/UCVF for fp16
While we have some of the scalar paths for *CVF for fp16,
we failed to decode the fp16 version of these instructions.
Cc: qemu-stable@nongnu.org Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180502221552.3873-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 a6117fae4576edfe7a5a5b802a742c33112c0993) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Tue, 15 May 2018 13:58:42 +0000 (14:58 +0100)]
fpu/softfloat: Don't set Invalid for float-to-int(MAXINT)
In float-to-integer conversion, if the floating point input
converts exactly to the largest or smallest integer that
fits in to the result type, this is not an overflow.
In this situation we were producing the correct result value,
but were incorrectly setting the Invalid flag.
For example for Arm A64, "FCVTAS w0, d0" on an input of
0x41dfffffffc00000 should produce 0x7fffffff and set no flags.
Fix the boundary case to take the right half of the if()
statements.
This fixes a regression from 2.11 introduced by the softfloat
refactoring.
Cc: qemu-stable@nongnu.org Fixes: ab52f973a50 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20180510140141.12120-1-peter.maydell@linaro.org
(cherry picked from commit 333583757c5e910b040bef793974773635ce1918) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Tue, 15 May 2018 13:58:42 +0000 (14:58 +0100)]
target/arm: Fix fp_status_f16 tininess before rounding
In commit d81ce0ef2c4f105 we added an extra float_status field
fp_status_fp16 for Arm, but forgot to initialize it correctly
by setting it to float_tininess_before_rounding. This currently
will only cause problems for the new V8_FP16 feature, since the
float-to-float conversion code doesn't use it yet. The effect
would be that we failed to set the Underflow IEEE exception flag
in all the cases where we should.
Add the missing initialization.
Fixes: d81ce0ef2c4f105 Cc: qemu-stable@nongnu.org Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20180512004311.9299-16-richard.henderson@linaro.org
(cherry picked from commit bcc531f0364796104df4443d17f99b5fb494eca2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
John Snow [Tue, 8 May 2018 23:36:59 +0000 (19:36 -0400)]
blockjob: expose error string via query
When we've reached the concluded state, we need to expose the error
state if applicable. Add the new field.
This should be sufficient for determining if a job completed
successfully or not after concluding; if we want to discriminate
based on how it failed more mechanically, we can always add an
explicit return code enumeration later.
I didn't bother to make it only show up if we are in the concluded
state; I don't think it's necessary.
Cc: qemu-stable@nongnu.org Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit ab9ba614556ac5b0f8d96b99e0dba19f1e28d6c2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Michael Clark [Wed, 9 May 2018 09:06:40 +0000 (21:06 +1200)]
RISC-V: Minimal QEMU 2.12 fix for sifive_u machine
The 'sifive_u' board has a bug where the ROM is
created as RAM at the wrong address and marked
readonly. The bug renders the board unusable.
This is a minimal fix and allows booting Linux.
5aec3247c190f10654250203a1742490ae7343a2
"RISC-V: Mark ROM read-only after copying in code"
contains a comprehensive fix using the ROM APIs
memory_region_init_rom and rom_add_blob_fixed_as
which could be backported.
Cc: Sagar Karandikar <sagark@eecs.berkeley.edu> Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Alistair Francis <Alistair.Francis@wdc.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Clark <mjc@sifive.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
In 6001f7729e12 we partially attempt to address the branch
displacement overflow caused by 15fa08f845.
However, gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vqtbX.c
is a testcase that contains a TB so large as to overflow anyway.
The limit here of 8000 ops produces a maximum output TB size of
24112 bytes on a ppc64le host with that test case. This is still
much less than the maximum forward branch distance of 32764 bytes.
Cc: qemu-stable@nongnu.org Fixes: 15fa08f845 ("tcg: Dynamically allocate TCGOps") Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit abebf92597186be2bc48d487235da28b1127860f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Thu, 10 May 2018 17:10:56 +0000 (18:10 +0100)]
softfloat: Handle default NaN mode after pickNaNMulAdd, not before
It is implementation defined whether a multiply-add of
(0,inf,qnan) or (inf,0,qnan) raises InvalidaOperation or
not, so we let the target-specific pickNaNMulAdd function
handle this. This means that we must do the "return the
default NaN in default NaN mode" check after the call,
not before. Correct the ordering, and restore the comment
from the old propagateFloat64MulAddNaN() that warned about
this corner case.
This fixes a regression from 2.11 for Arm guests where we would
incorrectly fail to set the Invalid flag for these cases.
Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20180504100547.14621-1-peter.maydell@linaro.org
(cherry picked from commit 1839189bbf89889076aadf0c793c1b57977b28d7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Maydell [Fri, 4 May 2018 15:34:31 +0000 (16:34 +0100)]
tcg/i386: Fix dup_vec in non-AVX2 codepath
The VPUNPCKLD* instructions are all "non-destructive source",
indicated by "NDS" in the encoding string in the x86 ISA manual.
This means that they take two source operands, one of which is
encoded in the VEX.vvvv field. We were incorrectly treating them
as if they were destructive-source and passing 0 as the 'v'
argument of tcg_out_vex_modrm(). This meant we were always
using %xmm0 as one of the source operands, causing incorrect
results if the register allocator happened to want to use
something else. For instance the input AArch64 insn:
DUP v26.16b, w21
which becomes TCG IR ops:
dup_vec v128,e8,tmp2,x21
st_vec v128,e8,tmp2,env,$0xa40
was assembled to:
0x607c568c: c4 c1 7a 7e 86 e8 00 00 vmovq 0xe8(%r14), %xmm0
0x607c5694: 00
0x607c5695: c5 f9 60 c8 vpunpcklbw %xmm0, %xmm0, %xmm1
0x607c5699: c5 f9 61 c9 vpunpcklwd %xmm1, %xmm0, %xmm1
0x607c569d: c5 f9 70 c9 00 vpshufd $0, %xmm1, %xmm1
0x607c56a2: c4 c1 7a 7f 8e 40 0a 00 vmovdqu %xmm1, 0xa40(%r14)
0x607c56aa: 00
when the vpunpcklwd insn should be "%xmm1, %xmm1, %xmm1".
This resulted in our incorrectly setting the output vector to
q26=0000320000003200:0000320000003200
when given an input of x21 == 0000000002803200
rather than the expected all-zeroes.
Pass the correct source register number to tcg_out_vex_modrm()
for these insns.
Fixes: 770c2fc7bb70804a Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-Id: <20180504153431.5169-1-peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 7eb30ef0ba2eb59e7430d4848ae8d4bf4e50f768) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eric Blake [Thu, 3 May 2018 22:26:26 +0000 (17:26 -0500)]
nbd/client: Relax handling of large NBD_CMD_BLOCK_STATUS reply
The NBD spec is proposing a relaxation of NBD_CMD_BLOCK_STATUS
where a server may have the final extent per context give a
length beyond the original request, if it can easily prove that
subsequent bytes have the same status, on the grounds that a
client can take advantage of this information for fewer block
status requests. Since qemu 2.12 as a client always sends
NBD_CMD_FLAG_REQ_ONE, and rejects a server that sends extra
length, the upstream NBD spec will probably limit this behavior
to clients that don't request REQ_ONE semantics; but it doesn't
hurt to relax qemu to always be permissive of this server
behavior, even if it continues to use REQ_ONE.
CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20180503222626.1303410-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
(cherry picked from commit acfd8f7a5f92e703d2d046cbe3d510008a697194) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
KONRAD Frederic [Thu, 3 May 2018 15:17:16 +0000 (17:17 +0200)]
riscv: requires libfdt
When compiling on a machine without libfdt installed the configure script
should try to get libfdt from the git or should die because otherwise
CONFIG_LIBFDT is not set and the build process end in an error in the link
phase.. eg:
hw/riscv/virt.o: In function `riscv_virt_board_init':
qemu/src/hw/riscv/virt.c:317: undefined reference to `qemu_fdt_setprop_cell'
qemu/src/hw/riscv/virt.c:319: undefined reference to `qemu_fdt_setprop_cell'
qemu/src/hw/riscv/virt.c:345: undefined reference to `qemu_fdt_dumpdtb'
collect2: error: ld returned 1 exit status
make[1]: *** [qemu-system-riscv64] Error 1
make: *** [subdir-riscv64-softmmu] Error 2
Cc: qemu-stable@nongnu.org Reviewed-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Michael Clark <mjc@sifive.com>
Message-Id: <1525360636-18229-4-git-send-email-frederic.konrad@adacore.com>
(cherry picked from commit a666409f0df5dce113a5bd2c4c144a0792f2a4a3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Michael Clark <mjc@sifive.com>
Message-Id: <1525360636-18229-3-git-send-email-frederic.konrad@adacore.com>
(cherry picked from commit 6fad7d1893f6ea926063067af957009bc320406f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
KONRAD Frederic [Thu, 3 May 2018 15:17:14 +0000 (17:17 +0200)]
riscv: spike: allow base == 0
The sanity check on base doesn't allow htif to be mapped @0. Check if the
symbol exists instead so we can map it where we want.
Reviewed-by: Michael Clark <mjc@sifive.com> Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Michael Clark <mjc@sifive.com>
Message-Id: <1525360636-18229-2-git-send-email-frederic.konrad@adacore.com>
(cherry picked from commit 17b9751e85b9989cc841ed387794d7f1e8aa5e46) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Tue, 1 May 2018 22:05:09 +0000 (00:05 +0200)]
iotests: Add test for cancelling a mirror job
We already have an extensive mirror test (041) which does cover
cancelling a mirror job, especially after it has emitted the READY
event. However, it does not check what exact events are emitted after
block-job-cancel is executed. More importantly, it does not use
throttling to ensure that it covers the case of block-job-cancel before
READY.
It would be possible to add this case to 041, but considering it is
already our largest test file, it makes sense to create a new file for
these cases.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180501220509.14152-3-mreitz@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
(cherry picked from commit dc885fff972c447f51572afc4c921a26b880731b)
Conflicts:
tests/qemu-iotests/group
* fix minor conflicts with test groups Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Tue, 1 May 2018 22:05:08 +0000 (00:05 +0200)]
block/mirror: Make cancel always cancel pre-READY
Commit b76e4458b1eb3c32e9824fe6aa51f67d2b251748 made the mirror block
job respect block-job-cancel's @force flag: With that flag set, it would
now always really cancel, even post-READY.
Unfortunately, it had a side effect: Without that flag set, it would now
never cancel, not even before READY. Considering that is an
incompatible change and not noted anywhere in the commit or the
description of block-job-cancel's @force parameter, this seems
unintentional and we should revert to the previous behavior, which is to
immediately cancel the job when block-job-cancel is called before source
and target are in sync (i.e. before the READY event).
Cc: qemu-stable@nongnu.org Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1572856 Reported-by: Yanan Fu <yfu@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180501220509.14152-2-mreitz@redhat.com Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Jeff Cody <jcody@redhat.com>
(cherry picked from commit eb36639f7bbc16055e551593b81365e8ae3b0b05) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
* Commit ca230ff33f89 added the @arch field to @CpuInfoFast, but it failed
to set the new field in qmp_query_cpus_fast(), when TARGET_S390X was not
defined. The updated @query-cpus-fast example in "qapi-schema.json"
showed "arch":"x86" only because qmp_query_cpus_fast() calls g_malloc0()
to allocate @CpuInfoFast, and the CPU_INFO_ARCH_X86 enum constant is
generated with value 0.
All @arch values other than @s390 implied the @CpuInfoOther sub-struct
for @CpuInfoFast -- at the time of writing the patch --, thus no fields
other than @arch needed to be set when TARGET_S390X was not defined. Set
@arch now, by copying the corresponding assignments from
qmp_query_cpus().
* Commit 25fa194b7b11 added the @riscv enum constant to @CpuInfoArch (used
in both @CpuInfo and @CpuInfoFast -- the return types of the @query-cpus
and @query-cpus-fast commands, respectively), and assigned, in both
return structures, the @CpuInfoRISCV sub-structure to the new enum
value.
However, qmp_query_cpus_fast() would not populate either the @arch field
or the @CpuInfoRISCV sub-structure, when TARGET_RISCV was defined; only
qmp_query_cpus() would.
Assign @CpuInfoOther to the @riscv enum constant in @CpuInfoFast, and
populate only the @arch field in qmp_query_cpus_fast(). Getting CPU
state without interrupting KVM is an exceptional thing that only S390X
does currently. Quoting Cornelia Huck <cohuck@redhat.com>, "s390x is
exceptional in that it has state in QEMU that is actually interesting
for upper layers and can be retrieved without performance penalty". See
also
<https://www.redhat.com/archives/libvir-list/2018-February/msg00121.html>.
Cc: Cornelia Huck <cohuck@redhat.com> Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Viktor VM Mihajlovski <mihajlov@linux.vnet.ibm.com> Cc: qemu-stable@nongnu.org Fixes: ca230ff33f89bf7102cbfbc2328716da6750aaed Fixes: 25fa194b7b11901561532e435beb83d046899f7a Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20180427192852.15013-2-lersek@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
(cherry picked from commit 96054f56396eaa0b9b5c681fc3e42a0004b17ade) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
migration/block-dirty-bitmap: fix memory leak in dirty_bitmap_load_bits
Release buf on error path too.
Bug was introduced in b35ebdf076d697bc "migration: add postcopy
migration of dirty bitmaps" with the whole function.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20180427142002.21930-3-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 16a2227893dc1d5cad78ed376ad1d7e300978fbe) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Initialize received variable. Otherwise, is is possible for server to
answer without any contexts, but we will set context_id to something
random (received_id is not initialized too) and return 1, which is
wrong.
To solve it, just initialize received to false. Initialize received_id
too, just to make all possible checkers happy.
Bug was introduced in 78a33ab58782efdb206de14 "nbd: BLOCK_STATUS for
standard get_block_status function: client part" with the whole
function.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20180427142002.21930-2-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 89aa0d87634e2cb98517509dc8bdb876f26ecf8b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit 9b0605f9837b ("cpus: tcg: unregister thread with RCU, fix
exiting of loop on unplug") changed the exit condition of the loop in
the vCPU thread function but forgot to remove the beginning 'while (1)'
statement. The resulting code :
while (1) {
...
} while (!cpu->unplug || cpu_can_run(cpu));
is a sequence of two distinct two while() loops, the first not exiting
in case of an unplug event.
Stefan Hajnoczi [Tue, 24 Apr 2018 12:35:27 +0000 (13:35 +0100)]
block/mirror: honor ratelimit again
Commit b76e4458b1eb3c32e9824fe6aa51f67d2b251748 ("block/mirror: change
the semantic of 'force' of block-job-cancel") accidentally removed the
ratelimit in the mirror job.
Note that block_job_sleep_ns() returns immediately when the job is
cancelled. Therefore it's safe to unconditionally call
block_job_sleep_ns() - a cancelled job does not sleep.
This commit fixes the non-deterministic qemu-iotests 185 output. The
test relies on the ratelimit to make the job sleep until the 'quit'
command is processed. Previously the job could complete before the
'quit' command was received since there was no ratelimit.
Cc: Liang Li <liliang.opensource@gmail.com> Cc: Jeff Cody <jcody@redhat.com> Cc: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 20180424123527.19168-1-stefanha@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
(cherry picked from commit ddc4115efdfa6619689fe18871aa2d37890b3463) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
hw/usb/dev-mtp.c:971:5: warning: 4th function call argument is an uninitialized value
trace_usb_mtp_op_get_partial_object(s->dev.addr, o->handle, o->path,
c->argv[1], c->argv[2]);
^~~~~~~~~~
and:
hw/usb/dev-mtp.c:981:12: warning: Assigned value is garbage or undefined
offset = c->argv[1];
^ ~~~~~~~~~~
Reported-by: Clang Static Analyzer Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180604151421.23385-3-f4bug@amsat.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 62713a2e50f653162387451034f1a2490e87be88) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
USB Specification Revision 2.0, §5.5.3:
The Data stage of a control transfer from an endpoint to the host is complete when the endpoint does one of the following:
• Has transferred exactly the amount of data specified during the Setup stage
• Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet"
hw/usb/redirect.c:802:9: warning: Declared variable-length array (VLA) has zero size
uint8_t buf[size];
^~~~~~~~~~~ ~~~~
Reported-by: Clang Static Analyzer Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Message-id: 20180604151421.23385-2-f4bug@amsat.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit bf78fb1c1b61a819a47f7a1dbecf9934b9f32a0d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Shannon Zhao [Fri, 15 Jun 2018 13:57:13 +0000 (14:57 +0100)]
arm_gicv3_kvm: kvm_dist_get/put_priority: skip the registers banked by GICR_IPRIORITYR
While for_each_dist_irq_reg loop starts from GIC_INTERNAL, it forgot to
offset the date array and index. This will overlap the GICR registers
value and leave the last GIC_INTERNAL irq's registers out of update.
Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920 Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 1dcf3675196a1cec616ce71b067d9498590a60a6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eric Blake [Mon, 11 Jun 2018 21:39:27 +0000 (16:39 -0500)]
iotests: Add test 221 to catch qemu-img map regression
Although qemu-img creates aligned files (by rounding up), it
must also gracefully handle files that are not sector-aligned.
Test that the bug fixed in the previous patch does not recur.
It's a bit annoying that we can see the (implicit) hole past
the end of the file on to the next sector boundary, so if we
ever reach the point where we report a byte-accurate size rather
than our current behavior of always rounding up, this test will
probably need a slight modification.
Signed-off-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit c6a9d2f6f9bc0c163b3a3073126464a2446bad5f)
Conflicts:
tests/qemu-iotests/group
* drop context dep on tests not present in 2.12 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Eric Blake [Mon, 11 Jun 2018 21:39:26 +0000 (16:39 -0500)]
qemu-img: Fix assert when mapping unaligned raw file
Commit a290f085 exposed a latent bug in qemu-img map introduced
during the conversion of block status to be byte-based. Earlier in
commit 5e344dd8, the internal interface get_block_status() switched
to take byte-based parameters, but still called a sector-based
block layer function; as such, rounding was added in the lone
caller to obey the contract. However, commit 237d78f8 changed
get_block_status() to truly be byte-based, at which point rounding
to sector boundaries can result in calling bdrv_block_status() with
'bytes == 0' (a coding error) when the boundary between data and a
hole falls mid-sector (true for the past-EOF implicit hole present
in POSIX files). Fix things by removing the rounding that is now
no longer necessary.
linzhecheng [Tue, 12 Jun 2018 02:24:45 +0000 (10:24 +0800)]
vhost-user: delete net client if necessary
As qemu_new_net_client create new ncs but error happens later,
ncs will be left in global net_clients list and we can't use them any
more, so we need to cleanup them.
Cc: qemu-stable@nongnu.org Signed-off-by: linzhecheng <linzhecheng@huawei.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit c67daf4a24442d1bb404a11a6a54dc45ea10f234)
Conflicts:
net/vhost-user.c
* drop functional dep on 4d0cf552 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Commit: c471ad0e9bd46 (vhost_net: device IOTLB support) took care of
setting vhostfd to non-blocking when QEMU opens /dev/host-net but if
the fd is passed from qemu cli then we need to ensure that fd is set
to non-blocking.
Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support") Cc: qemu-stable@nongnu.org Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit d542800d1edc62f63f8a29cfa6bdd1a9536ae11c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
i386: define the AMD 'virt-ssbd' CPUID feature bit (CVE-2018-3639)
AMD Zen expose the Intel equivalant to Speculative Store Bypass Disable
via the 0x80000008_EBX[25] CPUID feature bit.
This needs to be exposed to guest OS to allow them to protect
against CVE-2018-3639.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180521215424.13520-3-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit 403503b162ffc33fb64cfefdf7b880acf41772cd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
i386: Define the Virt SSBD MSR and handling of it (CVE-2018-3639)
"Some AMD processors only support a non-architectural means of enabling
speculative store bypass disable (SSBD). To allow a simplified view of
this to a guest, an architectural definition has been created through a new
CPUID bit, 0x80000008_EBX[25], and a new MSR, 0xc001011f. With this, a
hypervisor can virtualize the existence of this definition and provide an
architectural method for using SSBD to a guest.
Add the new CPUID feature, the new MSR and update the existing SSBD
support to use this MSR when present." (from x86/speculation: Add virtualized
speculative store bypass disable support in Linux).
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180521215424.13520-4-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit cfeea0c021db6234c154dbc723730e81553924ff) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
i386: define the 'ssbd' CPUID feature bit (CVE-2018-3639)
New microcode introduces the "Speculative Store Bypass Disable"
CPUID feature bit. This needs to be exposed to guest OS to allow
them to protect against CVE-2018-3639.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-Id: <20180521215424.13520-2-berrange@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
(cherry picked from commit d19d1f965904a533998739698020ff4ee8a103da) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Alberto Garcia [Fri, 8 Jun 2018 15:15:36 +0000 (18:15 +0300)]
throttle: Fix crash on reopen
The throttle block filter can be reopened, and with this it is
possible to change the throttle group that the filter belongs to.
The way the code does that is the following:
- On throttle_reopen_prepare(): create a new ThrottleGroupMember
and attach it to the new throttle group.
- On throttle_reopen_commit(): detach the old ThrottleGroupMember,
delete it and replace it with the new one.
The problem with this is that by replacing the ThrottleGroupMember the
previous value of io_limits_disabled is lost, causing an assertion
failure in throttle_co_drain_end().
This problem can be reproduced by reopening a throttle node:
Since we only want to change the throttle group on reopen there's no
need to create a ThrottleGroupMember and discard the old one. It's
easier if we simply detach it from its current group and attach it to
the new one.
Signed-off-by: Alberto Garcia <berto@igalia.com>
Message-id: 20180608151536.7378-1-berto@igalia.com Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit bc33c047d1ec0b35c9cd8be62bcefae2da28654f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Wed, 6 Jun 2018 19:37:02 +0000 (21:37 +0200)]
iotests: Add case for a corrupted inactive image
Reviewed-by: John Snow <jsnow@redhat.com> Tested-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit c50abd175a88cd41c2c08339de91f6f6e4a7b162) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Wed, 6 Jun 2018 19:37:01 +0000 (21:37 +0200)]
qcow2: Do not mark inactive images corrupt
When signaling a corruption on a read-only image, qcow2 already makes
fatal events non-fatal (i.e., they will not result in the image being
closed, and the image header's corrupt flag will not be set). This is
necessary because we cannot set the corrupt flag on read-only images,
and it is possible because further corruption of read-only images is
impossible.
Inactive images are effectively read-only, too, so we should do the same
for them. bdrv_is_writable() can tell us whether an image can actually
be written to, so use its result instead of !bs->read_only.
(Otherwise, the assert(!(bs->open_flags & BDRV_O_INACTIVE)) in
bdrv_co_pwritev() will fail, crashing qemu.)
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-3-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit ddf3b47ef4b5ed0bf6558d4c2c8ae130b8d8a580) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Wed, 6 Jun 2018 19:37:00 +0000 (21:37 +0200)]
block: Make bdrv_is_writable() public
This is a useful function for the whole block layer, so make it public.
At the same time, users outside of block.c probably do not need to make
use of the reopen functionality, so rename the current function to
bdrv_is_writable_after_reopen() create a new bdrv_is_writable() function
that just passes NULL to it for the reopen queue.
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180606193702.7113-2-mreitz@redhat.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit cc022140972f8b6ac3973c12ccf9dd6b1d2fd200) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Shannon Zhao [Fri, 8 Jun 2018 12:15:32 +0000 (13:15 +0100)]
arm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR
While we skip the GIC_INTERNAL irqs, we don't change the register offset
accordingly. This will overlap the GICR registers value and leave the
last GIC_INTERNAL irq's registers out of update.
Fix this by skipping the registers banked by GICR.
Also for migration compatibility if the migration source (old version
qemu) doesn't send gicd_no_migration_shift_bug = 1 to destination, then
we shift the data of PPI to get the right data for SPI.
Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920 Cc: qemu-stable@nongnu.org Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com>
Message-id: 1527816987-16108-1-git-send-email-zhaoshenglong@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 910e204841954b95c051b2ee49ab0f5c735ff93c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
John Snow [Fri, 8 Jun 2018 17:17:36 +0000 (13:17 -0400)]
ahci: fix PxCI register race
Fixes: https://bugs.launchpad.net/qemu/+bug/1769189
AHCI presently signals completion prior to the PxCI register being
cleared to indicate completion. If a guest driver attempts to issue
a new command in its IRQ handler, it might be surprised to learn there
is still a command pending.
In the case of Windows 10's boot driver, it will actually poll the IRQ
register hoping to find out when the command is done running -- which
will never happen, as there isn't a command running.
Fix this: clear PxCI in ahci_cmd_done and not in the asynchronous BH.
Because it now runs synchronously, we don't need to check if the command
is actually done by spying on the ATA registers. We know it's done.
CC: qemu-stable <qemu-stable@nongnu.org> Reported-by: François Guerraz <kubrick@fgv6.net> Tested-by: Bruce Rogers <brogers@suse.com> Signed-off-by: John Snow <jsnow@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com>
Message-id: 20180531004323.4611-3-jsnow@redhat.com Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 5694c7eacce6b263ad7497cc1bb76aad746cfd4e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
CC hw/usb/host-libusb.o
/builds/xen/src/qemu-xen/hw/usb/host-libusb.c: In function 'usb_host_init':
/builds/xen/src/qemu-xen/hw/usb/host-libusb.c:250:5: error: 'libusb_set_debug' is deprecated: Use libusb_set_option instead [-Werror=deprecated-declarations]
libusb_set_debug(ctx, loglevel);
^~~~~~~~~~~~~~~~
In file included from /builds/xen/src/qemu-xen/hw/usb/host-libusb.c:40:0:
/usr/include/libusb-1.0/libusb.h:1300:18: note: declared here
void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/builds/xen/src/qemu-xen/rules.mak:66: hw/usb/host-libusb.o] Error 1
make: Leaving directory '/builds/xen/src/xen/tools/qemu-xen-build'
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
Message-id: 20180405132046.4968-1-git@johnthomson.fastmail.com.au Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 9d8fa0df49af16a208fa961c2968fba4daffcc07) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:17 +0000 (15:25 +0800)]
intel-iommu: rework the page walk logic
This patch fixes a potential small window that the DMA page table might
be incomplete or invalid when the guest sends domain/context
invalidations to a device. This can cause random DMA errors for
assigned devices.
This is a major change to the VT-d shadow page walking logic. It
includes but is not limited to:
- For each VTDAddressSpace, now we maintain what IOVA ranges we have
mapped and what we have not. With that information, now we only send
MAP or UNMAP when necessary. Say, we don't send MAP notifies if we
know we have already mapped the range, meanwhile we don't send UNMAP
notifies if we know we never mapped the range at all.
- Introduce vtd_sync_shadow_page_table[_range] APIs so that we can call
in any places to resync the shadow page table for a device.
- When we receive domain/context invalidation, we should not really run
the replay logic, instead we use the new sync shadow page table API to
resync the whole shadow page table without unmapping the whole
region. After this change, we'll only do the page walk once for each
domain invalidations (before this, it can be multiple, depending on
number of notifiers per address space).
While at it, the page walking logic is also refactored to be simpler.
CC: QEMU Stable <qemu-stable@nongnu.org> Reported-by: Jintack Lim <jintack@cs.columbia.edu> Tested-by: Jintack Lim <jintack@cs.columbia.edu> Signed-off-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 63b88968f139b6a77f2f81e6f1eedf70c0170a85) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:16 +0000 (15:25 +0800)]
util: implement simple iova tree
Introduce a simplest iova tree implementation based on GTree.
CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 eecf5eedbdc0fc04f39abcf3afeedfbf21b25ca4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:15 +0000 (15:25 +0800)]
intel-iommu: trace domain id during page walk
This patch only modifies the trace points.
Previously we were tracing page walk levels. They are redundant since
we have page mask (size) already. Now we trace something much more
useful which is the domain ID of the page walking. That can be very
useful when we trace more than one devices on the same system, so that
we can know which map is for which domain.
CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 d118c06ebbee2d23ddf873cae4a809311aa61310) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:14 +0000 (15:25 +0800)]
intel-iommu: pass in address space when page walk
We pass in the VTDAddressSpace too. It'll be used in the follow up
patches.
CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 2f764fa87d2a81812b313dd6d998e10126292653) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:13 +0000 (15:25 +0800)]
intel-iommu: introduce vtd_page_walk_info
During the recursive page walking of IOVA page tables, some stack
variables are constant variables and never changed during the whole page
walking procedure. Isolate them into a struct so that we don't need to
pass those contants down the stack every time and multiple times.
CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 fe215b0cbb8c1f4b4af0a64aa5c02042080dd537) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:12 +0000 (15:25 +0800)]
intel-iommu: only do page walk for MAP notifiers
For UNMAP-only IOMMU notifiers, we don't need to walk the page tables.
Fasten that procedure by skipping the page table walk. That should
boost performance for UNMAP-only notifiers like vhost.
CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 4f8a62a933a79094e44bc1b16b63bb23e62d67b4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:11 +0000 (15:25 +0800)]
intel-iommu: add iommu lock
SECURITY IMPLICATION: this patch fixes a potential race when multiple
threads access the IOMMU IOTLB cache.
Add a per-iommu big lock to protect IOMMU status. Currently the only
thing to be protected is the IOTLB/context cache, since that can be
accessed even without BQL, e.g., in IO dataplane.
Note that we don't need to protect device page tables since that's fully
controlled by the guest kernel. However there is still possibility that
malicious drivers will program the device to not obey the rule. In that
case QEMU can't really do anything useful, instead the guest itself will
be responsible for all uncertainties.
CC: QEMU Stable <qemu-stable@nongnu.org> Reported-by: Fam Zheng <famz@redhat.com> Signed-off-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 1d9efa73e12ddf361ea997c2d532cc4afa6674d1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:10 +0000 (15:25 +0800)]
intel-iommu: remove IntelIOMMUNotifierNode
That is not really necessary. Removing that node struct and put the
list entry directly into VTDAddressSpace. It simplfies the code a lot.
Since at it, rename the old notifiers_list into vtd_as_with_notifiers.
CC: QEMU Stable <qemu-stable@nongnu.org> Signed-off-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 b4a4ba0d68f50f218ee3957b6638dbee32a5eeef) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Peter Xu [Fri, 18 May 2018 07:25:09 +0000 (15:25 +0800)]
intel-iommu: send PSI always even if across PDEs
SECURITY IMPLICATION: without this patch, any guest with both assigned
device and a vIOMMU might encounter stale IO page mappings even if guest
has already unmapped the page, which may lead to guest memory
corruption. The stale mappings will only be limited to the guest's own
memory range, so it should not affect the host memory or other guests on
the host.
During IOVA page table walking, there is a special case when the PSI
covers one whole PDE (Page Directory Entry, which contains 512 Page
Table Entries) or more. In the past, we skip that entry and we don't
notify the IOMMU notifiers. This is not correct. We should send UNMAP
notification to registered UNMAP notifiers in this case.
For UNMAP only notifiers, this might cause IOTLBs cached in the devices
even if they were already invalid. For MAP/UNMAP notifiers like
vfio-pci, this will cause stale page mappings.
This special case doesn't trigger often, but it is very easy to be
triggered by nested device assignments, since in that case we'll
possibly map the whole L2 guest RAM region into the device's IOVA
address space (several GBs at least), which is far bigger than normal
kernel driver usages of the device (tens of MBs normally).
Without this patch applied to L1 QEMU, nested device assignment to L2
guests will dump some errors like:
CC: QEMU Stable <qemu-stable@nongnu.org> Acked-by: Jason Wang <jasowang@redhat.com>
[peterx: rewrite the commit message] Signed-off-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 36d2d52bdb45f5b753a61fdaf0fe7891f1f5b61d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
There was a nasty flip in identifying which register group an access is
targeting. The issue caused spuriously raised priorities of the guest
when handing CPUs over in the Jailhouse hypervisor.
Cc: qemu-stable@nongnu.org Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Message-id: 28b927d3-da58-bce4-cc13-bfec7f9b1cb9@siemens.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 887aae10f6150dfdc71c45d7588e8efe6c144019) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Michal Privoznik [Thu, 17 May 2018 15:00:11 +0000 (17:00 +0200)]
console: Avoid segfault in screendump
After f771c5440e04626f1 it is possible to select device and
head which to take screendump from. And even though we check if
provided head number falls within range, it may still happen that
the console has no surface yet leading to SIGSEGV:
Cornelia Huck [Mon, 7 May 2018 13:27:57 +0000 (15:27 +0200)]
s390x/ccw: make sure all ccw devices are properly reset
Thomas reported that the subchannel for a 3270 device that ended up
in a broken state (status pending even though not enabled) did not
get out of that state even after a reboot (which involves a subsytem
reset). The reason for this is that the 3270 device did not define
a reset handler.
Let's fix this by introducing a base reset handler (set up for all
ccw devices) that resets the subchannel and have virtio-ccw call
its virtio-specific reset procedure in addition to that.
CC: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 838fb84f83c84f00d15b1bede5e080b495644458) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Thomas Huth [Tue, 8 May 2018 10:17:52 +0000 (12:17 +0200)]
pc-bios/s390-ccw: struct tpi_info must be declared as aligned(4)
I've run into a compilation error today with the current version of GCC 8:
In file included from s390-ccw.h:49,
from main.c:12:
cio.h:128:1: error: alignment 1 of 'struct tpi_info' is less than 4 [-Werror=packed-not-aligned]
} __attribute__ ((packed));
^
cc1: all warnings being treated as errors
Since the struct tpi_info contains an element ("struct subchannel_id schid")
which is marked as aligned(4), we've got to mark the struct tpi_info as
aligned(4), too.
CC: qemu-stable@nongnu.org Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1525774672-11913-1-git-send-email-thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit a6e4385dea94850d7b06b0542e7960c1063fdabd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Cornelia Huck [Fri, 4 May 2018 12:53:16 +0000 (14:53 +0200)]
s390x/css: disabled subchannels cannot be status pending
The 3270 code will try to post an attention interrupt when the
3270 emulator (e.g. x3270) attaches. If the guest has not yet
enabled the subchannel for the 3270 device, we will present a spurious
cc 1 (status pending) when it uses msch on it later on, e.g. when
trying to enable the subchannel.
To fix this, just don't do anything in css_conditional_io_interrupt()
if the subchannel is not enabled. The 3270 code will work fine with
that, and the other user of this function (virtio-ccw) never
attempts to post an interrupt for a disabled device to begin with.
CC: qemu-stable@nongnu.org Reported-by: Thomas Huth <thuth@redhat.com> Tested-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
(cherry picked from commit 6e9c893ecd00afd5344c35d0d0ded50eaa0938f6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Fam Zheng [Fri, 1 Jun 2018 09:26:40 +0000 (17:26 +0800)]
raw: Check byte range uniformly
We don't verify the request range against s->size in the I/O callbacks
except for raw_co_pwritev. This is inconsistent (especially for
raw_co_pwrite_zeroes and raw_co_pdiscard), so fix them, in the meanwhile
make the helper reusable by the coming new callbacks.
Note that in most cases the block layer already verifies the request
byte range against our reported image length, before invoking the driver
callbacks. The exception is during image creating, after
blk_set_allow_write_beyond_eof(blk, true) is called. But in that case,
the requests are not directly from the user or guest. So there is no
visible behavior change in adding the check code.
The int64_t -> uint64_t inconsistency, as shown by the type casting, is
pre-existing due to the interface.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com>
Message-id: 20180601092648.24614-3-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 384455385248762e74a080978f18f0c8f74757fe) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Michael Walle [Tue, 9 Jan 2018 17:01:13 +0000 (18:01 +0100)]
lm32: take BQL before writing IP/IM register
Writing to these registers may raise an interrupt request. Actually,
this prevents the milkymist board from starting.
Cc: qemu-stable@nongnu.org Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
(cherry picked from commit 81e9cbd0ca1131012b058df6804b1f626a6b730c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Wed, 2 May 2018 20:20:51 +0000 (22:20 +0200)]
iotests: Add test for -U/force-share conflicts
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180502202051.15493-4-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 4e7d73c5fbd97e55ffe5af02f24d1f7dbe3bbf20) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Wed, 2 May 2018 20:20:50 +0000 (22:20 +0200)]
qemu-img: Use only string options in img_open_opts
img_open_opts() takes a QemuOpts and converts them to a QDict, so all
values therein are strings. Then it may try to call qdict_get_bool(),
however, which will fail with a segmentation fault every time:
$ ./qemu-img info -U --image-opts \
driver=file,filename=/dev/null,force-share=off
[1] 27869 segmentation fault (core dumped) ./qemu-img info -U
--image-opts driver=file,filename=/dev/null,force-share=off
Fix this by using qdict_get_str() and comparing the value as a string.
Also, when adding a force-share value to the QDict, add it as a string
so it fits the rest of the dict.
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180502202051.15493-3-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 4615f87832d2fcb7a544bedeece2741bf8c21f94) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Wed, 2 May 2018 20:20:49 +0000 (22:20 +0200)]
qemu-io: Use purely string blockdev options
Currently, qemu-io only uses string-valued blockdev options (as all are
converted directly from QemuOpts) -- with one exception: -U adds the
force-share option as a boolean. This in itself is already a bit
questionable, but a real issue is that it also assumes the value already
existing in the options QDict would be a boolean, which is wrong.
Since @opts is converted from QemuOpts, the value must be a string, and
we have to compare it as such. Consequently, it makes sense to also set
it as a string instead of a boolean.
Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20180502202051.15493-2-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 2a01c01f9ecb43af4c0a85fe6adc429ffc9c31b5) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Wed, 9 May 2018 18:20:02 +0000 (20:20 +0200)]
iotests: Add test for rebasing with relative paths
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20180509182002.8044-3-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
(cherry picked from commit 28036a7f7044fddb79819e3c8fcb4ae5605c60e0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Wed, 9 May 2018 18:20:01 +0000 (20:20 +0200)]
qemu-img: Resolve relative backing paths in rebase
Currently, rebase interprets a relative path for the new backing image
as follows:
(1) Open the new backing image with the given relative path (thus relative to
qemu-img's working directory).
(2) Write it directly into the overlay's backing path field (thus
relative to the overlay).
If the overlay is not in qemu-img's working directory, both will be
different interpretations, which may either lead to an error somewhere
(either rebase fails because it cannot open the new backing image, or
your overlay becomes unusable because its backing path does not point to
a file), or, even worse, it may result in your rebase being performed
for a different backing file than what your overlay will point to after
the rebase.
Fix this by interpreting the target backing path as relative to the
overlay, like qemu-img does everywhere else.
Make sure we only ask the spice local renderer for display updates in
case we have a valid primary surface. Without that spice is confused
and throws errors in case a display update request (triggered by
screendump for example) happens in parallel to a mode switch and hits
the race window where the old primary surface is gone and the new isn't
establisted yet.
projects / mirror_qemu.git / log