[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 5669ef: qcow2: Avoid COW during metadata prea
|
From: |
Michael Roth |
|
Subject: |
[Qemu-commits] [qemu/qemu] 5669ef: qcow2: Avoid COW during metadata preallocation |
|
Date: |
Thu, 17 Oct 2019 15:10:56 -0700 |
Branch: refs/heads/stable-4.0
Home: https://github.com/qemu/qemu
Commit: 5669ef1e6c40298762fc1f0610d6fac2a9552648
https://github.com/qemu/qemu/commit/5669ef1e6c40298762fc1f0610d6fac2a9552648
Author: Kevin Wolf <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Avoid COW during metadata preallocation
Limiting the allocation to INT_MAX bytes isn't particularly clever
because it means that the final cluster will be a partial cluster which
will be completed through a COW operation. This results in unnecessary
data read and write requests which lead to an unwanted non-sparse
filesystem block for metadata preallocation.
Align the maximum allocation size down to the cluster size to avoid this
situation.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
(cherry picked from commit f29fbf7c6b1c9a84f6931c1c222716fbe073e6e4)
Signed-off-by: Michael Roth <address@hidden>
Commit: e628c14be418cccf7f147a43b7b6c0d92f57e456
https://github.com/qemu/qemu/commit/e628c14be418cccf7f147a43b7b6c0d92f57e456
Author: Kevin Wolf <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Add errp to preallocate_co()
We'll add a bdrv_co_truncate() call in the next patch which can return
an Error that we don't want to discard. So add an errp parameter to
preallocate_co().
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
(cherry picked from commit 360bd07471dfd1830246e8403ffdc9ba9d82f9d4)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4382e8da228961dd319b7bacb5be4248da64de4e
https://github.com/qemu/qemu/commit/4382e8da228961dd319b7bacb5be4248da64de4e
Author: Kevin Wolf <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Fix full preallocation with external data file
preallocate_co() already gave the data file the full size without
forwarding the requested preallocation mode to the protocol. When
bdrv_co_truncate() was called later with the preallocation mode, the
file didn't actually grow any more, so the data file stayed unallocated
even if full preallocation was requested.
Pass the right preallocation mode to preallocate_co() and remove the
second bdrv_co_truncate() to fix this. As a side effect, the ugly
one-byte write in preallocate_co() is replaced with a truncate call,
now leaving the last block unallocated on the protocol level as it
should be.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
(cherry picked from commit 718c0fce2f56755a8d8f737607779a98aa6e7cc4)
Signed-off-by: Michael Roth <address@hidden>
Commit: 173e30de4c655efaa7ced9c3aca732ecacafb477
https://github.com/qemu/qemu/commit/173e30de4c655efaa7ced9c3aca732ecacafb477
Author: Peter Lieven <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
megasas: fix mapped frame size
the current value of 1024 bytes (16 * MFI_FRAME_SIZE) we map is not enough to
hold
the maximum number of scatter gather elements we advertise. We actually need a
maximum of 2048 bytes. This is 128 max sg elements * 16 bytes (sizeof (union
mfi_sgl)).
Cc: address@hidden
Signed-off-by: Peter Lieven <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Hannes Reinecke <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 2e56fbc87f6ec3cd56c37b01d313abd502b80d61)
Signed-off-by: Michael Roth <address@hidden>
Commit: 774f013111dbb0ba3bb542f89ba1126c3c164573
https://github.com/qemu/qemu/commit/774f013111dbb0ba3bb542f89ba1126c3c164573
Author: Kevin Wolf <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Fix qcow2_make_empty() with external data file
make_completely_empty() is an optimisated path for bdrv_make_empty()
where completely new metadata is created inside the image file instead
of going through all clusters and discarding them. For an external data
file, however, we actually need to do discard operations on the data
file; just overwriting the qcow2 file doesn't get rid of the data.
The necessary slow path with an explicit discard operation already
exists for other cases. Use it for external data files, too.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
(cherry picked from commit db04524f820582ebf1189223b6378de238511da1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 626a95f4aa3823e4a1d121ce30400ed843153c10
https://github.com/qemu/qemu/commit/626a95f4aa3823e4a1d121ce30400ed843153c10
Author: Kevin Wolf <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M block.c
Log Message:
-----------
block: Fix AioContext switch for bs->drv == NULL
Even for block nodes with bs->drv == NULL, we can't just ignore a
bdrv_set_aio_context() call. Leaving the node in its old context can
mean that it's still in an iothread context in bdrv_close_all() during
shutdown, resulting in an attempted unlock of the AioContext lock which
we don't hold.
This is an example stack trace of a related crash:
#0 0x00007ffff59da57f in raise () at /lib64/libc.so.6
#1 0x00007ffff59c4895 in abort () at /lib64/libc.so.6
#2 0x0000555555b97b1e in error_exit (err=<optimized out>,
msg=msg@entry=0x555555d386d0 <__func__.19059> "qemu_mutex_unlock_impl") at
util/qemu-thread-posix.c:36
#3 0x0000555555b97f7f in qemu_mutex_unlock_impl
(mutex=mutex@entry=0x5555568002f0, file=file@entry=0x555555d378df
"util/async.c", line=line@entry=507) at util/qemu-thread-posix.c:97
#4 0x0000555555b92f55 in aio_context_release (ctx=ctx@entry=0x555556800290)
at util/async.c:507
#5 0x0000555555b05cf8 in bdrv_prwv_co (child=child@entry=0x7fffc80012f0,
offset=offset@entry=131072, qiov=qiov@entry=0x7fffffffd4f0,
is_write=is_write@entry=true, flags=flags@entry=0)
at block/io.c:833
#6 0x0000555555b060a9 in bdrv_pwritev (qiov=0x7fffffffd4f0, offset=131072,
child=0x7fffc80012f0) at block/io.c:990
#7 0x0000555555b060a9 in bdrv_pwrite (child=0x7fffc80012f0, offset=131072,
buf=<optimized out>, bytes=<optimized out>) at block/io.c:990
#8 0x0000555555ae172b in qcow2_cache_entry_flush (bs=bs@entry=0x555556810680,
c=c@entry=0x5555568cc740, i=i@entry=0) at block/qcow2-cache.c:51
#9 0x0000555555ae18dd in qcow2_cache_write (bs=bs@entry=0x555556810680,
c=0x5555568cc740) at block/qcow2-cache.c:248
#10 0x0000555555ae15de in qcow2_cache_flush (bs=0x555556810680, c=<optimized
out>) at block/qcow2-cache.c:259
#11 0x0000555555ae16b1 in qcow2_cache_flush_dependency (c=0x5555568a1700,
c=0x5555568a1700, bs=0x555556810680) at block/qcow2-cache.c:194
#12 0x0000555555ae16b1 in qcow2_cache_entry_flush (bs=bs@entry=0x555556810680,
c=c@entry=0x5555568a1700, i=i@entry=0) at block/qcow2-cache.c:194
#13 0x0000555555ae18dd in qcow2_cache_write (bs=bs@entry=0x555556810680,
c=0x5555568a1700) at block/qcow2-cache.c:248
#14 0x0000555555ae15de in qcow2_cache_flush (bs=bs@entry=0x555556810680,
c=<optimized out>) at block/qcow2-cache.c:259
#15 0x0000555555ad242c in qcow2_inactivate (bs=bs@entry=0x555556810680) at
block/qcow2.c:2124
#16 0x0000555555ad2590 in qcow2_close (bs=0x555556810680) at block/qcow2.c:2153
#17 0x0000555555ab0c62 in bdrv_close (bs=0x555556810680) at block.c:3358
#18 0x0000555555ab0c62 in bdrv_delete (bs=0x555556810680) at block.c:3542
#19 0x0000555555ab0c62 in bdrv_unref (bs=0x555556810680) at block.c:4598
#20 0x0000555555af4d72 in blk_remove_bs (blk=blk@entry=0x5555568103d0) at
block/block-backend.c:785
#21 0x0000555555af4dbb in blk_remove_all_bs () at block/block-backend.c:483
#22 0x0000555555aae02f in bdrv_close_all () at block.c:3412
#23 0x00005555557f9796 in main (argc=<optimized out>, argv=<optimized out>,
envp=<optimized out>) at vl.c:4776
The reproducer I used is a qcow2 image on gluster volume, where the
virtual disk size (4 GB) is larger than the gluster volume size (64M),
so we can easily trigger an ENOSPC. This backend is assigned to a
virtio-blk device using an iothread, and then from the guest a
'dd if=/dev/zero of=/dev/vda bs=1G count=1' causes the VM to stop
because of an I/O error. qemu_gluster_co_flush_to_disk() sets
bs->drv = NULL on error, so when virtio-blk stops the dataplane, the
block nodes stay in the iothread AioContext. A 'quit' monitor command
issued from this paused state crashes the process.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1631227
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Reviewed-by: Stefano Garzarella <address@hidden>
(cherry picked from commit 1bffe1ae7a7b707c3a14ea2ccd00d3609d3ce4d8)
Signed-off-by: Michael Roth <address@hidden>
Commit: 48025d942e2f4fc3582c37f17a30d0af7d474a66
https://github.com/qemu/qemu/commit/48025d942e2f4fc3582c37f17a30d0af7d474a66
Author: Eric Blake <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M util/cutils.c
Log Message:
-----------
cutils: Fix size_to_str() on 32-bit platforms
When extracting a human-readable size formatter, we changed 'uint64_t
div' pre-patch to 'unsigned long div' post-patch. Which breaks on
32-bit platforms, resulting in 'inf' instead of intended values larger
than 999GB.
Fixes: 22951aaa
CC: address@hidden
Reported-by: Max Reitz <address@hidden>
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 754da86714d550c3f995f11a2587395081362e0a)
Signed-off-by: Michael Roth <address@hidden>
Commit: da436b77d88e5c22b14d43e7c35c9f50855bc0cb
https://github.com/qemu/qemu/commit/da436b77d88e5c22b14d43e7c35c9f50855bc0cb
Author: John Snow <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M Makefile
Log Message:
-----------
Makefile: add nit-picky mode to sphinx-build
If we add references that don't resolve (or accidentally remove them),
it will be helpful to have warning messages alerting us to that.
Further, turn those warnings into errors so we can be alerted to these
problems sooner rather than later.
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
[adjusted commit message. --js]
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 9e5b6cb87db66dfb606604fe6cf40e5ddf1ef0e7)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2974d636581cf3421af6038c4833876fa106f991
https://github.com/qemu/qemu/commit/2974d636581cf3421af6038c4833876fa106f991
Author: John Snow <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M docs/interop/bitmaps.rst
Log Message:
-----------
docs/interop/bitmaps: rewrite and modernize doc
This just about rewrites the entirety of the bitmaps.rst document to
make it consistent with the 4.0 release. I have added new features seen
in the 4.0 release, as well as tried to clarify some points that keep
coming up when discussing this feature both in-house and upstream.
It does not yet cover pull backups or migration details, but I intend to
keep extending this document to cover those cases.
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
[Adjusted commit message. --js]
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 90edef80a0852cf8a3d2668898ee40e8970e4314)
Signed-off-by: Michael Roth <address@hidden>
Commit: ffabb55ec206654cbc7c3505476b57c80282f3fb
https://github.com/qemu/qemu/commit/ffabb55ec206654cbc7c3505476b57c80282f3fb
Author: Cédric Le Goater <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M hw/intc/spapr_xive.c
M hw/intc/xive.c
M include/hw/ppc/xive_regs.h
Log Message:
-----------
spapr/xive: fix EQ page addresses above 64GB
The high order bits of the address of the OS event queue is stored in
bits [4-31] of word2 of the XIVE END internal structures and the low
order bits in word3. This structure is using Big Endian ordering and
computing the value requires some simple arithmetic which happens to
be wrong. The mask removing bits [0-3] of word2 is applied to the
wrong value and the resulting address is bogus when above 64GB.
Guests with more than 64GB of RAM will allocate pages for the OS event
queues which will reside above the 64GB limit. In this case, the XIVE
device model will wake up the CPUs in case of a notification, such as
IPIs, but the update of the event queue will be written at the wrong
place in memory. The result is uncertain as the guest memory is
trashed and IPI are not delivered.
Introduce a helper xive_end_qaddr() to compute this value correctly in
all places where it is used.
Signed-off-by: Cédric Le Goater <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 13df93244efbd4bb8b4cf4e26104a26033178674)
Signed-off-by: Michael Roth <address@hidden>
Commit: a68ab7c88f181fada63f6006a73c0875115b3705
https://github.com/qemu/qemu/commit/a68ab7c88f181fada63f6006a73c0875115b3705
Author: Gerd Hoffmann <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M ui/kbd-state.c
Log Message:
-----------
kbd-state: fix autorepeat handling
When allowing multiple down-events in a row (key autorepeat) we can't
use change_bit() any more to update the state, because autorepeat events
don't change the key state. We have to explicitly use set_bit() and
clear_bit() instead.
Cc: address@hidden
Fixes: 35921860156e kbd-state: don't block auto-repeat events
Buglink: https://bugs.launchpad.net/qemu/+bug/1828272
Signed-off-by: Gerd Hoffmann <address@hidden>
Message-id: address@hidden
(cherry picked from commit 5fff13f245cddd3bc260dfe6ebe1b1f05b72116f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 665218cc085c5c1ec871d8af6986903313638fbf
https://github.com/qemu/qemu/commit/665218cc085c5c1ec871d8af6986903313638fbf
Author: Gerd Hoffmann <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M hw/core/machine.c
Log Message:
-----------
usb-tablet: fix serial compat property
s/kbd/tablet/, fixes cut+paste bug.
Cc: address@hidden
Reported-by: Dr. David Alan Gilbert <address@hidden>
Signed-off-by: Gerd Hoffmann <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
(cherry picked from commit 442bac16a6cd708a9f87adb0a263f9d833f03ed5)
Signed-off-by: Michael Roth <address@hidden>
Commit: 241d89b760fd92827cf22b6ed666cf358e0f53ce
https://github.com/qemu/qemu/commit/241d89b760fd92827cf22b6ed666cf358e0f53ce
Author: Max Reitz <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M block/file-posix.c
Log Message:
-----------
block/file-posix: Unaligned O_DIRECT block-status
Currently, qemu crashes whenever someone queries the block status of an
unaligned image tail of an O_DIRECT image:
$ echo > foo
$ qemu-img map --image-opts driver=file,filename=foo,cache.direct=on
Offset Length Mapped to File
qemu-img: block/io.c:2093: bdrv_co_block_status: Assertion `*pnum &&
QEMU_IS_ALIGNED(*pnum, align) && align > offset - aligned_offset'
failed.
This is because bdrv_co_block_status() checks that the result returned
by the driver's implementation is aligned to the request_alignment, but
file-posix can fail to do so, which is actually mentioned in a comment
there: "[...] possibly including a partial sector at EOF".
Fix this by rounding up those partial sectors.
There are two possible alternative fixes:
(1) We could refuse to open unaligned image files with O_DIRECT
altogether. That sounds reasonable until you realize that qcow2
does necessarily not fill up its metadata clusters, and that nobody
runs qemu-img create with O_DIRECT. Therefore, unpreallocated qcow2
files usually have an unaligned image tail.
(2) bdrv_co_block_status() could ignore unaligned tails. It actually
throws away everything past the EOF already, so that sounds
reasonable.
Unfortunately, the block layer knows file lengths only with a
granularity of BDRV_SECTOR_SIZE, so bdrv_co_block_status() usually
would have to guess whether its file length information is inexact
or whether the driver is broken.
Fixing what raw_co_block_status() returns is the safest thing to do.
There seems to be no other block driver that sets request_alignment and
does not make sure that it always returns aligned values.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 9c3db310ff0b7473272ae8dce5e04e2f8a825390)
Signed-off-by: Michael Roth <address@hidden>
Commit: d8328a3ca5e01432af4c9a877533cf2827784680
https://github.com/qemu/qemu/commit/d8328a3ca5e01432af4c9a877533cf2827784680
Author: Max Reitz <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M tests/qemu-iotests/221
A tests/qemu-iotests/253
A tests/qemu-iotests/253.out
M tests/qemu-iotests/group
Log Message:
-----------
iotests: Test unaligned raw images with O_DIRECT
We already have 221 for accesses through the page cache, but it is
better to create a new file for O_DIRECT instead of integrating those
test cases into 221. This way, we can make use of
_supported_cache_modes (and _default_cache_mode) so the test is
automatically skipped on filesystems that do not support O_DIRECT.
As part of the split, add _supported_cache_modes to 221. With that, it
no longer fails when run with -c none or -c directsync.
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 2fab30c80b33cdc6157c7efe6207e54b6835cf92)
Conflicts:
tests/qemu-iotests/group
*fix context deps on test groups not in 4.0
Signed-off-by: Michael Roth <address@hidden>
Commit: f8d98e2b6db347922972126decbd2f9bb95d8326
https://github.com/qemu/qemu/commit/f8d98e2b6db347922972126decbd2f9bb95d8326
Author: Christian Borntraeger <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M target/s390x/cpu_models.c
Log Message:
-----------
s390x/cpumodel: ignore csske for expansion
csske will be removed in a future machine. Ignore it for expanding the
cpu model. Otherwise qemu falls back to z9.
Signed-off-by: Christian Borntraeger <address@hidden>
Cc: address@hidden
Reviewed-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit eaf6f642abf1d4d24791b70728d4068428fc4658)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2429dc4eea91b381ff67a4d25ea9f6bbfe87c784
https://github.com/qemu/qemu/commit/2429dc4eea91b381ff67a4d25ea9f6bbfe87c784
Author: John Snow <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M blockdev.c
Log Message:
-----------
blockdev-backup: don't check aio_context too early
in blockdev_backup_prepare, we check to make sure that the target is
associated with a compatible aio context. However, do_blockdev_backup is
called later and has some logic to move the target to a compatible
aio_context. The transaction version will fail certain commands
needlessly early as a result.
Allow blockdev_backup_prepare to simply call do_blockdev_backup, which
will ultimately decide if the contexts are compatible or not.
Note: the transaction version has always disallowed this operation since
its initial commit bd8baecd (2014), whereas the version of
qmp_blockdev_backup at the time, from commit c29c1dd312f, tried to
enforce the aio_context switch instead. It's not clear, and I can't see
from the mailing list archives at the time, why the two functions take a
different approach. It wasn't until later in efd7556708b (2016) that the
standalone version tried to determine if it could set the context or
not.
Reported-by: aihua liang <address@hidden>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1683498
Signed-off-by: John Snow <address@hidden>
Message-id: address@hidden
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit d81e1efbea7d19c2f142d300df56538c73800590)
Signed-off-by: Michael Roth <address@hidden>
Commit: 627fadfa1c44a298a04228179dd656de9aa6c9aa
https://github.com/qemu/qemu/commit/627fadfa1c44a298a04228179dd656de9aa6c9aa
Author: Kevin Wolf <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M block.c
Log Message:
-----------
block: Drain source node in bdrv_replace_node()
Instead of just asserting that no requests are in flight in
bdrv_replace_node(), which is a requirement that most callers ignore, we
can just drain the source node right there. This fixes at least starting
a commit job while I/O is active on the backing chain, but probably
other callers, too.
Having requests in flight on the target node isn't a problem because the
target just gets new parents, but the call path of running requests
isn't modified. So we can just drop this assertion without a replacement.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1711643
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
(cherry picked from commit f871abd60f4b67547e62c57c9bec19420052be39)
*prereq for d81e1efb tests
Signed-off-by: Michael Roth <address@hidden>
Commit: 7415a83e9bf9a03c89873c570ab9c1df91f80b75
https://github.com/qemu/qemu/commit/7415a83e9bf9a03c89873c570ab9c1df91f80b75
Author: Kevin Wolf <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
A tests/qemu-iotests/255
A tests/qemu-iotests/255.out
M tests/qemu-iotests/group
M tests/qemu-iotests/iotests.py
Log Message:
-----------
iotests: Test commit job start with concurrent I/O
This tests that concurrent requests are correctly drained before making
graph modifications instead of running into assertions in
bdrv_replace_node().
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
(cherry picked from commit ac6fb43eae1f5029b51e0a3d975fe2111cc8b976)
Conflicts:
tests/qemu-iotests/group
*prereq for d81e1efb tests
Signed-off-by: Michael Roth <address@hidden>
Commit: 94a14e6f2a6d67540e3ccac6399c2be3adeda5bc
https://github.com/qemu/qemu/commit/94a14e6f2a6d67540e3ccac6399c2be3adeda5bc
Author: John Snow <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M tests/qemu-iotests/iotests.py
Log Message:
-----------
iotests.py: do not use infinite waits
Cap waits to 60 seconds so that iotests can fail gracefully if something
goes wrong.
Signed-off-by: John Snow <address@hidden>
Message-id: address@hidden
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 8b6f5f8b9f3bec5cbeebefab34bae0102a2581b3)
Signed-off-by: Michael Roth <address@hidden>
Commit: c7b4a7354157a00a31d332401b56fee14cbb2bf2
https://github.com/qemu/qemu/commit/c7b4a7354157a00a31d332401b56fee14cbb2bf2
Author: John Snow <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M python/qemu/__init__.py
Log Message:
-----------
QEMUMachine: add events_wait method
Instead of event_wait which looks for a single event, add an events_wait
which can look for any number of events simultaneously. However, it
will still only return one at a time, whichever happens first.
Signed-off-by: John Snow <address@hidden>
Message-id: address@hidden
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit f6f4b3f045ea18e3fa93a50cd0462236c428d62e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2ab69df8db1f831ab7aaa1662d685d78823befca
https://github.com/qemu/qemu/commit/2ab69df8db1f831ab7aaa1662d685d78823befca
Author: Max Reitz <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M tests/qemu-iotests/iotests.py
Log Message:
-----------
iotests.py: Fix VM.run_job
log() is in the current module, there is no need to prefix it. In fact,
doing so may make VM.run_job() unusable in tests that never use
iotests.log() themselves.
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Alberto Garcia <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 86a4f599a67b9b709109c7a7c8b7eb91d21c21fd)
*prereq for d6a79af0e6
Signed-off-by: Michael Roth <address@hidden>
Commit: 32097f14fca0836756b80c15cc2f30cd7512d8d8
https://github.com/qemu/qemu/commit/32097f14fca0836756b80c15cc2f30cd7512d8d8
Author: John Snow <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M tests/qemu-iotests/iotests.py
Log Message:
-----------
iotests.py: rewrite run_job to be pickier
Don't pull events out of the queue that don't belong to us;
be choosier so that we can use this method to drive jobs that
were launched by transactions that may have more jobs.
Signed-off-by: John Snow <address@hidden>
Message-id: address@hidden
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit d6a79af0e641806d6bd6a42a4920e294b5db179c)
Signed-off-by: Michael Roth <address@hidden>
Commit: 07cc0a207fafab60f84f153f4b89488c6c0649e3
https://github.com/qemu/qemu/commit/07cc0a207fafab60f84f153f4b89488c6c0649e3
Author: John Snow <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
A tests/qemu-iotests/256
A tests/qemu-iotests/256.out
M tests/qemu-iotests/group
Log Message:
-----------
iotests: add iotest 256 for testing blockdev-backup across iothread contexts
Signed-off-by: John Snow <address@hidden>
Message-id: address@hidden
Reviewed-by: Max Reitz <address@hidden>
[mreitz: Moved from 250 to 256]
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit ba7704f2228f16ed61b9903801e28e17666c7e38)
Signed-off-by: Michael Roth <address@hidden>
Commit: 3a87d07722d4be717a97b59cfbc7b2ba27ca30b0
https://github.com/qemu/qemu/commit/3a87d07722d4be717a97b59cfbc7b2ba27ca30b0
Author: John Snow <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M migration/block-dirty-bitmap.c
Log Message:
-----------
migration/dirty-bitmaps: change bitmap enumeration method
Shift from looking at every root BDS to *every* BDS. This will migrate
bitmaps that are attached to blockdev created nodes instead of just ones
attached to emulated storage devices.
Note that this will not migrate anonymous or internal-use bitmaps, as
those are defined as having no name.
This will also fix the Coverity issues Peter Maydell has been asking
about for the past several releases, as well as fixing a real bug.
Reported-by: Peter Maydell <address@hidden>
Reported-by: Coverity 😅
Reported-by: aihua liang <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Signed-off-by: John Snow <address@hidden>
Message-id: address@hidden
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1652490
Fixes: Coverity CID 1390625
CC: Stefan Hajnoczi <address@hidden>
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 592203e7cfbd1ad261178431fcf390adfe8b16df)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1cf90f8a9797cebef6cf0cbe26306b51e0bac916
https://github.com/qemu/qemu/commit/1cf90f8a9797cebef6cf0cbe26306b51e0bac916
Author: Li Hangjing <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M hw/virtio/vhost.c
Log Message:
-----------
vhost: fix vhost_log size overflow during migration
When a guest which doesn't support multiqueue is migrated with a multi queues
vhost-user-blk deivce, a crash will occur like:
0 qemu_memfd_alloc (name=<value optimized out>, size=562949953421312,
seals=<value optimized out>, fd=0x7f87171fe8b4, errp=0x7f87171fe8a8) at
util/memfd.c:153
1 0x00007f883559d7cf in vhost_log_alloc (size=70368744177664, share=true) at
hw/virtio/vhost.c:186
2 0x00007f88355a0758 in vhost_log_get (listener=0x7f8838bd7940, enable=1) at
qemu-2-12/hw/virtio/vhost.c:211
3 vhost_dev_log_resize (listener=0x7f8838bd7940, enable=1) at
hw/virtio/vhost.c:263
4 vhost_migration_log (listener=0x7f8838bd7940, enable=1) at
hw/virtio/vhost.c:787
5 0x00007f88355463d6 in memory_global_dirty_log_start () at memory.c:2503
6 0x00007f8835550577 in ram_init_bitmaps (f=0x7f88384ce600,
opaque=0x7f8836024098) at migration/ram.c:2173
7 ram_init_all (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2192
8 ram_save_setup (f=0x7f88384ce600, opaque=0x7f8836024098) at
migration/ram.c:2219
9 0x00007f88357a419d in qemu_savevm_state_setup (f=0x7f88384ce600) at
migration/savevm.c:1002
10 0x00007f883579fc3e in migration_thread (opaque=0x7f8837530400) at
migration/migration.c:2382
11 0x00007f8832447893 in start_thread () from /lib64/libpthread.so.0
12 0x00007f8832178bfd in clone () from /lib64/libc.so.6
This is because vhost_get_log_size() returns a overflowed vhost-log size.
In this function, it uses the uninitialized variable vqs->used_phys and
vqs->used_size to get the vhost-log size.
Signed-off-by: Li Hangjing <address@hidden>
Reviewed-by: Xie Yongji <address@hidden>
Reviewed-by: Chai Wen <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 240e647a14df9677b3a501f7b8b870e40aac3fd5)
Signed-off-by: Michael Roth <address@hidden>
Commit: 14c9bbab092e497ed737f320e2b6da4a2c888d90
https://github.com/qemu/qemu/commit/14c9bbab092e497ed737f320e2b6da4a2c888d90
Author: Anton Blanchard <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M target/ppc/translate/vsx-impl.inc.c
Log Message:
-----------
target/ppc: Fix xvabs[sd]p, xvnabs[sd]p, xvneg[sd]p, xvcpsgn[sd]p
We were using set_cpu_vsr*() when we should have used get_cpu_vsr*().
Fixes: 8b3b2d75c7c0 ("introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}()
helpers for VSR register access")
Signed-off-by: Anton Blanchard <address@hidden>
Message-Id: <20190509104912.6b754dff@kryten>
Reviewed-by: Mark Cave-Ayland <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(upstream commit 77bd8937c03dd55e57cc257951ad07c185303c3e)
Acked-by: David Gibson <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: fd72de904789b0659d89af0046d85ce8286a4b45
https://github.com/qemu/qemu/commit/fd72de904789b0659d89af0046d85ce8286a4b45
Author: Anton Blanchard <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M target/ppc/translate/vsx-impl.inc.c
Log Message:
-----------
target/ppc: Fix xvxsigdp
Fix a typo in xvxsigdp where we put both results into the lower
doubleword.
Fixes: dd977e4f45cb ("target/ppc: Optimize x[sv]xsigdp using deposit_i64()")
Signed-off-by: Anton Blanchard <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(upstream commit cf4e9363f7fd889d8d804c8f78e8927782c2aa48)
Acked-by: David Gibson <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: da3bd13802dd49052dc1ac6443e24635dbf2ee51
https://github.com/qemu/qemu/commit/da3bd13802dd49052dc1ac6443e24635dbf2ee51
Author: Anton Blanchard <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M target/ppc/translate/vsx-impl.inc.c
Log Message:
-----------
target/ppc: Fix xxbrq, xxbrw
Fix a typo in xxbrq and xxbrw where we put both results into the lower
doubleword.
Fixes: 8b3b2d75c7c0 ("introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}()
helpers for VSR register access")
Signed-off-by: Anton Blanchard <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(upstream commit d47a751adab7833e9831408376077bc8dba41d5d)
Acked-by: David Gibson <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: b6159fc9a67c78c0783db0b7e704b8f57f827f6b
https://github.com/qemu/qemu/commit/b6159fc9a67c78c0783db0b7e704b8f57f827f6b
Author: Anton Blanchard <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M target/ppc/int_helper.c
Log Message:
-----------
target/ppc: Fix vsum2sws
A recent cleanup changed the pre zeroing of the result from 64 bit
to 32 bit operations:
- result.u64[i] = 0;
+ result.VsrW(i) = 0;
This corrupts the result.
Fixes: 60594fea298d ("target/ppc: remove various HOST_WORDS_BIGENDIAN hacks in
int_helper.c")
Signed-off-by: Anton Blanchard <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(upstream commit 7fa0ddc1d63806769d1b6246a62708d3bde39037)
Acked-by: David Gibson <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: 75f83e7c4a270fdd42253510d48c0ff1ae166751
https://github.com/qemu/qemu/commit/75f83e7c4a270fdd42253510d48c0ff1ae166751
Author: Anton Blanchard <address@hidden>
Date: 2019-09-17 (Tue, 17 Sep 2019)
Changed paths:
M target/ppc/translate/vsx-impl.inc.c
Log Message:
-----------
target/ppc: Fix lxvw4x, lxvh8x and lxvb16x
During the conversion these instructions were incorrectly treated as
stores. We need to use set_cpu_vsr* and not get_cpu_vsr*.
Fixes: 8b3b2d75c7c0 ("introduce get_cpu_vsr{l,h}() and set_cpu_vsr{l,h}()
helpers for VSR register access")
Signed-off-by: Anton Blanchard <address@hidden>
Reviewed-by: Mark Cave-Ayland <address@hidden>
Tested-by: Greg Kurz <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(upstream commit 2a1224359008e23b051b7b45be4789afa0269f8c)
Acked-by: David Gibson <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: 92fa1b1a28bbb47905d31440da13ca1a88a2de3d
https://github.com/qemu/qemu/commit/92fa1b1a28bbb47905d31440da13ca1a88a2de3d
Author: Alex Williamson <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/core/machine.c
M hw/i386/pc.c
M hw/i386/pc_q35.c
M include/hw/boards.h
M include/hw/i386/pc.h
M tests/bios-tables-test.c
Log Message:
-----------
q35: Revert to kernel irqchip
Backport of QEMU v4.1 commit for stable v4.0.1 release
commit c87759ce876a7a0b17c2bf4f0b964bd51f0ee871
Author: Alex Williamson <address@hidden>
Date: Tue May 14 14:14:41 2019 -0600
q35: Revert to kernel irqchip
Commit b2fc91db8447 ("q35: set split kernel irqchip as default") changed
the default for the pc-q35-4.0 machine type to use split irqchip, which
turned out to have disasterous effects on vfio-pci INTx support. KVM
resampling irqfds are registered for handling these interrupts, but
these are non-functional in split irqchip mode. We can't simply test
for split irqchip in QEMU as userspace handling of this interrupt is a
significant performance regression versus KVM handling (GeForce GPUs
assigned to Windows VMs are non-functional without forcing MSI mode or
re-enabling kernel irqchip).
The resolution is to revert the change in default irqchip mode in the
pc-q35-4.1 machine and create a pc-q35-4.0.1 machine for the 4.0-stable
branch. The qemu-q35-4.0 machine type should not be used in vfio-pci
configurations for devices requiring legacy INTx support without
explicitly modifying the VM configuration to use kernel irqchip.
Link: https://bugs.launchpad.net/qemu/+bug/1826422
Fixes: b2fc91db8447 ("q35: set split kernel irqchip as default")
Cc: address@hidden
Reviewed-by: Peter Xu <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>
(upstream commit c87759ce876a7a0b17c2bf4f0b964bd51f0ee871)
Reviewed-by: Michael S. Tsirkin <address@hidden>
*add comments regarding AML mismatch warnings from
tests/bios-tables-test.c
Signed-off-by: Michael Roth <address@hidden>
Commit: 8e29c657cacbea10e35b27e5069f0e340a7c03a4
https://github.com/qemu/qemu/commit/8e29c657cacbea10e35b27e5069f0e340a7c03a4
Author: Markus Armbruster <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M vl.c
Log Message:
-----------
vl: Fix -drive / -blockdev persistent reservation management
qemu-system-FOO's main() acts on command line arguments in its own
idiosyncratic order. There's not much method to its madness.
Whenever we find a case where one kind of command line argument needs
to refer to something created for another kind later, we rejigger the
order.
Recent commit cda4aa9a5a "vl: Create block backends before setting
machine properties" was such a rejigger. Block backends are now
created before "delayed" objects. This broke persistent reservation
management. Reproducer:
$ qemu-system-x86_64 -object
pr-manager-helper,id=pr-helper0,path=/tmp/pr-helper0.sock-drive -drive
file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2
qemu-system-x86_64: -drive
file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2:
No persistent reservation manager with id 'pr-helper0'
The delayed pr-manager-helper object is created too late for use by
-drive or -blockdev. Normal objects are still created in time.
pr-manager-helper has always been a delayed object (commit 7c9e527659
"scsi, file-posix: add support for persistent reservation
management"). Turns out there's no real reason for that. Make it a
normal object.
Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce
Signed-off-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michal Privoznik <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 9ea18ed25a36527167e9676f25d983df5e7f76e6)
Signed-off-by: Michael Roth <address@hidden>
Commit: 41e1564fb50515d7902628d25c0c8421a8516cc1
https://github.com/qemu/qemu/commit/41e1564fb50515d7902628d25c0c8421a8516cc1
Author: Paolo Bonzini <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386: add MDS-NO feature
Microarchitectural Data Sampling is a hardware vulnerability which allows
unprivileged speculative access to data which is available in various CPU
internal buffers.
Some Intel processors use the ARCH_CAP_MDS_NO bit in the
IA32_ARCH_CAPABILITIES
MSR to report that they are not vulnerable, make it available to guests.
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 20140a82c67467f53814ca197403d5e1b561a5e5)
Signed-off-by: Oguz Bektas <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: 7427060f98d603020ef99e1ba3f07f7ee7c193ba
https://github.com/qemu/qemu/commit/7427060f98d603020ef99e1ba3f07f7ee7c193ba
Author: Paolo Bonzini <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386: define md-clear bit
md-clear is a new CPUID bit which is set when microcode provides the
mechanism to invoke a flush of various exploitable CPU buffers by invoking
the VERW instruction.
Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit b2ae52101fca7f9547ac2f388085dbc58f8fe1c0)
Signed-off-by: Oguz Bektas <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: 8da804f4f9d4d60c4efc9e71093b1c3ef8c25e67
https://github.com/qemu/qemu/commit/8da804f4f9d4d60c4efc9e71093b1c3ef8c25e67
Author: Daniel P. Berrangé <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M docs/qemu-cpu-models.texi
Log Message:
-----------
docs: recommend use of md-clear feature on all Intel CPUs
Update x86 CPU model guidance to recommend that the md-clear feature is
manually enabled with all Intel CPU models, when supported by the host
microcode.
Signed-off-by: Daniel P. Berrangé <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 2c7e82a30774730100da9dbe68d2360459030d91)
Signed-off-by: Oguz Bektas <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: 32e8ac8a28f80df7d303900f6501fdfc96f4725d
https://github.com/qemu/qemu/commit/32e8ac8a28f80df7d303900f6501fdfc96f4725d
Author: Marc-André Lureau <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-pci.c
Log Message:
-----------
virtio-pci: fix missing device properties
Since commit a4ee4c8baa37154 ("virtio: Helper for registering virtio
device types"), virtio-gpu-pci, virtio-vga, and virtio-crypto-pci lost
some properties: "ioeventfd" and "vectors". This may cause various
issues, such as failing migration or invalid properties.
Since those VirtioPCI devices do not have a base name, their class are
initialized with virtio_pci_generic_base_class_init(). However, if the
VirtioPCIDeviceTypeInfo provided a class_init which sets dc->props,
the properties were overwritten by virtio_pci_generic_class_init().
Instead, introduce an intermediary base-type to register the generic
properties.
Fixes: a4ee4c8baa37154f42b4dc6a13fee79268d15238
Cc: address@hidden
Signed-off-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
(cherry picked from commit 683c1d89efd1eeb111c129a9a91f629b94d90d45)
Signed-off-by: Michael Roth <address@hidden>
Commit: e86e620656becb37890a6d91e0148c74f3e43f3d
https://github.com/qemu/qemu/commit/e86e620656becb37890a6d91e0148c74f3e43f3d
Author: Marc-André Lureau <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/usb/redirect.c
Log Message:
-----------
usbredir: fix buffer-overflow on vmload
If interface_count is NO_INTERFACE_INFO, let's not access the arrays
out-of-bounds.
==994==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x625000243930
at pc 0x5642068086a8 bp 0x7f0b6f9ffa50 sp 0x7f0b6f9ffa40
READ of size 1 at 0x625000243930 thread T0
#0 0x5642068086a7 in usbredir_check_bulk_receiving
/home/elmarco/src/qemu/hw/usb/redirect.c:1503
#1 0x56420681301c in usbredir_post_load
/home/elmarco/src/qemu/hw/usb/redirect.c:2154
#2 0x5642068a56c2 in vmstate_load_state
/home/elmarco/src/qemu/migration/vmstate.c:168
#3 0x56420688e2ac in vmstate_load
/home/elmarco/src/qemu/migration/savevm.c:829
#4 0x5642068980cb in qemu_loadvm_section_start_full
/home/elmarco/src/qemu/migration/savevm.c:2211
#5 0x564206899645 in qemu_loadvm_state_main
/home/elmarco/src/qemu/migration/savevm.c:2395
#6 0x5642068998cf in qemu_loadvm_state
/home/elmarco/src/qemu/migration/savevm.c:2467
#7 0x56420685f3e9 in process_incoming_migration_co
/home/elmarco/src/qemu/migration/migration.c:449
#8 0x564207106c47 in coroutine_trampoline
/home/elmarco/src/qemu/util/coroutine-ucontext.c:115
#9 0x7f0c0604e37f (/lib64/libc.so.6+0x4d37f)
Signed-off-by: Marc-André Lureau <address@hidden>
Reviewed-by: Liam Merwick <address@hidden>
Reviewed-by: Li Qiang <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 7b84b90966568da0e05655ecaa78c209300aae6e)
Signed-off-by: Michael Roth <address@hidden>
Commit: a6fe4a3aa8007524ffe4758109c08f3ac102c628
https://github.com/qemu/qemu/commit/a6fe4a3aa8007524ffe4758109c08f3ac102c628
Author: Stefan Hajnoczi <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/core/machine.c
M hw/virtio/virtio-balloon.c
M include/hw/virtio/virtio-balloon.h
Log Message:
-----------
virtio-balloon: fix QEMU 4.0 config size migration incompatibility
The virtio-balloon config size changed in QEMU 4.0 even for existing
machine types. Migration from QEMU 3.1 to 4.0 can fail in some
circumstances with the following error:
qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10 read: a1
device: 1 cmask: ff wmask: c0 w1cmask:0
This happens because the virtio-balloon config size affects the VIRTIO
Legacy I/O Memory PCI BAR size.
Introduce a qdev property called "qemu-4-0-config-size" and enable it
only for the QEMU 4.0 machine types. This way <4.0 machine types use
the old size, 4.0 uses the larger size, and >4.0 machine types use the
appropriate size depending on enabled virtio-balloon features.
Live migration to and from old QEMUs to QEMU 4.1 works again as long as
a versioned machine type is specified (do not use just "pc"!).
Originally-by: Wolfgang Bumiller <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Tested-by: Dr. David Alan Gilbert <address@hidden>
Tested-by: Wolfgang Bumiller <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 2bbadb08ce272d65e1f78621002008b07d1e0f03)
Conflicts:
hw/core/machine.c
* drop context dep. on 0a71966253c
Signed-off-by: Michael Roth <address@hidden>
Commit: e653d5ed1863a5a5e4f8178d87c33d223f902bf3
https://github.com/qemu/qemu/commit/e653d5ed1863a5a5e4f8178d87c33d223f902bf3
Author: John Snow <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M docs/interop/bitmaps.rst
Log Message:
-----------
docs/interop/bitmaps.rst: Fix typos
Pygments and Sphinx get pickier all the time; Sphinx 2.1+ now catches
these errors.
Signed-off-by: John Snow <address@hidden>
Reported-by: Aarushi Mehta <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 575e6226287072bd0d6eb85d9712d280eb29c392)
Signed-off-by: Michael Roth <address@hidden>
Commit: 22a03c48e7c84b39009dea584a2c67498f9573b7
https://github.com/qemu/qemu/commit/22a03c48e7c84b39009dea584a2c67498f9573b7
Author: John Snow <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M docs/conf.py
A docs/sphinx/qmp_lexer.py
Log Message:
-----------
sphinx: add qmp_lexer
Sphinx, through Pygments, does not like annotated json examples very
much. In some versions of Sphinx (1.7), it will render the non-json
portions of code blocks in red, but in newer versions (2.0) it will
throw an exception and not highlight the block at all. Though we can
suppress this warning, it doesn't bring back highlighting on non-strict
json blocks.
We can alleviate this by creating a custom lexer for QMP examples that
allows us to properly highlight these examples in a robust way, keeping
our directionality and elision notations.
Signed-off-by: Eduardo Habkost <address@hidden>
Signed-off-by: John Snow <address@hidden>
Reported-by: Aarushi Mehta <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit cd231e13bdcb8d686b014bef940c7d19c6f1e769)
Signed-off-by: Michael Roth <address@hidden>
Commit: e11cd43f24c10751816896866bdab384773bf688
https://github.com/qemu/qemu/commit/e11cd43f24c10751816896866bdab384773bf688
Author: John Snow <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M docs/interop/bitmaps.rst
Log Message:
-----------
docs/bitmaps: use QMP lexer instead of json
The annotated style json we use in QMP documentation is not strict json
and depending on the version of Sphinx (2.0+) or Pygments installed,
might cause the build to fail.
Use the new QMP lexer.
Further, some versions of Sphinx can not apply custom lexers to "code"
directives and require the use of "code-block" directives instead, so
make that change at this time as well.
Tested under:
- Sphinx 1.3.6 and Pygments 2.4
- Sphinx 1.7.6 and Pygments 2.2 (Fedora 29 packages)
- Sphinx 2.0.1 and Pygments 2.4
- Sphinx 3.0.0+/f396b3a783 and Pygments 2.4 (From Sphinx git c4f44bdd)
Reported-by: Aarushi Mehta <address@hidden>
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Eduardo Habkost <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit a7786bfb0effe0b4b0fc61d8a8cd307c0b739ed7)
Signed-off-by: Michael Roth <address@hidden>
Commit: 255325da13fb93fb417adec98c614229bd6e6acc
https://github.com/qemu/qemu/commit/255325da13fb93fb417adec98c614229bd6e6acc
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/ssi/xilinx_spips.c
Log Message:
-----------
hw/ssi/xilinx_spips: Convert lqspi_read() to read_with_attrs
In the next commit we will implement the write_with_attrs()
handler. To avoid using different APIs, convert the read()
handler first.
Reviewed-by: Francisco Iglesias <address@hidden>
Tested-by: Francisco Iglesias <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 5937bd50d3841b6ab2592c1ff4233448762a8483)
Signed-off-by: Michael Roth <address@hidden>
Commit: 804a0ae6c07bae1de5620b553866d08db8a8acf0
https://github.com/qemu/qemu/commit/804a0ae6c07bae1de5620b553866d08db8a8acf0
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/ssi/xilinx_spips.c
Log Message:
-----------
hw/ssi/xilinx_spips: Avoid AXI writes to the LQSPI linear memory
Lei Sun found while auditing the code that a CPU write would
trigger a NULL pointer dereference.
>From UG1085 datasheet [*] AXI writes in this region are ignored
and generates an AXI Slave Error (SLVERR).
Fix by implementing the write_with_attrs() handler.
Return MEMTX_ERROR when the region is accessed (this error maps
to an AXI slave error).
[*]
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
Reported-by: Lei Sun <address@hidden>
Reviewed-by: Francisco Iglesias <address@hidden>
Tested-by: Francisco Iglesias <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 936a236c4e4b1068ade99220260cd04f68eb0212)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5ad70231d31ce1c70bbd1d10098e482c90d760f5
https://github.com/qemu/qemu/commit/5ad70231d31ce1c70bbd1d10098e482c90d760f5
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/ssi/xilinx_spips.c
Log Message:
-----------
hw/ssi/xilinx_spips: Avoid out-of-bound access to lqspi_buf[]
Both lqspi_read() and lqspi_load_cache() expect a 32-bit
aligned address.
>From UG1085 datasheet [*] chapter on 'Quad-SPI Controller':
Transfer Size Limitations
Because of the 32-bit wide TX, RX, and generic FIFO, all
APB/AXI transfers must be an integer multiple of 4-bytes.
Shorter transfers are not possible.
Set MemoryRegionOps.impl values to force 32-bit accesses,
this way we are sure we do not access the lqspi_buf[] array
out of bound.
[*]
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
Reviewed-by: Francisco Iglesias <address@hidden>
Tested-by: Francisco Iglesias <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 526668c734e6a07f2fedfd378840a61b70c1cbab)
Signed-off-by: Michael Roth <address@hidden>
Commit: d25b37247d9fe5671059556699d5d8be643f6cf9
https://github.com/qemu/qemu/commit/d25b37247d9fe5671059556699d5d8be643f6cf9
Author: Jan Kiszka <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/intc/ioapic.c
Log Message:
-----------
ioapic: kvm: Skip route updates for masked pins
Masked entries will not generate interrupt messages, thus do no need to
be routed by KVM. This is a cosmetic cleanup, just avoiding warnings of
the kind
qemu-system-x86_64: vtd_irte_get: detected non-present IRTE (index=0,
high=0xff00, low=0x100)
if the masked entry happens to reference a non-present IRTE.
Cc: address@hidden
Signed-off-by: Jan Kiszka <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
(cherry picked from commit be1927c97e564346cbd409cb17fe611df74b84e5)
Signed-off-by: Michael Roth <address@hidden>
Commit: eeb25956e764de7e103b3177acd59b0b93d90f54
https://github.com/qemu/qemu/commit/eeb25956e764de7e103b3177acd59b0b93d90f54
Author: Evgeny Yakovlev <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/i386/acpi-build.c
Log Message:
-----------
i386/acpi: show PCI Express bus on pxb-pcie expanders
Show PCIe host bridge PNP id with PCI host bridge as a compatible id
when expanding a pcie bus.
Cc: address@hidden
Signed-off-by: Evgeny Yakovlev <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit ee4b0c8686f781987879508d7c6dd605b5435bac)
Signed-off-by: Michael Roth <address@hidden>
Commit: 912440beb5eee62ffac2b6511ac58fed31bf9b7e
https://github.com/qemu/qemu/commit/912440beb5eee62ffac2b6511ac58fed31bf9b7e
Author: David Hildenbrand <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: Fix wrong sign extension of PFNs
If we directly cast from int to uint64_t, we will first sign-extend to
an int64_t, which is wrong. We actually want to treat the PFNs like
unsigned values.
As far as I can see, this dates back to the initial virtio-balloon
commit, but wasn't triggered as fairly big guests would be required.
Cc: address@hidden
Reported-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: David Gibson <address@hidden>
(cherry picked from commit ffa207d08253ffffb3993a1dbe09e40af4fc91f1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 04e35fe3c4ab0e37854348f5742a29fb5de99c97
https://github.com/qemu/qemu/commit/04e35fe3c4ab0e37854348f5742a29fb5de99c97
Author: David Hildenbrand <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: Fix QEMU crashes on pagesize > BALLOON_PAGE_SIZE
We are using the wrong functions to set/clear bits, effectively touching
multiple bits, writing out of range of the bitmap, resulting in memory
corruptions. We have to use set_bit()/clear_bit() instead.
Can easily be reproduced by starting a qemu guest on hugetlbfs memory,
inflating the balloon. QEMU crashes. This never could have worked
properly - especially, also pages would have been discarded when the
first sub-page would be inflated (the whole bitmap would be set).
While testing I realized, that on hugetlbfs it is pretty much impossible
to discard a page - the guest just frees the 4k sub-pages in random order
most of the time. I was only able to discard a hugepage a handful of
times - so I hope that now works correctly.
Fixes: ed48c59875b6 ("virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host
page size")
Fixes: b27b32391404 ("virtio-balloon: Fix possible guest memory corruption with
inflates & deflates")
Cc: address@hidden #v4.0.0
Acked-by: David Gibson <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 483f13524bb2a08b7ff6a7560b846564ed3b0c33)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2c743c85220e99910536ba9db590e339853716c0
https://github.com/qemu/qemu/commit/2c743c85220e99910536ba9db590e339853716c0
Author: David Hildenbrand <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: Simplify deflate with pbp
Let's simplify this - the case we are optimizing for is very hard to
trigger and not worth the effort. If we're switching from inflation to
deflation, let's reset the pbp.
Acked-by: David Gibson <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 2ffc49eea1bbd454913a88a0ad872c2649b36950)
Signed-off-by: Michael Roth <address@hidden>
Commit: b50aab6b836c37344be7ab3b4810ad01cb500e0e
https://github.com/qemu/qemu/commit/b50aab6b836c37344be7ab3b4810ad01cb500e0e
Author: David Hildenbrand <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: Better names for offset variables in inflate/deflate code
"host_page_base" is really confusing, let's make this clearer, also
rename the other offsets to indicate to which base they apply.
offset -> mr_offset
ram_offset -> rb_offset
host_page_base -> rb_aligned_offset
While at it, use QEMU_ALIGN_DOWN() instead of a handcrafted computation
and move the computation to the place where it is needed.
Acked-by: David Gibson <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit e6129b271b9dccca22c84870e313c315f2c70063)
Signed-off-by: Michael Roth <address@hidden>
Commit: d0444b1ee3c6f5cdc3975dc41f27a0c43c398af6
https://github.com/qemu/qemu/commit/d0444b1ee3c6f5cdc3975dc41f27a0c43c398af6
Author: David Hildenbrand <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: Rework pbp tracking data
Using the address of a RAMBlock to test for a matching pbp is not really
safe. Instead, let's use the guest physical address of the base page
along with the page size (via the number of subpages).
Also, let's allocate the bitmap separately. This makes the code
easier to read and maintain - we can reuse bitmap_new().
Prepare the code to move the PBP out of the device.
Fixes: ed48c59875b6 ("virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host
page size")
Fixes: b27b32391404 ("virtio-balloon: Fix possible guest memory corruption with
inflates & deflates")
Cc: address@hidden #v4.0.0
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 1c5cfc2b7153dd72bf4b8ddc456408eb2b9b66d8)
Signed-off-by: Michael Roth <address@hidden>
Commit: 8e20acad634e38f29afd54b951c42eec113288bc
https://github.com/qemu/qemu/commit/8e20acad634e38f29afd54b951c42eec113288bc
Author: David Hildenbrand <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-balloon.c
M include/hw/virtio/virtio-balloon.h
Log Message:
-----------
virtio-balloon: Use temporary PBP only
We still have multiple issues in the current code
- The PBP is not freed during unrealize()
- The PBP is not reset on device resets: After a reset, the PBP is stale.
- We are not indicating VIRTIO_BALLOON_F_MUST_TELL_HOST, therefore
guests (esp. legacy guests) will reuse pages without deflating,
turning the PBP stale. Adding that would require compat handling.
Instead, let's use the PBP only temporarily, when processing one bulk of
inflation requests. This will keep guest_page_size > 4k working (with
Linux guests). There is nothing to do for deflation requests anymore.
The pbp is only used for a limited amount of time.
Fixes: ed48c59875b6 ("virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host
page size")
Cc: address@hidden #v4.0.0
Suggested-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Acked-by: David Gibson <address@hidden>
(cherry picked from commit a8cd64d488325f3be5c4ddec4bf07efb3b8c7330)
Signed-off-by: Michael Roth <address@hidden>
Commit: f18bce29e1259e079dc4089f40ab26c333a47c81
https://github.com/qemu/qemu/commit/f18bce29e1259e079dc4089f40ab26c333a47c81
Author: David Hildenbrand <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: don't track subpages for the PBP
As ramblocks cannot get removed/readded while we are processing a bulk
of inflation requests, there is no more need to track the page size
in form of the number of subpages.
Suggested-by: David Gibson <address@hidden>
Signed-off-by: David Hildenbrand <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 9a7ca8a7c920360db9dcaf616ca6f1440c025043)
Signed-off-by: Michael Roth <address@hidden>
Commit: c4ac49457896e13139f9edb83fa88c04a2d524b1
https://github.com/qemu/qemu/commit/c4ac49457896e13139f9edb83fa88c04a2d524b1
Author: Michael S. Tsirkin <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: free pbp more aggressively
Previous patches switched to a temporary pbp but that does not go far
enough: after device uses a buffer, guest is free to reuse it, so
tracking the page and freeing it later is wrong.
Free and reset the pbp after we push each element.
Fixes: ed48c59875b6 ("virtio-balloon: Safely handle BALLOON_PAGE_SIZE < host
page size")
Cc: address@hidden #v4.0.0
Cc: David Hildenbrand <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 1b47b37c33ec01ae1efc527f4c97f97f93723bc4)
Signed-off-by: Michael Roth <address@hidden>
Commit: d7e9b19f0b4ae99e1a5bfe8f190847e7f1785db4
https://github.com/qemu/qemu/commit/d7e9b19f0b4ae99e1a5bfe8f190847e7f1785db4
Author: Evgeny Yakovlev <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/i386/acpi-build.c
Log Message:
-----------
i386/acpi: fix gint overflow in crs_range_compare
When very large regions (32GB sized in our case, PCI pass-through of GPUs)
are compared substraction result does not fit into gint.
As a result crs_replace_with_free_ranges does not get sorted ranges and
incorrectly computes PCI64 free space regions. Which then makes linux
guest complain about device and PCI64 hole intersection and device
becomes unusable.
Fix that by returning exactly fitting ranges.
Also fix indentation of an entire crs_replace_with_free_ranges to make
checkpatch happy.
Cc: address@hidden
Signed-off-by: Evgeny Yakovlev <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Evgeny Yakovlev <address@hidden>
(cherry picked from commit 21e2acd583126db94f6d881005cd58e835160582)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0647727e4754d291d57a598cf3d0fa5b53cd5d41
https://github.com/qemu/qemu/commit/0647727e4754d291d57a598cf3d0fa5b53cd5d41
Author: Stefan Berger <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/tpm/tpm_crb.c
M hw/tpm/tpm_tis.c
Log Message:
-----------
tpm: Exit in reset when backend indicates failure
Exit() in the frontend reset function when the backend indicates
intialization failure.
Signed-off-by: Stefan Berger <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
(cherry picked from commit bcfd16fe26d6bb6eabfd2dfb46b9fda59d5493db)
Signed-off-by: Michael Roth <address@hidden>
Commit: 6210ff6aa2ba332f1539d30f80a1f5aeffb3a3f8
https://github.com/qemu/qemu/commit/6210ff6aa2ba332f1539d30f80a1f5aeffb3a3f8
Author: Stefan Berger <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/tpm/tpm_emulator.c
M hw/tpm/tpm_int.h
Log Message:
-----------
tpm_emulator: Translate TPM error codes to strings
Implement a function to translate TPM error codes to strings so that
at least the most common error codes can be translated to human
readable strings.
Signed-off-by: Stefan Berger <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
(cherry picked from commit 7e095e84ba0b7c0a1ac45bc6824dace2fd352e56)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0b55b27908f29f641e95b43c891b1984b25c6080
https://github.com/qemu/qemu/commit/0b55b27908f29f641e95b43c891b1984b25c6080
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
block/backup: simplify backup_incremental_init_copy_bitmap
Simplify backup_incremental_init_copy_bitmap using the function
bdrv_dirty_bitmap_next_dirty_area.
Note: move to job->len instead of bitmap size: it should not matter but
less code.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit c2da3413c021398152e98022261bb1643276a2fe)
*prereq for 4a5b91ca
Signed-off-by: Michael Roth <address@hidden>
Commit: 3f6c00eb618389034a0414ea119665f8cc36b2ca
https://github.com/qemu/qemu/commit/3f6c00eb618389034a0414ea119665f8cc36b2ca
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
block/backup: move to copy_bitmap with granularity
We are going to share this bitmap between backup and backup-top filter
driver, so let's share something more meaningful. It also simplifies
some calculations.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit a8389e315ef71913ae99cf8f3b1f89e84631f599)
*prereq for 4a5b91ca
Signed-off-by: Michael Roth <address@hidden>
Commit: 87851171b4adc456ba6de97e729cf87ace318288
https://github.com/qemu/qemu/commit/87851171b4adc456ba6de97e729cf87ace318288
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
block/backup: refactor and tolerate unallocated cluster skipping
Split allocation checking to separate function and reduce nesting.
Consider bdrv_is_allocated() fail as allocated area, as copying more
than needed is not wrong (and we do it anyway) and seems better than
fail the whole job. And, most probably we will fail on the next read,
if there are real problem with source.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 9eb5a248f3e50c1f034bc6ff4b2f25c8c56515a5)
*prereq for 110571be4e
Signed-off-by: Michael Roth <address@hidden>
Commit: 54d45c8251d1ee392eb1d5b537ef9189d9f918a2
https://github.com/qemu/qemu/commit/54d45c8251d1ee392eb1d5b537ef9189d9f918a2
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
block/backup: unify different modes code path
Do full, top and incremental mode copying all in one place. This
unifies the code path and helps further improvements.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit c334e897d08eea1f5a3a95f6a2208afe6757c103)
*prereq for 110571be4e
Signed-off-by: Michael Roth <address@hidden>
Commit: 872b7b8ef9a62a72a125a9bb87e77b8e6867c7e1
https://github.com/qemu/qemu/commit/872b7b8ef9a62a72a125a9bb87e77b8e6867c7e1
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
block/backup: refactor: split out backup_calculate_cluster_size
Split out cluster_size calculation. Move copy-bitmap creation above
block-job creation, as we are going to share it with upcoming
backup-top filter, which also should be created before actual block job
creation.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
[mreitz: Dropped a paragraph from the commit message that was left over
from a previous version]
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit ae6b12fa4cf7d54add35531c790aaf2bd6d833f3)
*prereq for 110571be4e
Signed-off-by: Michael Roth <address@hidden>
Commit: 70353442dbda6c66475403d1907f14939e73b716
https://github.com/qemu/qemu/commit/70353442dbda6c66475403d1907f14939e73b716
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
backup: Copy only dirty areas
The backup job must only copy areas that the copy_bitmap reports as
dirty. This is always the case when using traditional non-offloading
backup, because it copies each cluster separately. When offloading the
copy operation, we sometimes copy more than one cluster at a time, but
we only check whether the first one is dirty.
Therefore, whenever copy offloading is possible, the backup job
currently produces wrong output when the guest writes to an area of
which an inner part has already been backed up, because that inner part
will be re-copied.
Fixes: 9ded4a0114968e98b41494fc035ba14f84cdf700
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 4a5b91ca024fc6fd87021c54655af76a35f2ef1e)
Signed-off-by: Michael Roth <address@hidden>
Commit: c430d7684e0afc1c07bbc844a90e39311783b469
https://github.com/qemu/qemu/commit/c430d7684e0afc1c07bbc844a90e39311783b469
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M tests/qemu-iotests/056
M tests/qemu-iotests/056.out
Log Message:
-----------
iotests: Test backup job with two guest writes
Perform two guest writes to not yet backed up areas of an image, where
the former touches an inner area of the latter.
Before HEAD^, copy offloading broke this in two ways:
(1) The target image differs from the reference image (what the source
was when the backup started).
(2) But you will not see that in the failing output, because the job
offset is reported as being greater than the job length. This is
because one cluster is copied twice, and thus accounted for twice,
but of course the job length does not increase.
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Tested-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 5f594a2e99f19ca0f7744d333bcd556f5976b78f)
Signed-off-by: Michael Roth <address@hidden>
Commit: fc5c701636127a0b90cd7ab564da0354d06809dc
https://github.com/qemu/qemu/commit/fc5c701636127a0b90cd7ab564da0354d06809dc
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M util/hbitmap.c
Log Message:
-----------
util/hbitmap: update orig_size on truncate
Without this, hbitmap_next_zero and hbitmap_next_dirty_area are broken
after truncate. So, orig_size is broken since it's introduction in
76d570dc495c56bb.
Fixes: 76d570dc495c56bb
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Reviewed-by: Max Reitz <address@hidden>
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 4e4de222799634d8159ee7b9303b9e1b45c6be2c)
Signed-off-by: Michael Roth <address@hidden>
Commit: f69d8f2347b210bab8d8cd11611dd67e4b6da2c5
https://github.com/qemu/qemu/commit/f69d8f2347b210bab8d8cd11611dd67e4b6da2c5
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M tests/qemu-iotests/124
M tests/qemu-iotests/124.out
Log Message:
-----------
iotests: Test incremental backup after truncation
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 8a9cb864086269af14bbd13f395472703cf99f8c)
Signed-off-by: Michael Roth <address@hidden>
Commit: d65d02614b6b0f6bcc64cd2a737b5204c0fc5304
https://github.com/qemu/qemu/commit/d65d02614b6b0f6bcc64cd2a737b5204c0fc5304
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/mirror.c
Log Message:
-----------
mirror: Only mirror granularity-aligned chunks
In write-blocking mode, all writes to the top node directly go to the
target. We must only mirror chunks of data that are aligned to the
job's granularity, because that is how the dirty bitmap works.
Therefore, the request alignment for writes must be the job's
granularity (in write-blocking mode).
Unfortunately, this forces all reads and writes to have the same
granularity (we only need this alignment for writes to the target, not
the source), but that is something to be fixed another time.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Fixes: d06107ade0ce74dc39739bac80de84b51ec18546
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 9adc1cb49af8d4e54f57980b1eed5c0a4b2dafa6)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5a35dbf228b3e2a6bb3d72bc8cdb3d37abac7fdb
https://github.com/qemu/qemu/commit/5a35dbf228b3e2a6bb3d72bc8cdb3d37abac7fdb
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M tests/qemu-iotests/151
M tests/qemu-iotests/151.out
Log Message:
-----------
iotests: Test unaligned blocking mirror write
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 19ba4651fe2d17cc49adae29acbb4a8cc29db8d1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 7d4b4677907a262edc7b67bb07442de742a859f3
https://github.com/qemu/qemu/commit/7d4b4677907a262edc7b67bb07442de742a859f3
Author: Vladimir Sementsov-Ogievskiy <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/backup.c
Log Message:
-----------
block/backup: disable copy_range for compressed backup
Enabled by default copy_range ignores compress option. It's definitely
unexpected for user.
It's broken since introduction of copy_range usage in backup in
9ded4a011496.
Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Message-id: address@hidden
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 110571be4e70ac015628e76d2731f96dd8d1998c)
Signed-off-by: Michael Roth <address@hidden>
Commit: 107018c4fdcd82a888b79bd29e75eadcd15dabcd
https://github.com/qemu/qemu/commit/107018c4fdcd82a888b79bd29e75eadcd15dabcd
Author: John Snow <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/ide/ahci.c
M hw/ide/core.c
Log Message:
-----------
Revert "ide/ahci: Check for -ECANCELED in aio callbacks"
This reverts commit 0d910cfeaf2076b116b4517166d5deb0fea76394.
It's not correct to just ignore an error code in a callback; we need to
handle that error and possible report failure to the guest so that they
don't wait indefinitely for an operation that will now never finish.
This ought to help cases reported by Nutanix where iSCSI returns a
legitimate -ECANCELED for certain operations which should be propagated
normally.
Reported-by: Shaju Abraham <address@hidden>
Signed-off-by: John Snow <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 8ec41c4265714255d5a138f8b538faf3583dcff6)
Signed-off-by: Michael Roth <address@hidden>
Commit: cb7630af20d353cbde66ddfb14d858737ffaf877
https://github.com/qemu/qemu/commit/cb7630af20d353cbde66ddfb14d858737ffaf877
Author: Alberto Garcia <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Fix the calculation of the maximum L2 cache size
The size of the qcow2 L2 cache defaults to 32 MB, which can be easily
larger than the maximum amount of L2 metadata that the image can have.
For example: with 64 KB clusters the user would need a qcow2 image
with a virtual size of 256 GB in order to have 32 MB of L2 metadata.
Because of that, since commit b749562d9822d14ef69c9eaa5f85903010b86c30
we forbid the L2 cache to become larger than the maximum amount of L2
metadata for the image, calculated using this formula:
uint64_t max_l2_cache = virtual_disk_size / (s->cluster_size / 8);
The problem with this formula is that the result should be rounded up
to the cluster size because an L2 table on disk always takes one full
cluster.
For example, a 1280 MB qcow2 image with 64 KB clusters needs exactly
160 KB of L2 metadata, but we need 192 KB on disk (3 clusters) even if
the last 32 KB of those are not going to be used.
However QEMU rounds the numbers down and only creates 2 cache tables
(128 KB), which is not enough for the image.
A quick test doing 4KB random writes on a 1280 MB image gives me
around 500 IOPS, while with the correct cache size I get 16K IOPS.
Cc: address@hidden
Signed-off-by: Alberto Garcia <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit b70d08205b2e4044c529eefc21df2c8ab61b473b)
Signed-off-by: Michael Roth <address@hidden>
Commit: 53c641048e0a8da1d2bed76cbd17f259a35e39a0
https://github.com/qemu/qemu/commit/53c641048e0a8da1d2bed76cbd17f259a35e39a0
Author: Paolo Bonzini <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M dma-helpers.c
Log Message:
-----------
dma-helpers: ensure AIO callback is invoked after cancellation
dma_aio_cancel unschedules the BH if there is one, which corresponds
to the reschedule_dma case of dma_blk_cb. This can stall the DMA
permanently, because dma_complete will never get invoked and therefore
nobody will ever invoke the original AIO callback in dbs->common.cb.
Fix this by invoking the callback (which is ensured to happen after
a bdrv_aio_cancel_async, or done manually in the dbs->bh case), and
add assertions to check that the DMA state machine is indeed waiting
for dma_complete or reschedule_dma, but never both.
Reported-by: John Snow <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 539343c0a47e19d5dd64d846d64d084d9793681f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0570d468b76790b268734458070d21ba0e1043b5
https://github.com/qemu/qemu/commit/0570d468b76790b268734458070d21ba0e1043b5
Author: Peter Maydell <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Don't abort on M-profile exception return in linux-user mode
An attempt to do an exception-return (branch to one of the magic
addresses) in linux-user mode for M-profile should behave like
a normal branch, because linux-user mode is always going to be
in 'handler' mode. This used to work, but we broke it when we added
support for the M-profile security extension in commit d02a8698d7ae2bfed.
In that commit we allowed even handler-mode calls to magic return
values to be checked for and dealt with by causing an
EXCP_EXCEPTION_EXIT exception to be taken, because this is
needed for the FNC_RETURN return-from-non-secure-function-call
handling. For system mode we added a check in do_v7m_exception_exit()
to make any spurious calls from Handler mode behave correctly, but
forgot that linux-user mode would also be affected.
How an attempted return-from-non-secure-function-call in linux-user
mode should be handled is not clear -- on real hardware it would
result in return to secure code (not to the Linux kernel) which
could then handle the error in any way it chose. For QEMU we take
the simple approach of treating this erroneous return the same way
it would be handled on a CPU without the security extensions --
treat it as a normal branch.
The upshot of all this is that for linux-user mode we should never
do any of the bx_excret magic, so the code change is simple.
This ought to be a weird corner case that only affects broken guest
code (because Linux user processes should never be attempting to do
exception returns or NS function returns), except that the code that
assigns addresses in RAM for the process and stack in our linux-user
code does not attempt to avoid this magic address range, so
legitimate code attempting to return to a trampoline routine on the
stack can fall into this case. This change fixes those programs,
but we should also look at restricting the range of memory we
use for M-profile linux-user guests to the area that would be
real RAM in hardware.
Cc: address@hidden
Reported-by: Christophe Lyon <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Fixes: https://bugs.launchpad.net/qemu/+bug/1840922
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 5e5584c89f36b302c666bc6db535fd3f7ff35ad2)
Signed-off-by: Michael Roth <address@hidden>
Commit: 434a15214f3016fc308debe353a9b1d17c582cab
https://github.com/qemu/qemu/commit/434a15214f3016fc308debe353a9b1d17c582cab
Author: Anthony PERARD <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/xen/xen-bus.c
Log Message:
-----------
xen-bus: Fix backend state transition on device reset
When a frontend wants to reset its state and the backend one, it
starts with setting "Closing", then waits for the backend (QEMU) to do
the same.
But when QEMU is setting "Closing" to its state, it triggers an event
(xenstore watch) that re-execute xen_device_backend_changed() and set
the backend state to "Closed". QEMU should wait for the frontend to
set "Closed" before doing the same.
Before setting "Closed" to the backend_state, we are also going to
check if there is a frontend. If that the case, when the backend state
is set to "Closing" the frontend should react and sets its state to
"Closing" then "Closed". The backend should wait for that to happen.
Fixes: b6af8926fb858c4f1426e5acb2cfc1f0580ec98a
Signed-off-by: Anthony PERARD <address@hidden>
Reviewed-by: Paul Durrant <address@hidden>
Message-Id: <address@hidden>
(cherry picked from commit cb3231460747552d70af9d546dc53d8195bcb796)
Signed-off-by: Michael Roth <address@hidden>
Commit: 83f9b84c8bcb24265e25cd7f22e971e81cacebc6
https://github.com/qemu/qemu/commit/83f9b84c8bcb24265e25cd7f22e971e81cacebc6
Author: Markus Armbruster <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M scsi/pr-manager.c
Log Message:
-----------
pr-manager: Fix invalid g_free() crash bug
pr_manager_worker() passes its @opaque argument to g_free(). Wrong;
it points to pr_manager_worker()'s automatic @data. Broken when
commit 2f3a7ab39be converted @data from heap- to stack-allocated. Fix
by deleting the g_free().
Fixes: 2f3a7ab39bec4ba8022dc4d42ea641165b004e3e
Cc: address@hidden
Signed-off-by: Markus Armbruster <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 6b9d62c2a9e83bbad73fb61406f0ff69b46ff6f3)
Signed-off-by: Michael Roth <address@hidden>
Commit: 88a2ea5a4872cfb7e8b66f4cdc203e2a6fd3c034
https://github.com/qemu/qemu/commit/88a2ea5a4872cfb7e8b66f4cdc203e2a6fd3c034
Author: John Snow <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M tests/qemu-iotests/iotests.py
Log Message:
-----------
iotests: add testing shim for script-style python tests
Because the new-style python tests don't use the iotests.main() test
launcher, we don't turn on the debugger logging for these scripts
when invoked via ./check -d.
Refactor the launcher shim into new and old style shims so that they
share environmental configuration.
Two cleanup notes: debug was not actually used as a global, and there
was no reason to create a class in an inner scope just to achieve
default variables; we can simply create an instance of the runner with
the values we want instead.
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 456a2d5ac7641c7e75c76328a561b528a8607a8e)
*prereq for 1a37e31244/88d2aa533a
Signed-off-by: Michael Roth <address@hidden>
Commit: 43143d5d91f535eebea9f0c3fac6575a8c831fcf
https://github.com/qemu/qemu/commit/43143d5d91f535eebea9f0c3fac6575a8c831fcf
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/vpc.c
Log Message:
-----------
vpc: Return 0 from vpc_co_create() on success
blockdev_create_run() directly uses .bdrv_co_create()'s return value as
the job's return value. Jobs must return 0 on success, not just any
nonnegative value. Therefore, using blockdev-create for VPC images may
currently fail as the vpc driver may return a positive integer.
Because there is no point in returning a positive integer anywhere in
the block layer (all non-negative integers are generally treated as
complete success), we probably do not want to add more such cases.
Therefore, fix this problem by making the vpc driver always return 0 in
case of success.
Suggested-by: Kevin Wolf <address@hidden>
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 1a37e3124407b5a145d44478d3ecbdb89c63789f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 89e4faa9ca615cd473825fe00cb5c5e09f57fb67
https://github.com/qemu/qemu/commit/89e4faa9ca615cd473825fe00cb5c5e09f57fb67
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M tests/qemu-iotests/iotests.py
Log Message:
-----------
iotests: Add supported protocols to execute_test()
Signed-off-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 88d2aa533a4a1aad44a27c2e6cd5bc5fbcbce7ed)
Signed-off-by: Michael Roth <address@hidden>
Commit: f949655dd33a78457debd1b8f2064c49e230bf10
https://github.com/qemu/qemu/commit/f949655dd33a78457debd1b8f2064c49e230bf10
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M tests/qemu-iotests/030
M tests/qemu-iotests/040
M tests/qemu-iotests/041
M tests/qemu-iotests/044
M tests/qemu-iotests/045
M tests/qemu-iotests/055
M tests/qemu-iotests/056
M tests/qemu-iotests/057
M tests/qemu-iotests/065
M tests/qemu-iotests/096
M tests/qemu-iotests/118
M tests/qemu-iotests/124
M tests/qemu-iotests/129
M tests/qemu-iotests/132
M tests/qemu-iotests/139
M tests/qemu-iotests/148
M tests/qemu-iotests/151
M tests/qemu-iotests/152
M tests/qemu-iotests/155
M tests/qemu-iotests/163
M tests/qemu-iotests/165
M tests/qemu-iotests/169
M tests/qemu-iotests/196
M tests/qemu-iotests/199
M tests/qemu-iotests/245
Log Message:
-----------
iotests: Restrict file Python tests to file
Most of our Python unittest-style tests only support the file protocol.
You can run them with any other protocol, but the test will simply
ignore your choice and use file anyway.
We should let them signal that they require the file protocol so they
are skipped when you want to test some other protocol.
Signed-off-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 103cbc771e5660d1f5bb458be80aa9e363547ae0)
Conflicts:
tests/qemu-iotests/257
*drop changes for test 257, not present in 4.0
Signed-off-by: Michael Roth <address@hidden>
Commit: 491bf156718ca25a5c3c2f9d91c216d400e532b9
https://github.com/qemu/qemu/commit/491bf156718ca25a5c3c2f9d91c216d400e532b9
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M tests/qemu-iotests/147
M tests/qemu-iotests/205
Log Message:
-----------
iotests: Restrict nbd Python tests to nbd
We have two Python unittest-style tests that test NBD. As such, they
should specify supported_protocols=['nbd'] so they are skipped when the
user wants to test some other protocol.
Furthermore, we should restrict their choice of formats to 'raw'. The
idea of a protocol/format combination is to use some format over some
protocol; but we always use the raw format over NBD. It does not really
matter what the NBD server uses on its end, and it is not a useful test
of the respective format driver anyway.
Signed-off-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 7c932a1d69a6d6ac5c0b615c11d191da3bbe9aa8)
Signed-off-by: Michael Roth <address@hidden>
Commit: e40124c4873ca7bee8d56235331047d4386a71e7
https://github.com/qemu/qemu/commit/e40124c4873ca7bee8d56235331047d4386a71e7
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
A tests/qemu-iotests/266
A tests/qemu-iotests/266.out
M tests/qemu-iotests/group
Log Message:
-----------
iotests: Test blockdev-create for vpc
Signed-off-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit cb73747e1a47b93d3dfdc3f769c576b053916938)
Conflicts:
tests/qemu-iotests/group
*drop context dep. on tests not in 4.0
Signed-off-by: Michael Roth <address@hidden>
Commit: ce9c8f676782a9faf2c3b22ea174bb9ee8e660d0
https://github.com/qemu/qemu/commit/ce9c8f676782a9faf2c3b22ea174bb9ee8e660d0
Author: Johannes Berg <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M contrib/libvhost-user/libvhost-user.c
Log Message:
-----------
libvhost-user: fix SLAVE_SEND_FD handling
It doesn't look like this could possibly work properly since
VHOST_USER_PROTOCOL_F_SLAVE_SEND_FD is defined to 10, but the
dev->protocol_features has a bitmap. I suppose the peer this
was tested with also supported VHOST_USER_PROTOCOL_F_LOG_SHMFD,
in which case the test would always be false, but nevertheless
the code seems wrong.
Use has_feature() to fix this.
Fixes: d84599f56c82 ("libvhost-user: support host notifier")
Signed-off-by: Johannes Berg <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Tiwei Bie <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 8726b70b449896f1211f869ec4f608904f027207)
Signed-off-by: Michael Roth <address@hidden>
Commit: c24d971c130d889d4d001d2ae2cb02b9a34d51b6
https://github.com/qemu/qemu/commit/c24d971c130d889d4d001d2ae2cb02b9a34d51b6
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/create.c
Log Message:
-----------
block/create: Do not abort if a block driver is not available
The 'blockdev-create' QMP command was introduced as experimental
feature in commit b0292b851b8, using the assert() debug call.
It got promoted to 'stable' command in 3fb588a0f2c, but the
assert call was not removed.
Some block drivers are optional, and bdrv_find_format() might
return a NULL value, triggering the assertion.
Stable code is not expected to abort, so return an error instead.
This is easily reproducible when libnfs is not installed:
./configure
[...]
module support no
Block whitelist (rw)
Block whitelist (ro)
libiscsi support yes
libnfs support no
[...]
Start QEMU:
$ qemu-system-x86_64 -S -qmp unix:/tmp/qemu.qmp,server,nowait
Send the 'blockdev-create' with the 'nfs' driver:
$ ( cat << 'EOF'
{'execute': 'qmp_capabilities'}
{'execute': 'blockdev-create', 'arguments': {'job-id': 'x', 'options':
{'size': 0, 'driver': 'nfs', 'location': {'path': '/', 'server': {'host':
'::1', 'type': 'inet'}}}}, 'id': 'x'}
EOF
) | socat STDIO UNIX:/tmp/qemu.qmp
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 4},
"package": "v4.1.0-733-g89ea03a7dc"}, "capabilities": ["oob"]}}
{"return": {}}
QEMU crashes:
$ gdb qemu-system-x86_64 core
Program received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00007ffff510957f in raise () at /lib64/libc.so.6
#1 0x00007ffff50f3895 in abort () at /lib64/libc.so.6
#2 0x00007ffff50f3769 in _nl_load_domain.cold.0 () at /lib64/libc.so.6
#3 0x00007ffff5101a26 in .annobin_assert.c_end () at /lib64/libc.so.6
#4 0x0000555555d7e1f1 in qmp_blockdev_create (job_id=0x555556baee40 "x",
options=0x555557666610, errp=0x7fffffffc770) at block/create.c:69
#5 0x0000555555c96b52 in qmp_marshal_blockdev_create (args=0x7fffdc003830,
ret=0x7fffffffc7f8, errp=0x7fffffffc7f0) at qapi/qapi-commands-block-core.c:1314
#6 0x0000555555deb0a0 in do_qmp_dispatch (cmds=0x55555645de70
<qmp_commands>, request=0x7fffdc005c70, allow_oob=false, errp=0x7fffffffc898)
at qapi/qmp-dispatch.c:131
#7 0x0000555555deb2a1 in qmp_dispatch (cmds=0x55555645de70 <qmp_commands>,
request=0x7fffdc005c70, allow_oob=false) at qapi/qmp-dispatch.c:174
With this patch applied, QEMU returns a QMP error:
{'execute': 'blockdev-create', 'arguments': {'job-id': 'x', 'options':
{'size': 0, 'driver': 'nfs', 'location': {'path': '/', 'server': {'host':
'::1', 'type': 'inet'}}}}, 'id': 'x'}
{"id": "x", "error": {"class": "GenericError", "desc": "Block driver 'nfs'
not found or not supported"}}
Cc: address@hidden
Reported-by: Xu Tian <address@hidden>
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit d90d5cae2b10efc0e8d0b3cc91ff16201853d3ba)
Signed-off-by: Michael Roth <address@hidden>
Commit: 6cb3e9e4f17c182c43ded773a04b1072c881aa78
https://github.com/qemu/qemu/commit/6cb3e9e4f17c182c43ded773a04b1072c881aa78
Author: Peter Lieven <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/nfs.c
Log Message:
-----------
block/nfs: tear down aio before nfs_close
nfs_close is a sync call from libnfs and has its own event
handler polling on the nfs FD. Avoid that both QEMU and libnfs
are intefering here.
CC: address@hidden
Signed-off-by: Peter Lieven <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 601dc6559725f7a614b6f893611e17ff0908e914)
Signed-off-by: Michael Roth <address@hidden>
Commit: b9405afb0956fe2c293a94bdc4440579e5c0efee
https://github.com/qemu/qemu/commit/b9405afb0956fe2c293a94bdc4440579e5c0efee
Author: Sergio Lopez <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M blockjob.c
Log Message:
-----------
blockjob: update nodes head while removing all bdrv
block_job_remove_all_bdrv() iterates through job->nodes, calling
bdrv_root_unref_child() for each entry. The call to the latter may
reach child_job_[can_]set_aio_ctx(), which will also attempt to
traverse job->nodes, potentially finding entries that where freed
on previous iterations.
To avoid this situation, update job->nodes head on each iteration to
ensure that already freed entries are no longer linked to the list.
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1746631
Signed-off-by: Sergio Lopez <address@hidden>
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Sergio Lopez <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit d876bf676f5e7c6aa9ac64555e48cba8734ecb2f)
Signed-off-by: Michael Roth <address@hidden>
Commit: c4134c9c46864a3bff04b92acbf8ea5b1b0ca6d9
https://github.com/qemu/qemu/commit/c4134c9c46864a3bff04b92acbf8ea5b1b0ca6d9
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Keep pointer to the CURLState in CURLSocket
A follow-up patch will make curl_multi_do() and curl_multi_read() take a
CURLSocket instead of the CURLState. They still need the latter,
though, so add a pointer to it to the former.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: John Snow <address@hidden>
Message-id: address@hidden
Reviewed-by: Maxim Levitsky <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 0487861685294660b23bc146e1ebd5304aa8bbe0)
Signed-off-by: Michael Roth <address@hidden>
Commit: 06b178eb6168dd5d3a50b7dc210cac748c1f19a1
https://github.com/qemu/qemu/commit/06b178eb6168dd5d3a50b7dc210cac748c1f19a1
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Keep *socket until the end of curl_sock_cb()
This does not really change anything, but it makes the code a bit easier
to follow once we use @socket as the opaque pointer for
aio_set_fd_handler().
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Maxim Levitsky <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 007f339b1099af46a008dac438ca0943e31dba72)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2aba40a2c8813533ebc4af02d181745e4ae96142
https://github.com/qemu/qemu/commit/2aba40a2c8813533ebc4af02d181745e4ae96142
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Check completion in curl_multi_do()
While it is more likely that transfers complete after some file
descriptor has data ready to read, we probably should not rely on it.
Better be safe than sorry and call curl_multi_check_completion() in
curl_multi_do(), too, just like it is done in curl_multi_read().
With this change, curl_multi_do() and curl_multi_read() are actually the
same, so drop curl_multi_read() and use curl_multi_do() as the sole FD
handler.
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Maxim Levitsky <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 948403bcb1c7e71dcbe8ab8479cf3934a0efcbb5)
Signed-off-by: Michael Roth <address@hidden>
Commit: 076796fd39129d0b6c96a3bb4038af2f2b180a70
https://github.com/qemu/qemu/commit/076796fd39129d0b6c96a3bb4038af2f2b180a70
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Pass CURLSocket to curl_multi_do()
curl_multi_do_locked() currently marks all sockets as ready. That is
not only inefficient, but in fact unsafe (the loop is). A follow-up
patch will change that, but to do so, curl_multi_do_locked() needs to
know exactly which socket is ready; and that is accomplished by this
patch here.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Maxim Levitsky <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 9dbad87d25587ff640ef878f7b6159fc368ff541)
Signed-off-by: Michael Roth <address@hidden>
Commit: deea66dc61e526e59c25149b15f552ae27d6003b
https://github.com/qemu/qemu/commit/deea66dc61e526e59c25149b15f552ae27d6003b
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Report only ready sockets
Instead of reporting all sockets to cURL, only report the one that has
caused curl_multi_do_locked() to be called. This lets us get rid of the
QLIST_FOREACH_SAFE() list, which was actually wrong: SAFE foreaches are
only safe when the current element is removed in each iteration. If it
possible for the list to be concurrently modified, we cannot guarantee
that only the current element will be removed. Therefore, we must not
use QLIST_FOREACH_SAFE() here.
Fixes: ff5ca1664af85b24a4180d595ea6873fd3deac57
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Maxim Levitsky <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 9abaf9fc474c3dd53e8e119326abc774c977c331)
Signed-off-by: Michael Roth <address@hidden>
Commit: 6739c97bdec07481392ac4f00445038247b16d76
https://github.com/qemu/qemu/commit/6739c97bdec07481392ac4f00445038247b16d76
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Handle success in multi_check_completion
Background: As of cURL 7.59.0, it verifies that several functions are
not called from within a callback. Among these functions is
curl_multi_add_handle().
curl_read_cb() is a callback from cURL and not a coroutine. Waking up
acb->co will lead to entering it then and there, which means the current
request will settle and the caller (if it runs in the same coroutine)
may then issue the next request. In such a case, we will enter
curl_setup_preadv() effectively from within curl_read_cb().
Calling curl_multi_add_handle() will then fail and the new request will
not be processed.
Fix this by not letting curl_read_cb() wake up acb->co. Instead, leave
the whole business of settling the AIOCB objects to
curl_multi_check_completion() (which is called from our timer callback
and our FD handler, so not from any cURL callbacks).
Reported-by: Natalie Gavrielov <address@hidden>
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1740193
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Maxim Levitsky <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit bfb23b480a49114315877aacf700b49453e0f9d9)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4e5fe75422608046312f986743e4e267c2e3bdd6
https://github.com/qemu/qemu/commit/4e5fe75422608046312f986743e4e267c2e3bdd6
Author: Max Reitz <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: Check curl_multi_add_handle()'s return code
If we had done that all along, debugging would have been much simpler.
(Also, I/O errors are better than hangs.)
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Maxim Levitsky <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit c34dc07f9f01cf686e512f939aece744723072cd)
Signed-off-by: Michael Roth <address@hidden>
Commit: c2e03e2aa42d0f4f41deb08c2655503835840afa
https://github.com/qemu/qemu/commit/c2e03e2aa42d0f4f41deb08c2655503835840afa
Author: Michael Roth <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M slirp/src/ip_input.c
Log Message:
-----------
slirp: Fix heap overflow in ip_reass on big packet input
When the first fragment does not fit in the preallocated buffer, q will
already be pointing to the ext buffer, so we mustn't try to update it.
Signed-off-by: Samuel Thibault <address@hidden>
(from libslirp.git commit 126c04acbabd7ad32c2b018fe10dfac2a3bc1210)
(from libslirp.git commit e0be80430c390bce181ea04dfcdd6ea3dfa97de1)
*squash in e0be80 (clarifying comments)
Fixes: CVE-2019-14378
Signed-off-by: Michael Roth <address@hidden>
Commit: b27192be13da3fb59f51185d9a1f944b3474b2fc
https://github.com/qemu/qemu/commit/b27192be13da3fb59f51185d9a1f944b3474b2fc
Author: Michael Roth <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M slirp/src/ip_input.c
Log Message:
-----------
slirp: ip_reass: Fix use after free
Using ip_deq after m_free might read pointers from an allocation reuse.
This would be difficult to exploit, but that is still related with
CVE-2019-14378 which generates fragmented IP packets that would trigger this
issue and at least produce a DoS.
Signed-off-by: Samuel Thibault <address@hidden>
(from libslirp.git commit c59279437eda91841b9d26079c70b8a540d41204)
Fixes: CVE-2019-15890
Signed-off-by: Michael Roth <address@hidden>
Commit: a8f24b6bdf52abbe5d13495c7470484e71343c7f
https://github.com/qemu/qemu/commit/a8f24b6bdf52abbe5d13495c7470484e71343c7f
Author: Matthew Rosato <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/s390x/s390-pci-bus.c
Log Message:
-----------
s390: PCI: fix IOMMU region init
The fix in dbe9cf606c shrinks the IOMMU memory region to a size
that seems reasonable on the surface, however is actually too
small as it is based against a 0-mapped address space. This
causes breakage with small guests as they can overrun the IOMMU window.
Let's go back to the prior method of initializing iommu for now.
Fixes: dbe9cf606c ("s390x/pci: Set the iommu region size mpcifc request")
Cc: address@hidden
Reviewed-by: Pierre Morel <address@hidden>
Reported-by: Boris Fiuczynski <address@hidden>
Tested-by: Boris Fiuczynski <address@hidden>
Reported-by: Stefan Zimmerman <address@hidden>
Signed-off-by: Matthew Rosato <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>
(cherry picked from commit 7df1dac5f1c85312474df9cb3a8fcae72303da62)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4f1c6cb2f9afafda05eab150fd2bd284edce6676
https://github.com/qemu/qemu/commit/4f1c6cb2f9afafda05eab150fd2bd284edce6676
Author: Thomas Huth <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/core/loader.c
Log Message:
-----------
hw/core/loader: Fix possible crash in rom_copy()
Both, "rom->addr" and "addr" are derived from the binary image
that can be loaded with the "-kernel" paramer. The code in
rom_copy() then calculates:
d = dest + (rom->addr - addr);
and uses "d" as destination in a memcpy() some lines later. Now with
bad kernel images, it is possible that rom->addr is smaller than addr,
thus "rom->addr - addr" gets negative and the memcpy() then tries to
copy contents from the image to a bad memory location. This could
maybe be used to inject code from a kernel image into the QEMU binary,
so we better fix it with an additional sanity check here.
Cc: address@hidden
Reported-by: Guangming Liu
Buglink: https://bugs.launchpad.net/qemu/+bug/1844635
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Thomas Huth <address@hidden>
(cherry picked from commit e423455c4f23a1a828901c78fe6d03b7dde79319)
Signed-off-by: Michael Roth <address@hidden>
Commit: b65e78320bba2655b60355739ed1a1da2ccc6c78
https://github.com/qemu/qemu/commit/b65e78320bba2655b60355739ed1a1da2ccc6c78
Author: Paolo Bonzini <address@hidden>
Date: 2019-10-01 (Tue, 01 Oct 2019)
Changed paths:
M hw/scsi/lsi53c895a.c
Log Message:
-----------
scsi: lsi: exit infinite loop while executing script (CVE-2019-12068)
When executing script in lsi_execute_script(), the LSI scsi adapter
emulator advances 's->dsp' index to read next opcode. This can lead
to an infinite loop if the next opcode is empty. Move the existing
loop exit after 10k iterations so that it covers no-op opcodes as
well.
Reported-by: Bugs SysSec <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit de594e47659029316bbf9391efb79da0a1a08e08)
Signed-off-by: Michael Roth <address@hidden>
Commit: a81a7fc22e0e185ddaa878d44e92ea7776f1b8a5
https://github.com/qemu/qemu/commit/a81a7fc22e0e185ddaa878d44e92ea7776f1b8a5
Author: Igor Mammedov <address@hidden>
Date: 2019-10-03 (Thu, 03 Oct 2019)
Changed paths:
M hw/mem/pc-dimm.c
Log Message:
-----------
pc-dimm: fix crash when invalid slot number is used
QEMU will crash with:
Segmentation fault (core dumped)
when negative slot number is used, ex:
qemu-system-x86_64 -m 1G,maxmem=20G,slots=256 \
-object memory-backend-ram,id=mem1,size=1G \
-device pc-dimm,id=dimm1,memdev=mem1,slot=-2
fix it by checking that slot number is within valid range.
Signed-off-by: Igor Mammedov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Reviewed-by: Li Qiang <address@hidden>
Signed-off-by: Igor Mammedov <<a href="mailto:address@hidden";
target="_blank">address@hidden</a>><br></blockquote><div><br></div><div>Reviewed-by:
Li Qiang <<a
href="mailto:address@hidden";>address@hidden</a>><br></div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Reviewed-by: Pankaj Gupta <address@hidden>
(cherry picked from commit 22235bb609c18547cf6b215bad1f9d2ec56ad371)
Signed-off-by: Michael Roth <address@hidden>
Commit: 535b8d00c14f36e9323ae082331414ab5ee15e5c
https://github.com/qemu/qemu/commit/535b8d00c14f36e9323ae082331414ab5ee15e5c
Author: Michal Privoznik <address@hidden>
Date: 2019-10-03 (Thu, 03 Oct 2019)
Changed paths:
M block/nvme.c
Log Message:
-----------
nvme: Set number of queues later in nvme_init()
When creating the admin queue in nvme_init() the variable that
holds the number of queues created is modified before actual
queue creation. This is a problem because if creating the queue
fails then the variable is left in inconsistent state. This was
actually observed when I tried to hotplug a nvme disk. The
control got to nvme_file_open() which called nvme_init() which
failed and thus nvme_close() was called which in turn called
nvme_free_queue_pair() with queue being NULL. This lead to an
instant crash:
#0 0x000055d9507ec211 in nvme_free_queue_pair (bs=0x55d952ddb880, q=0x0) at
block/nvme.c:164
#1 0x000055d9507ee180 in nvme_close (bs=0x55d952ddb880) at block/nvme.c:729
#2 0x000055d9507ee3d5 in nvme_file_open (bs=0x55d952ddb880,
options=0x55d952bb1410, flags=147456, errp=0x7ffd8e19e200) at block/nvme.c:781
#3 0x000055d9507629f3 in bdrv_open_driver (bs=0x55d952ddb880,
drv=0x55d95109c1e0 <bdrv_nvme>, node_name=0x0, options=0x55d952bb1410,
open_flags=147456, errp=0x7ffd8e19e310) at block.c:1291
#4 0x000055d9507633d6 in bdrv_open_common (bs=0x55d952ddb880, file=0x0,
options=0x55d952bb1410, errp=0x7ffd8e19e310) at block.c:1551
#5 0x000055d950766881 in bdrv_open_inherit (filename=0x0, reference=0x0,
options=0x55d952bb1410, flags=32768, parent=0x55d9538ce420,
child_role=0x55d950eaade0 <child_file>, errp=0x7ffd8e19e510) at block.c:3063
#6 0x000055d950765ae4 in bdrv_open_child_bs (filename=0x0,
options=0x55d9541cdff0, bdref_key=0x55d950af33aa "file", parent=0x55d9538ce420,
child_role=0x55d950eaade0 <child_file>, allow_none=true, errp=0x7ffd8e19e510)
at block.c:2712
#7 0x000055d950766633 in bdrv_open_inherit (filename=0x0, reference=0x0,
options=0x55d9541cdff0, flags=0, parent=0x0, child_role=0x0,
errp=0x7ffd8e19e908) at block.c:3011
#8 0x000055d950766dba in bdrv_open (filename=0x0, reference=0x0,
options=0x55d953d00390, flags=0, errp=0x7ffd8e19e908) at block.c:3156
#9 0x000055d9507cb635 in blk_new_open (filename=0x0, reference=0x0,
options=0x55d953d00390, flags=0, errp=0x7ffd8e19e908) at
block/block-backend.c:389
#10 0x000055d950465ec5 in blockdev_init (file=0x0, bs_opts=0x55d953d00390,
errp=0x7ffd8e19e908) at blockdev.c:602
Signed-off-by: Michal Privoznik <address@hidden>
Message-id: address@hidden
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Maxim Levitsky <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 95667c3be0c9f5fc62f58fe845879250f63f7d32)
Signed-off-by: Michael Roth <address@hidden>
Commit: 96389e9061f9394c72fec5dda673918a5eddbcaf
https://github.com/qemu/qemu/commit/96389e9061f9394c72fec5dda673918a5eddbcaf
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2019-10-03 (Thu, 03 Oct 2019)
Changed paths:
M hw/ssi/mss-spi.c
Log Message:
-----------
hw/ssi/mss-spi: Avoid crash when reading empty RX FIFO
Reading the RX_DATA register when the RX_FIFO is empty triggers
an abort. This can be easily reproduced:
$ qemu-system-arm -M emcraft-sf2 -monitor stdio -S
QEMU 4.0.50 monitor - type 'help' for more information
(qemu) x 0x40001010
Aborted (core dumped)
(gdb) bt
#1 0x00007f035874f895 in abort () at /lib64/libc.so.6
#2 0x00005628686591ff in fifo8_pop (fifo=0x56286a9a4c68) at util/fifo8.c:66
#3 0x00005628683e0b8e in fifo32_pop (fifo=0x56286a9a4c68) at
include/qemu/fifo32.h:137
#4 0x00005628683e0efb in spi_read (opaque=0x56286a9a4850, addr=4, size=4) at
hw/ssi/mss-spi.c:168
#5 0x0000562867f96801 in memory_region_read_accessor (mr=0x56286a9a4b60,
addr=16, value=0x7ffeecb0c5c8, size=4, shift=0, mask=4294967295, attrs=...) at
memory.c:439
#6 0x0000562867f96cdb in access_with_adjusted_size (addr=16,
value=0x7ffeecb0c5c8, size=4, access_size_min=1, access_size_max=4,
access_fn=0x562867f967c3 <memory_region_read_accessor>, mr=0x56286a9a4b60,
attrs=...) at memory.c:569
#7 0x0000562867f99940 in memory_region_dispatch_read1 (mr=0x56286a9a4b60,
addr=16, pval=0x7ffeecb0c5c8, size=4, attrs=...) at memory.c:1420
#8 0x0000562867f99a08 in memory_region_dispatch_read (mr=0x56286a9a4b60,
addr=16, pval=0x7ffeecb0c5c8, size=4, attrs=...) at memory.c:1447
#9 0x0000562867f38721 in flatview_read_continue (fv=0x56286aec6360,
addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4,
addr1=16, l=4, mr=0x56286a9a4b60) at exec.c:3385
#10 0x0000562867f38874 in flatview_read (fv=0x56286aec6360, addr=1073745936,
attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4) at exec.c:3423
#11 0x0000562867f388ea in address_space_read_full (as=0x56286aa3e890,
addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4) at
exec.c:3436
#12 0x0000562867f389c5 in address_space_rw (as=0x56286aa3e890,
addr=1073745936, attrs=..., buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4,
is_write=false) at exec.c:3466
#13 0x0000562867f3bdd7 in cpu_memory_rw_debug (cpu=0x56286aa19d00,
addr=1073745936, buf=0x7ffeecb0c7c0 "\340ǰ\354\376\177", len=4, is_write=0) at
exec.c:3976
#14 0x000056286811ed51 in memory_dump (mon=0x56286a8c32d0, count=1,
format=120, wsize=4, addr=1073745936, is_physical=0) at monitor/misc.c:730
#15 0x000056286811eff1 in hmp_memory_dump (mon=0x56286a8c32d0,
qdict=0x56286b15c400) at monitor/misc.c:785
#16 0x00005628684740ee in handle_hmp_command (mon=0x56286a8c32d0,
cmdline=0x56286a8caeb2 "0x40001010") at monitor/hmp.c:1082
>From the datasheet "Actel SmartFusion Microcontroller Subsystem
User's Guide" Rev.1, Table 13-3 "SPI Register Summary", this
register has a reset value of 0.
Check the FIFO is not empty before accessing it, else log an
error message.
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit c0bccee9b40ec58c9d165b406ae3d4f63652ce53)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1e821a0abc8c1b1914f55ffb6a265d381ad4946b
https://github.com/qemu/qemu/commit/1e821a0abc8c1b1914f55ffb6a265d381ad4946b
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2019-10-03 (Thu, 03 Oct 2019)
Changed paths:
M hw/display/xlnx_dp.c
Log Message:
-----------
hw/display/xlnx_dp: Avoid crash when reading empty RX FIFO
In the previous commit we fixed a crash when the guest read a
register that pop from an empty FIFO.
By auditing the repository, we found another similar use with
an easy way to reproduce:
$ qemu-system-aarch64 -M xlnx-zcu102 -monitor stdio -S
QEMU 4.0.50 monitor - type 'help' for more information
(qemu) xp/b 0xfd4a0134
Aborted (core dumped)
(gdb) bt
#0 0x00007f6936dea57f in raise () at /lib64/libc.so.6
#1 0x00007f6936dd4895 in abort () at /lib64/libc.so.6
#2 0x0000561ad32975ec in xlnx_dp_aux_pop_rx_fifo (s=0x7f692babee70) at
hw/display/xlnx_dp.c:431
#3 0x0000561ad3297dc0 in xlnx_dp_read (opaque=0x7f692babee70, offset=77,
size=4) at hw/display/xlnx_dp.c:667
#4 0x0000561ad321b896 in memory_region_read_accessor (mr=0x7f692babf620,
addr=308, value=0x7ffe05c1db88, size=4, shift=0, mask=4294967295, attrs=...) at
memory.c:439
#5 0x0000561ad321bd70 in access_with_adjusted_size (addr=308,
value=0x7ffe05c1db88, size=1, access_size_min=4, access_size_max=4,
access_fn=0x561ad321b858 <memory_region_read_accessor>, mr=0x7f692babf620,
attrs=...) at memory.c:569
#6 0x0000561ad321e9d5 in memory_region_dispatch_read1 (mr=0x7f692babf620,
addr=308, pval=0x7ffe05c1db88, size=1, attrs=...) at memory.c:1420
#7 0x0000561ad321ea9d in memory_region_dispatch_read (mr=0x7f692babf620,
addr=308, pval=0x7ffe05c1db88, size=1, attrs=...) at memory.c:1447
#8 0x0000561ad31bd742 in flatview_read_continue (fv=0x561ad69c04f0,
addr=4249485620, attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177",
len=1, addr1=308, l=1, mr=0x7f692babf620) at exec.c:3385
#9 0x0000561ad31bd895 in flatview_read (fv=0x561ad69c04f0, addr=4249485620,
attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177", len=1) at exec.c:3423
#10 0x0000561ad31bd90b in address_space_read_full (as=0x561ad5bb3020,
addr=4249485620, attrs=..., buf=0x7ffe05c1dcf0 "\020\335\301\005\376\177",
len=1) at exec.c:3436
#11 0x0000561ad33b1c42 in address_space_read (len=1, buf=0x7ffe05c1dcf0
"\020\335\301\005\376\177", attrs=..., addr=4249485620, as=0x561ad5bb3020) at
include/exec/memory.h:2131
#12 0x0000561ad33b1c42 in memory_dump (mon=0x561ad59c4530, count=1,
format=120, wsize=1, addr=4249485620, is_physical=1) at monitor/misc.c:723
#13 0x0000561ad33b1fc1 in hmp_physical_memory_dump (mon=0x561ad59c4530,
qdict=0x561ad6c6fd00) at monitor/misc.c:795
#14 0x0000561ad37b4a9f in handle_hmp_command (mon=0x561ad59c4530,
cmdline=0x561ad59d0f22 "/b 0x00000000fd4a0134") at monitor/hmp.c:1082
Fix by checking the FIFO is not empty before popping from it.
The datasheet is not clear about the reset value of this register,
we choose to return '0'.
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alistair Francis <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit a09ef5040477643a7026703199d8781fe048d3a8)
Signed-off-by: Michael Roth <address@hidden>
Commit: 306ecc0d24bebd724e766c147c28ccd384582b4f
https://github.com/qemu/qemu/commit/306ecc0d24bebd724e766c147c28ccd384582b4f
Author: Li Qiang <address@hidden>
Date: 2019-10-14 (Mon, 14 Oct 2019)
Changed paths:
M hw/nvram/fw_cfg.c
Log Message:
-----------
hw/nvram/fw_cfg: Store 'reboot-timeout' as little endian
The current codebase is not specific about the endianess of the
fw_cfg 'file' entry 'reboot-timeout'.
Per docs/specs/fw_cfg.txt:
=== All Other Data Items ===
Please consult the QEMU source for the most up-to-date
and authoritative list of selector keys and their respective
items' purpose, format and writeability.
Checking the git history, this code was introduced in commit
ac05f3492421, very similar to commit 3d3b8303c6f8 for the
'boot-menu-wait' entry, which explicitely use little-endian.
OVMF consumes 'boot-menu-wait' as little-endian, however it does
not consume 'reboot-timeout'.
Regarding the git history and OVMF use, we choose to explicit
'reboot-timeout' endianess as little-endian.
Signed-off-by: Li Qiang <address@hidden>
Tested-by: Thomas Huth <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
[PMD: Reword commit description based on review comments]
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
(cherry picked from commit 04da973501b591525ce68c2925c61c8886badd4d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 35d6458d6a100b2f15a7e079558a4570742c6e5a
https://github.com/qemu/qemu/commit/35d6458d6a100b2f15a7e079558a4570742c6e5a
Author: Yury Kotov <address@hidden>
Date: 2019-10-14 (Mon, 14 Oct 2019)
Changed paths:
M migration/migration.c
Log Message:
-----------
migration: Fix use-after-free during process exit
It fixes heap-use-after-free which was found by clang's ASAN.
Control flow of this use-after-free:
main_thread:
* Got SIGTERM and completes main loop
* Calls migration_shutdown
- migrate_fd_cancel (so, migration_thread begins to complete)
- object_unref(OBJECT(current_migration));
migration_thread:
* migration_iteration_finish -> schedule cleanup bh
* object_unref(OBJECT(s)); (Now, current_migration is freed)
* exits
main_thread:
* Calls vm_shutdown -> drain bdrvs -> main loop
-> cleanup_bh -> use after free
If you want to reproduce, these couple of sleeps will help:
vl.c:4613:
migration_shutdown();
+ sleep(2);
migration.c:3269:
+ sleep(1);
trace_migration_thread_after_loop();
migration_iteration_finish(s);
Original output:
qemu-system-x86_64: terminating on signal 15 from pid 31980 (<unknown process>)
=================================================================
==31958==ERROR: AddressSanitizer: heap-use-after-free on address 0x61900001d210
at pc 0x555558a535ca bp 0x7fffffffb190 sp 0x7fffffffb188
READ of size 8 at 0x61900001d210 thread T0 (qemu-vm-0)
#0 0x555558a535c9 in migrate_fd_cleanup migration/migration.c:1502:23
#1 0x5555594fde0a in aio_bh_call util/async.c:90:5
#2 0x5555594fe522 in aio_bh_poll util/async.c:118:13
#3 0x555559524783 in aio_poll util/aio-posix.c:725:17
#4 0x555559504fb3 in aio_wait_bh_oneshot util/aio-wait.c:71:5
#5 0x5555573bddf6 in virtio_blk_data_plane_stop
hw/block/dataplane/virtio-blk.c:282:5
#6 0x5555589d5c09 in virtio_bus_stop_ioeventfd hw/virtio/virtio-bus.c:246:9
#7 0x5555589e9917 in virtio_pci_stop_ioeventfd hw/virtio/virtio-pci.c:287:5
#8 0x5555589e22bf in virtio_pci_vmstate_change hw/virtio/virtio-pci.c:1072:9
#9 0x555557628931 in virtio_vmstate_change hw/virtio/virtio.c:2257:9
#10 0x555557c36713 in vm_state_notify vl.c:1605:9
#11 0x55555716ef53 in do_vm_stop cpus.c:1074:9
#12 0x55555716eeff in vm_shutdown cpus.c:1092:12
#13 0x555557c4283e in main vl.c:4617:5
#14 0x7fffdfdb482f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#15 0x555556ecb118 in _start (x86_64-softmmu/qemu-system-x86_64+0x1977118)
0x61900001d210 is located 144 bytes inside of 952-byte region
[0x61900001d180,0x61900001d538)
freed by thread T6 (live_migration) here:
#0 0x555556f76782 in __interceptor_free
/tmp/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:124:3
#1 0x555558d5fa94 in object_finalize qom/object.c:618:9
#2 0x555558d57651 in object_unref qom/object.c:1068:9
#3 0x555558a55588 in migration_thread migration/migration.c:3272:5
#4 0x5555595393f2 in qemu_thread_start util/qemu-thread-posix.c:502:9
#5 0x7fffe057f6b9 in start_thread
(/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
previously allocated by thread T0 (qemu-vm-0) here:
#0 0x555556f76b03 in __interceptor_malloc
/tmp/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:146:3
#1 0x7ffff6ee37b8 in g_malloc
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4f7b8)
#2 0x555558d58031 in object_new qom/object.c:640:12
#3 0x555558a31f21 in migration_object_init migration/migration.c:139:25
#4 0x555557c41398 in main vl.c:4320:5
#5 0x7fffdfdb482f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Thread T6 (live_migration) created by T0 (qemu-vm-0) here:
#0 0x555556f5f0dd in pthread_create
/tmp/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:210:3
#1 0x555559538cf9 in qemu_thread_create util/qemu-thread-posix.c:539:11
#2 0x555558a53304 in migrate_fd_connect migration/migration.c:3332:5
#3 0x555558a72bd8 in migration_channel_connect migration/channel.c:92:5
#4 0x555558a6ef87 in exec_start_outgoing_migration migration/exec.c:42:5
#5 0x555558a4f3c2 in qmp_migrate migration/migration.c:1922:9
#6 0x555558bb4f6a in qmp_marshal_migrate
qapi/qapi-commands-migration.c:607:5
#7 0x555559363738 in do_qmp_dispatch qapi/qmp-dispatch.c:131:5
#8 0x555559362a15 in qmp_dispatch qapi/qmp-dispatch.c:174:11
#9 0x5555571bac15 in monitor_qmp_dispatch monitor.c:4124:11
#10 0x55555719a22d in monitor_qmp_bh_dispatcher monitor.c:4207:9
#11 0x5555594fde0a in aio_bh_call util/async.c:90:5
#12 0x5555594fe522 in aio_bh_poll util/async.c:118:13
#13 0x5555595201e0 in aio_dispatch util/aio-posix.c:460:5
#14 0x555559503553 in aio_ctx_dispatch util/async.c:261:5
#15 0x7ffff6ede196 in g_main_context_dispatch
(/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4a196)
SUMMARY: AddressSanitizer: heap-use-after-free migration/migration.c:1502:23
in migrate_fd_cleanup
Shadow bytes around the buggy address:
0x0c327fffb9f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffba00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffba10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffba20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c327fffba30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c327fffba40: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c327fffba50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c327fffba60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c327fffba70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c327fffba80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x0c327fffba90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==31958==ABORTING
Signed-off-by: Yury Kotov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
Fixed up comment formatting
(cherry picked from commit fd392cfa8e6fb0dc34bd0327fc356dfbf6edf1fd)
Signed-off-by: Michael Roth <address@hidden>
Commit: 6341bef4684e59d87735f6543a8b205b1f34d3a3
https://github.com/qemu/qemu/commit/6341bef4684e59d87735f6543a8b205b1f34d3a3
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2019-10-14 (Mon, 14 Oct 2019)
Changed paths:
M hw/block/dataplane/virtio-blk.c
Log Message:
-----------
virtio-blk: Cancel the pending BH when the dataplane is reset
When 'system_reset' is called, the main loop clear the memory
region cache before the BH has a chance to execute. Later when
the deferred function is called, some assumptions that were
made when scheduling them are no longer true when they actually
execute.
This is what happens using a virtio-blk device (fresh RHEL7.8 install):
$ (sleep 12.3; echo system_reset; sleep 12.3; echo system_reset; sleep 1; echo
q) \
| qemu-system-x86_64 -m 4G -smp 8 -boot menu=on \
-device virtio-blk-pci,id=image1,drive=drive_image1 \
-drive
file=/var/lib/libvirt/images/rhel78.qcow2,if=none,id=drive_image1,format=qcow2,cache=none
\
-device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:84 \
-netdev tap,id=net0,script=/bin/true,downscript=/bin/true,vhost=on \
-monitor stdio -serial null -nographic
(qemu) system_reset
(qemu) system_reset
(qemu) qemu-system-x86_64: hw/virtio/virtio.c:225: vring_get_region_caches:
Assertion `caches != NULL' failed.
Aborted
(gdb) bt
Thread 1 (Thread 0x7f109c17b680 (LWP 10939)):
#0 0x00005604083296d1 in vring_get_region_caches (vq=0x56040a24bdd0) at
hw/virtio/virtio.c:227
#1 0x000056040832972b in vring_avail_flags (vq=0x56040a24bdd0) at
hw/virtio/virtio.c:235
#2 0x000056040832d13d in virtio_should_notify (vdev=0x56040a240630,
vq=0x56040a24bdd0) at hw/virtio/virtio.c:1648
#3 0x000056040832d1f8 in virtio_notify_irqfd (vdev=0x56040a240630,
vq=0x56040a24bdd0) at hw/virtio/virtio.c:1662
#4 0x00005604082d213d in notify_guest_bh (opaque=0x56040a243ec0) at
hw/block/dataplane/virtio-blk.c:75
#5 0x000056040883dc35 in aio_bh_call (bh=0x56040a243f10) at util/async.c:90
#6 0x000056040883dccd in aio_bh_poll (ctx=0x560409161980) at util/async.c:118
#7 0x0000560408842af7 in aio_dispatch (ctx=0x560409161980) at
util/aio-posix.c:460
#8 0x000056040883e068 in aio_ctx_dispatch (source=0x560409161980,
callback=0x0, user_data=0x0) at util/async.c:261
#9 0x00007f10a8fca06d in g_main_context_dispatch () at
/lib64/libglib-2.0.so.0
#10 0x0000560408841445 in glib_pollfds_poll () at util/main-loop.c:215
#11 0x00005604088414bf in os_host_main_loop_wait (timeout=0) at
util/main-loop.c:238
#12 0x00005604088415c4 in main_loop_wait (nonblocking=0) at
util/main-loop.c:514
#13 0x0000560408416b1e in main_loop () at vl.c:1923
#14 0x000056040841e0e8 in main (argc=20, argv=0x7ffc2c3f9c58,
envp=0x7ffc2c3f9d00) at vl.c:4578
Fix this by cancelling the BH when the virtio dataplane is stopped.
[This is version of the patch was modified as discussed with Philippe on
the mailing list thread.
--Stefan]
Reported-by: Yihuang Yu <address@hidden>
Suggested-by: Stefan Hajnoczi <address@hidden>
Fixes: https://bugs.launchpad.net/qemu/+bug/1839428
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit ebb6ff25cd888a52a64a9adc3692541c6d1d9a42)
Signed-off-by: Michael Roth <address@hidden>
Commit: a678cd4d30cce2597340c22d88b486816d93bc76
https://github.com/qemu/qemu/commit/a678cd4d30cce2597340c22d88b486816d93bc76
Author: Paul Durrant <address@hidden>
Date: 2019-10-14 (Mon, 14 Oct 2019)
Changed paths:
M hw/xen/xen-bus.c
Log Message:
-----------
xen-bus: check whether the frontend is active during device reset...
...not the backend
Commit cb323146 "xen-bus: Fix backend state transition on device reset"
contained a subtle mistake. The hunk
@@ -539,11 +556,11 @@ static void xen_device_backend_changed(void *opaque)
/*
* If the toolstack (or unplug request callback) has set the backend
- * state to Closing, but there is no active frontend (i.e. the
- * state is not Connected) then set the backend state to Closed.
+ * state to Closing, but there is no active frontend then set the
+ * backend state to Closed.
*/
if (xendev->backend_state == XenbusStateClosing &&
- xendev->frontend_state != XenbusStateConnected) {
+ !xen_device_state_is_active(state)) {
xen_device_backend_set_state(xendev, XenbusStateClosed);
}
mistakenly replaced the check of 'xendev->frontend_state' with a check
(now in a helper function) of 'state', which actually equates to
'xendev->backend_state'.
This patch fixes the mistake.
Fixes: cb3231460747552d70af9d546dc53d8195bcb796
Signed-off-by: Paul Durrant <address@hidden>
Reviewed-by: Anthony PERARD <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Anthony PERARD <address@hidden>
(cherry picked from commit df6180bb56cd03949c2c64083da58755fed81a61)
Signed-off-by: Michael Roth <address@hidden>
Commit: 23967e5b2a6c6d04b8db766a8a149f3631a7b899
https://github.com/qemu/qemu/commit/23967e5b2a6c6d04b8db766a8a149f3631a7b899
Author: Michael Roth <address@hidden>
Date: 2019-10-17 (Thu, 17 Oct 2019)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 4.0.1 release
Signed-off-by: Michael Roth <address@hidden>
Compare: https://github.com/qemu/qemu/compare/5669ef1e6c40%5E...23967e5b2a6c
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 5669ef: qcow2: Avoid COW during metadata preallocation,
Michael Roth <=