[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 27dd31: qga-win: Enable 'can-offline' field i
|
From: |
GitHub |
|
Subject: |
[Qemu-commits] [qemu/qemu] 27dd31: qga-win: Enable 'can-offline' field in 'guest-get-... |
|
Date: |
Thu, 07 Sep 2017 12:11:01 -0700 |
Branch: refs/heads/stable-2.9
Home: https://github.com/qemu/qemu
Commit: 27dd31f164044532bea38cc2c0711ed08e2b044f
https://github.com/qemu/qemu/commit/27dd31f164044532bea38cc2c0711ed08e2b044f
Author: Sameeh Jubran <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M qga/commands-win32.c
Log Message:
-----------
qga-win: Enable 'can-offline' field in 'guest-get-vcpus' reply
The QGA schema states:
@can-offline: Whether offlining the VCPU is possible. This member
is always filled in by the guest agent when the structure
is returned, and always ignored on input (hence it can be
omitted then).
Currently 'can-offline' is missing entirely from the reply. This causes
errors in libvirt which is expecting the reply to be compliant with the
schema docs.
BZ#1438735: https://bugzilla.redhat.com/show_bug.cgi?id=1438735
Signed-off-by: Sameeh Jubran <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Cc: address@hidden
Signed-off-by: Michael Roth <address@hidden>
(cherry picked from commit 54858553def1879a3b0781529fb12a028ba36713)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4aa16db9cf4219c0bb4fa0291349eb5d26c34a06
https://github.com/qemu/qemu/commit/4aa16db9cf4219c0bb4fa0291349eb5d26c34a06
Author: Eric Blake <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M block/dirty-bitmap.c
Log Message:
-----------
dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented
We've been documenting the value in bytes since its introduction
in commit b9a9b3a4 (v1.3), where it was actually reported in bytes.
Commit e4654d2 (v2.0) then removed things from block/qapi.c, in
preparation for a rewrite to a list of dirty sectors in the next
commit 21b5683 in block.c, but the new code mistakenly started
reporting in sectors.
Fixes: https://bugzilla.redhat.com/1441460
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 6c98c57af3f4fab85bdf5f01616c91322bd4312a)
Signed-off-by: Michael Roth <address@hidden>
Commit: c37a62b751647927ec8d09fd885cf4f36f81255c
https://github.com/qemu/qemu/commit/c37a62b751647927ec8d09fd885cf4f36f81255c
Author: Max Reitz <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M qemu-img.c
Log Message:
-----------
qemu-img/convert: Always set ret < 0 on error
Otherwise the qemu-img process will exit with EXIT_SUCCESS instead of
EXIT_FAILURE.
Cc: qemu-stable <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
* applied directly to stable, upstream code has issue fixed via a
refactoring introduced by 9fd77f9, which isn't targetted for stable
Signed-off-by: Michael Roth <address@hidden>
Commit: a1c850fd9d491594b39b23dace01b1fb3ca83236
https://github.com/qemu/qemu/commit/a1c850fd9d491594b39b23dace01b1fb3ca83236
Author: Max Reitz <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M qemu-img.c
Log Message:
-----------
qemu-img/convert: Use @opts for one thing only
After storing the creation options for the new image into @opts, we
fetch some things for our own information, like the backing file name,
or whether to use encryption or preallocation.
With the -n parameter, there will not be any creation options; this is
not too bad because this just means that querying a NULL @opts will
always return the default value.
However, we also use @opts for the --object options. Therefore, @opts is
not necessarily NULL if -n was specified; instead, it may contain those
options. In practice, this probably does not cause any problems because
there most likely is no object that supports any of the parameters we
query here, but this is neither something we should rely on nor does
this variable reuse make the code very nice to read.
Therefore, just use an own variable for the --object options.
Cc: qemu-stable <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
* applied patch from v1 of series as suggested by author
Signed-off-by: Michael Roth <address@hidden>
Commit: bc70597a487a3bb8585c155a43d09dcff5e4ffd2
https://github.com/qemu/qemu/commit/bc70597a487a3bb8585c155a43d09dcff5e4ffd2
Author: Max Reitz <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M qemu-img.c
M tests/qemu-iotests/122.out
Log Message:
-----------
qemu-img/convert: Move bs_n > 1 && -B check down
It does not make much sense to use a backing image for the target when
you concatenate multiple images (because then there is no correspondence
between the source images' backing files and the target's); but it was
still possible to give one by using -o backing_file=X instead of -B X.
Fix this by moving the check.
(Also, change the error message because -B is not the only way to
specify the backing file, evidently.)
Cc: qemu-stable <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
* applied patch from v1 of series as suggested by author
Signed-off-by: Michael Roth <address@hidden>
Commit: bd1039b4639a9db4a292a9478f914932b2d54ffa
https://github.com/qemu/qemu/commit/bd1039b4639a9db4a292a9478f914932b2d54ffa
Author: Max Reitz <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M block.c
Log Message:
-----------
block: An empty filename counts as no filename
Reproducer:
$ ./qemu-img info ''
qemu-img: ./block.c:1008: bdrv_open_driver: Assertion
`!drv->bdrv_needs_filename || bs->filename[0]' failed.
[1] 26105 abort (core dumped) ./qemu-img info ''
This patch fixes this to be:
$ ./qemu-img info ''
qemu-img: Could not open '': The 'file' block driver requires a file
name
Cc: qemu-stable <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 4a0082401a770261b85625a41eef4a4e89ad7a74)
Signed-off-by: Michael Roth <address@hidden>
Commit: b8420f7102fe3ae3a796d828aecb4dacee781c9d
https://github.com/qemu/qemu/commit/b8420f7102fe3ae3a796d828aecb4dacee781c9d
Author: Max Reitz <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M tests/qemu-iotests/051
M tests/qemu-iotests/051.out
M tests/qemu-iotests/051.pc.out
Log Message:
-----------
iotests/051: Add test for empty filename
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 42dc10f17a7f1754d419e715114c37f5c5fde12f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 181e005f14aebfba80e5703c770c18531f0c73a4
https://github.com/qemu/qemu/commit/181e005f14aebfba80e5703c770c18531f0c73a4
Author: Daniel P. Berrange <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M migration/exec.c
Log Message:
-----------
migration: setup bi-directional I/O channel for exec: protocol
Historically the migration data channel has only needed to be
unidirectional. Thus the 'exec:' protocol was requesting an
I/O channel with O_RDONLY on incoming side, and O_WRONLY on
the outgoing side.
This is fine for classic migration, but if you then try to run
TLS over it, this fails because the TLS handshake requires a
bi-directional channel.
Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Signed-off-by: Juan Quintela <address@hidden>
(cherry picked from commit 062d81f0e968fe1597474735f3ea038065027372)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0b906e4d0ab270afda5de71977a84801e1ffac1d
https://github.com/qemu/qemu/commit/0b906e4d0ab270afda5de71977a84801e1ffac1d
Author: Herongguang (Stephen) <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M hw/pci/pci.c
Log Message:
-----------
pci: deassert intx when pci device unrealize
If a pci device is not reset by VM (by writing into config space)
and unplugged by VM, after that when VM reboots, qemu may assert:
pcibus_reset: Assertion `bus->irq_count[i] == 0' failed
Cc: address@hidden
Signed-off-by: herongguang <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 3936161f1fd72d1dfa577aaba910819c5e873260)
Signed-off-by: Michael Roth <address@hidden>
Commit: c1059a3a3cb80bc087ad7e33fced4f8a7a9c0150
https://github.com/qemu/qemu/commit/c1059a3a3cb80bc087ad7e33fced4f8a7a9c0150
Author: Max Reitz <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M block/blkdebug.c
M block/blkreplay.c
M block/blkverify.c
Log Message:
-----------
block: Do not unref bs->file on error in BD's open
The block layer takes care of removing the bs->file child if the block
driver's bdrv_open()/bdrv_file_open() implementation fails. The block
driver therefore does not need to do so, and indeed should not unless it
sets bs->file to NULL afterwards -- because if this is not done, the
bdrv_unref_child() in bdrv_open_inherit() will dereference the freed
memory block at bs->file afterwards, which is not good.
We can now decide whether to add a "bs->file = NULL;" after each of the
offending bdrv_unref_child() invocations, or just drop them altogether.
The latter is simpler, so let's do that.
Cc: qemu-stable <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit de234897b60e034ba94b307fc289e2dc692c9251)
Signed-off-by: Michael Roth <address@hidden>
Commit: c64d184584a0d0fdfd0c9669cf9d603491663b9c
https://github.com/qemu/qemu/commit/c64d184584a0d0fdfd0c9669cf9d603491663b9c
Author: Bruce Rogers <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M hw/acpi/piix4.c
Log Message:
-----------
ACPI: don't call acpi_pcihp_device_plug_cb on xen
Commit f0c9d64a exposed the issue that with a xenfv machine using
pci passthrough, acpi pci hotplug code was being executed by mistake.
Guard calls to acpi_pcihp_device_plug_cb (and corresponding
acpi_pcihp_device_unplug_cb) with a check for xen_enabled(). Without
this check I am seeing an error that the bus doesn't have the
acpi-pcihp-bsel property set.
Signed-off-by: Bruce Rogers <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 153eba4726dfa1bdfc31d1fe973b2a61b9035492)
Signed-off-by: Michael Roth <address@hidden>
Commit: 45b3eac7527d01c47f3474f47cf3add2f28bd6c8
https://github.com/qemu/qemu/commit/45b3eac7527d01c47f3474f47cf3add2f28bd6c8
Author: Markus Armbruster <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M migration/colo.c
M monitor.c
Log Message:
-----------
replication: Make --disable-replication compile again
Broken in commit daa33c5.
Cc: address@hidden
Signed-off-by: Markus Armbruster <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Zhang Chen <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit 38bb54f323bf7c83496b6a044cfd28896e997a00)
Signed-off-by: Michael Roth <address@hidden>
Commit: 785d9ab216c70e4fd4710e3127acda888756ef71
https://github.com/qemu/qemu/commit/785d9ab216c70e4fd4710e3127acda888756ef71
Author: Greg Kurz <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M hw/9pfs/9p-local.c
Log Message:
-----------
9pfs: local: fix unlink of alien files in mapped-file mode
When trying to remove a file from a directory, both created in non-mapped
mode, the file remains and EBADF is returned to the guest.
This is a regression introduced by commit "df4938a6651b 9pfs: local:
unlinkat: don't follow symlinks" when fixing CVE-2016-9602. It changed the
way we unlink the metadata file from
ret = remove("$dir/.virtfs_metadata/$name");
if (ret < 0 && errno != ENOENT) {
/* Error out */
}
/* Ignore absence of metadata */
to
fd = openat("$dir/.virtfs_metadata")
unlinkat(fd, "$name")
if (ret < 0 && errno != ENOENT) {
/* Error out */
}
/* Ignore absence of metadata */
If $dir was created in non-mapped mode, openat() fails with ENOENT and
we pass -1 to unlinkat(), which fails in turn with EBADF.
We just need to check the return of openat() and ignore ENOENT, in order
to restore the behaviour we had with remove().
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
[groug: rewrote the comments as suggested by Eric]
(cherry picked from commit 6a87e7929f97b86c5823d4616fa1aa7636b2f116)
Signed-off-by: Michael Roth <address@hidden>
Commit: 21047240d01ac8a8b90f65b8bc41b289ee3ba6ff
https://github.com/qemu/qemu/commit/21047240d01ac8a8b90f65b8bc41b289ee3ba6ff
Author: Eric Blake <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M MAINTAINERS
A scripts/coccinelle/qobject.cocci
Log Message:
-----------
coccinelle: Add script to remove useless QObject casts
We have macros in place to make it less verbose to add a subtype
of QObject to both QDict and QList. While we have made cleanups
like this in the past (see commit fcfcd8ffc, for example), having
it be automated by Coccinelle makes it easier to maintain.
The script is separate from the cleanups, for ease of review and
backporting. A later patch will then add further possible cleanups.
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>
(cherry picked from commit a2f3453ebc64b1ebe094aeaf83f9e67896f90ac3)
Signed-off-by: Michael Roth <address@hidden>
Commit: 3f308bf3acc724d50ffa3f280f75f4c7b5bb6003
https://github.com/qemu/qemu/commit/3f308bf3acc724d50ffa3f280f75f4c7b5bb6003
Author: Eric Blake <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M block.c
M block/blkdebug.c
M block/blkverify.c
M block/file-posix.c
M block/file-win32.c
M block/quorum.c
M tests/check-qdict.c
M tests/test-qmp-commands.c
Log Message:
-----------
qobject: Drop useless QObject casts
We have macros in place to make it less verbose to add a subtype
of QObject to both QDict and QList. While we have made cleanups
like this in the past (see commit fcfcd8ffc, for example), having
it be automated by Coccinelle makes it easier to maintain.
Patch created mechanically via:
spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-file scripts/cocci-macro-file.h --dir . --in-place
then I verified that no manual touchups were required.
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Alberto Garcia <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>
(cherry picked from commit de6e7951fe66053dfeaac1a237f7aceb9e079619)
Signed-off-by: Michael Roth <address@hidden>
Commit: 396474a18c63ef2d198955beab1bacb476b2d4d7
https://github.com/qemu/qemu/commit/396474a18c63ef2d198955beab1bacb476b2d4d7
Author: Eric Blake <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M include/qapi/qmp/qdict.h
M include/qapi/qmp/qlist.h
M scripts/coccinelle/qobject.cocci
Log Message:
-----------
qobject: Add helper macros for common scalar insertions
Rather than making lots of callers wrap a scalar in a QInt, QString,
or QBool, provide helper macros that do the wrapping automatically.
Update the Coccinelle script to make mass conversions easy, although
the conversion itself will be done as a separate patches to ease
review and backport efforts.
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>
(cherry picked from commit a92c21591b5bb9543996538f14854ca6b528318b)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1eaf431077759ed1013a199e913de711ceeb4087
https://github.com/qemu/qemu/commit/1eaf431077759ed1013a199e913de711ceeb4087
Author: Eric Blake <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M target/s390x/cpu_models.c
Log Message:
-----------
s390x: Drop useless casts
An upcoming Coccinelle cleanup script wanted to reformat the casts
present in this file - but on closer look, we don't need the casts
at all because C automatically converts void* to any other pointer.
Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit cb55c19a26d6928b445f1bd9394843c9eb60f8ab)
* prereq for 46f5ac2
Signed-off-by: Michael Roth <address@hidden>
Commit: e59084b5b2daa22427d3dc4e1fd241f69910615e
https://github.com/qemu/qemu/commit/e59084b5b2daa22427d3dc4e1fd241f69910615e
Author: Eric Blake <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M block.c
M block/blkdebug.c
M block/blkverify.c
M block/curl.c
M block/file-posix.c
M block/file-win32.c
M block/nbd.c
M block/nfs.c
M block/null.c
M block/qcow2.c
M block/quorum.c
M block/rbd.c
M block/snapshot.c
M block/ssh.c
M block/vvfat.c
M blockdev.c
M hw/block/xen_disk.c
M hw/usb/xen-usb.c
M monitor.c
M qapi/qmp-event.c
M qemu-img.c
M qemu-io.c
M qemu-nbd.c
M qobject/qdict.c
M target/s390x/cpu_models.c
M tests/check-qdict.c
M tests/check-qlist.c
M tests/device-introspect-test.c
M tests/test-qemu-opts.c
M tests/test-qmp-commands.c
M tests/test-qmp-event.c
M tests/test-qobject-output-visitor.c
M util/qemu-option.c
Log Message:
-----------
qobject: Use simpler QDict/QList scalar insertion macros
We now have macros in place to make it less verbose to add a scalar
to QDict and QList, so use them.
Patch created mechanically via:
spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-file scripts/cocci-macro-file.h --dir . --in-place
then touched up manually to fix a couple of '?:' back to original
spacing, as well as avoiding a long line in monitor.c.
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Alberto Garcia <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>
(cherry picked from commit 46f5ac205a9dc5e2c24274c7df371509a286281f)
* prereq for fc0932f
Signed-off-by: Michael Roth <address@hidden>
Commit: d2fcb92b18f735b7ea623ea649f3aedcacf48677
https://github.com/qemu/qemu/commit/d2fcb92b18f735b7ea623ea649f3aedcacf48677
Author: Fam Zheng <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M blockdev.c
Log Message:
-----------
block: Reuse bs as backing hd for drive-backup sync=none
Opening the backing image for the second time is bad, especially here
when it is also in use as the active image as the source. The
drive-backup job itself doesn't read from target->backing for COW,
instead it gets data from the write notifier, so it's not a big problem.
However, exporting the target to NBD etc. won't work, because of the
likely stale metadata cache.
Use BDRV_O_NO_BACKING in this case and manually set up the backing
BdrvChild.
Cc: address@hidden
Signed-off-by: Fam Zheng <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit fc0932fdcfc3e5cafa3641e361b681c07f639812)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0e727a207e2be29e5d6587cca4e2faef37c5dade
https://github.com/qemu/qemu/commit/0e727a207e2be29e5d6587cca4e2faef37c5dade
Author: Zhiyong Yang <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M hw/virtio/vhost-user.c
Log Message:
-----------
hw/virtio: fix vhost user fails to startup when MQ
Qemu2.7~2.9 and vhost user for dpdk 17.02 release work together
to cause failures of new connection when negotiating to set MQ.
(one queue pair works well).
Because there exist some bugs in qemu code when introducing
VHOST_USER_PROTOCOL_F_REPLY_ACK to qemu. When vhost_user_set_mem_table
is invoked to deal with the vhost message VHOST_USER_SET_MEM_TABLE
for the second time, qemu indeed doesn't send the messge (The message
needs to be sent only once)but still will be waiting for dpdk's reply
ack, then, qemu is always freezing, while DPDK is always waiting for
next vhost message from qemu.
The patch aims to fix the bug, MQ can work well.
The same bug is found in function vhost_user_net_set_mtu, it is fixed
at the same time.
DPDK related patch is as following:
http://www.dpdk.org/dev/patchwork/patch/23955/
Signed-off-by: Zhiyong Yang <address@hidden>
Cc: address@hidden
Fixes: ca525ce5618b ("vhost-user: Introduce a new protocol feature REPLY_ACK.")
Reviewed-by: Maxime Coquelin <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Tested-by: Jens Freimann <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
(cherry picked from commit 60cd11024f41cc73175e651a2dfe09a3cade56bb)
Signed-off-by: Michael Roth <address@hidden>
Commit: ce119247a175baea72acd915b55f01f46003392b
https://github.com/qemu/qemu/commit/ce119247a175baea72acd915b55f01f46003392b
Author: Stefan Hajnoczi <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M include/block/aio.h
Log Message:
-----------
aio: add missing aio_notify() to aio_enable_external()
The main loop uses aio_disable_external()/aio_enable_external() to
temporarily disable processing of external AioContext clients like
device emulation.
This allows monitor commands to quiesce I/O and prevent the guest from
submitting new requests while a monitor command is in progress.
The aio_enable_external() API is currently broken when an IOThread is in
aio_poll() waiting for fd activity when the main loop re-enables
external clients. Incrementing ctx->external_disable_cnt does not wake
the IOThread from ppoll(2) so fd processing remains suspended and leads
to unresponsive emulated devices.
This patch adds an aio_notify() call to aio_enable_external() so the
IOThread is kicked out of ppoll(2) and will re-arm the file descriptors.
The bug can be reproduced as follows:
$ qemu -M accel=kvm -m 1024 \
-object iothread,id=iothread0 \
-device virtio-scsi-pci,iothread=iothread0,id=virtio-scsi-pci0 \
-drive if=none,id=drive0,aio=native,cache=none,format=raw,file=test.img \
-device scsi-hd,id=scsi-hd0,drive=drive0 \
-qmp tcp::5555,server,nowait
$ scripts/qmp/qmp-shell localhost:5555
(qemu) blockdev-snapshot-sync device=drive0 snapshot-file=sn1.qcow2
mode=absolute-paths format=qcow2
After blockdev-snapshot-sync completes the SCSI disk will be
unresponsive. This leads to request timeouts inside the guest.
Reported-by: Qianqian Zhu <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
Message-id: address@hidden
Suggested-by: Fam Zheng <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit 321d1dba8bef9676a77e9399484e3cd8bf2cf16a)
Signed-off-by: Michael Roth <address@hidden>
Commit: d8cddcc2b9c741896ae2216a60859c75fe223756
https://github.com/qemu/qemu/commit/d8cddcc2b9c741896ae2216a60859c75fe223756
Author: Anton Nefedov <address@hidden>
Date: 2017-07-31 (Mon, 31 Jul 2017)
Changed paths:
M qemu-img.c
Log Message:
-----------
qemu-img: wait for convert coroutines to complete
On error path (like i/o error in one of the coroutines), it's required to
- wait for coroutines completion before cleaning the common structures
- reenter dependent coroutines so they ever finish
Introduced in 2d9187bc65.
Cc: address@hidden
Signed-off-by: Anton Nefedov <address@hidden>
Reviewed-by: Peter Lieven <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit b91127edd0ff96f27f1e58e47f4e9f9d6a0fed02)
Signed-off-by: Michael Roth <address@hidden>
Commit: 73aa7ad7d2249a602a93b6c2a8ecbd57bacbc482
https://github.com/qemu/qemu/commit/73aa7ad7d2249a602a93b6c2a8ecbd57bacbc482
Author: Max Reitz <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/vhdx.c
Log Message:
-----------
block/vhdx: Make vhdx_create() always set errp
This patch makes vhdx_create() always set errp in case of an error. It
also adds errp parameters to vhdx_create_bat() and
vhdx_create_new_region_table() so we can pass on the error object
generated by blk_truncate() as of a future commit.
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
Message-id: address@hidden
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 55b9392b98e500399f2da1edc1d110bbfd40fb05)
* prereq for 698bdfa
Signed-off-by: Michael Roth <address@hidden>
Commit: 5797a36abd2069232c39c7acd57a34220fe11d21
https://github.com/qemu/qemu/commit/5797a36abd2069232c39c7acd57a34220fe11d21
Author: Max Reitz <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block.c
M block/blkdebug.c
M block/block-backend.c
M block/commit.c
M block/crypto.c
M block/mirror.c
M block/parallels.c
M block/qcow.c
M block/qcow2-refcount.c
M block/qcow2.c
M block/qed.c
M block/raw-format.c
M block/vdi.c
M block/vhdx-log.c
M block/vhdx.c
M block/vmdk.c
M block/vpc.c
M blockdev.c
M include/block/block.h
M include/sysemu/block-backend.h
M qemu-img.c
M qemu-io-cmds.c
Log Message:
-----------
block: Add errp to b{lk,drv}_truncate()
For one thing, this allows us to drop the error message generation from
qemu-img.c and blockdev.c and instead have it unified in
bdrv_truncate().
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit ed3d2ec98a33fbdeabc471b11ff807075f07e996)
* prereq for 698bdfa
Signed-off-by: Michael Roth <address@hidden>
Commit: af8ca55a6b74f9907c33c72412ef7cb0fb256fc3
https://github.com/qemu/qemu/commit/af8ca55a6b74f9907c33c72412ef7cb0fb256fc3
Author: John Snow <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M blockdev.c
Log Message:
-----------
blockdev: use drained_begin/end for qmp_block_resize
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1447551
If one tries to issue a block_resize while a guest is busy
accessing the disk, it is possible that qemu may deadlock
when invoking aio_poll from both the main loop and the iothread.
Replace another instance of bdrv_drain_all that doesn't
quite belong.
Cc: address@hidden
Suggested-by: Paolo Bonzini <address@hidden>
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 698bdfa07d66b5ec218a60229e58eae1dcde00e5)
Signed-off-by: Michael Roth <address@hidden>
Commit: e4422534796c98fe4e1b8bbef127b5eb009ac697
https://github.com/qemu/qemu/commit/e4422534796c98fe4e1b8bbef127b5eb009ac697
Author: Max Filippov <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M target/xtensa/xtensa-semi.c
Log Message:
-----------
target/xtensa: fix mapping direction in read/write simcalls
Read and write simcalls map physical memory to access I/O buffers, but
'read' simcall need to map it for writing and 'write' simcall need to
map it for reading, i.e. the opposite of what they do now. Fix that.
Cc: address@hidden
Signed-off-by: Max Filippov <address@hidden>
(cherry picked from commit 30c2afd151cbc38c012f7b441088980807183da6)
Signed-off-by: Michael Roth <address@hidden>
Commit: d81db0becaeca093a55f3dba110c55528ad5c3bc
https://github.com/qemu/qemu/commit/d81db0becaeca093a55f3dba110c55528ad5c3bc
Author: Max Filippov <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M target/xtensa/xtensa-semi.c
Log Message:
-----------
target/xtensa: fix return value of read/write simcalls
Return value of read/write simcalls is not calculated correctly in case
of operations crossing page boundary and in case of short reads/writes.
Read and write simcalls should return the size of data actually
read/written or -1 in case of error.
Cc: address@hidden
Signed-off-by: Max Filippov <address@hidden>
(cherry picked from commit 347ec03093f9668a379ef6b7fa1feb332fff039c)
Signed-off-by: Michael Roth <address@hidden>
Commit: f00c08cbac63f452cc0828f60345a62cc175daa2
https://github.com/qemu/qemu/commit/f00c08cbac63f452cc0828f60345a62cc175daa2
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: strengthen assertion in curl_clean_state
curl_clean_state should only be called after all AIOCBs have been
completed. This is not so obvious for the call from curl_detach_aio_context,
so assert that.
Cc: address@hidden
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit 675a775633e68bf8b426a896fea5b93a4f4ff1cc)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4b519b9fd7c5e3d0107243ff776c0b5086ff2f4f
https://github.com/qemu/qemu/commit/4b519b9fd7c5e3d0107243ff776c0b5086ff2f4f
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: never invoke callbacks with s->mutex held
All curl callbacks go through curl_multi_do, and hence are called with
s->mutex held. Note that with comments, and make curl_read_cb drop the
lock before invoking the callback.
Likewise for curl_find_buf, where the callback can be invoked by the
caller.
Cc: address@hidden
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit 34db05e7ffe8d61ca7288b9532ad6e8300853318)
Signed-off-by: Michael Roth <address@hidden>
Commit: c79bef68c46cfb04d856516dcc5f828842f2907b
https://github.com/qemu/qemu/commit/c79bef68c46cfb04d856516dcc5f828842f2907b
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/curl.c
Log Message:
-----------
curl: avoid recursive locking of BDRVCURLState mutex
The curl driver has a ugly hack where, if it cannot find an empty CURLState,
it just uses aio_poll to wait for one to be empty. This is probably
buggy when used together with dataplane, and the simplest way to fix it
is to use coroutines instead.
A more immediate effect of the bug however is that it can cause a
recursive call to curl_readv_bh_cb and recursively taking the
BDRVCURLState mutex. This causes a deadlock.
The fix is to unlock the mutex around aio_poll, but for cleanliness we
should also take the mutex around all calls to curl_init_state, even if
reaching the unlock/lock pair is impossible. The same is true for
curl_clean_state.
Reported-by: Kun Wei <address@hidden>
Tested-by: Richard W.M. Jones <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Cc: address@hidden
Cc: Jeff Cody <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit 456af346297ebef86aa097b3609534d34f3d2f75)
Signed-off-by: Michael Roth <address@hidden>
Commit: c60a8ed89bcbccc48f4c9bd1088c0295019dec96
https://github.com/qemu/qemu/commit/c60a8ed89bcbccc48f4c9bd1088c0295019dec96
Author: Alberto Garcia <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/stream.c
Log Message:
-----------
stream: fix crash in stream_start() when block_job_create() fails
The code that tries to reopen a BlockDriverState in stream_start()
when the creation of a new block job fails crashes because it attempts
to dereference a pointer that is known to be NULL.
This is a regression introduced in a170a91fd3eab6155da39e740381867e,
likely because the code was copied from stream_complete().
Cc: address@hidden
Reported-by: Kashyap Chamarthy <address@hidden>
Signed-off-by: Alberto Garcia <address@hidden>
Tested-by: Kashyap Chamarthy <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 525989a50a70ea0ffa2b1cdf56279765bb2b7de0)
Signed-off-by: Michael Roth <address@hidden>
Commit: 636eacb641ce747cbc87c0c878d807cc09b4f905
https://github.com/qemu/qemu/commit/636eacb641ce747cbc87c0c878d807cc09b4f905
Author: Hervé Poussineau <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/vvfat.c
Log Message:
-----------
vvfat: fix qemu-img map and qemu-img convert
- bs->total_sectors is the number of sectors of the whole disk
- s->sector_count is the number of sectors of the FAT partition
This fixes the following assert in qemu-img map:
qemu-img.c:2641: get_block_status: Assertion `nb_sectors' failed.
This also fixes an infinite loop in qemu-img convert.
Fixes: 4480e0f924a42e1db8b8cfcac4d0634dd1bb27a0
Fixes: https://bugs.launchpad.net/qemu/+bug/1599539
Cc: address@hidden
Signed-off-by: Hervé Poussineau <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 139921aaa77c435104308ad53b631a00c3b65ae8)
Signed-off-by: Michael Roth <address@hidden>
Commit: c6b510d1e57cd4d3861955d8c989a67e739ae539
https://github.com/qemu/qemu/commit/c6b510d1e57cd4d3861955d8c989a67e739ae539
Author: Greg Kurz <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: allow broken device to notify guest
According to section 2.1.2 of the virtio-1 specification:
"The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state that
a reset is needed. If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET,
the device MUST send a device configuration change notification to the
driver."
Commit "f5ed36635d8f virtio: stop virtqueue processing if device is broken"
introduced a virtio_error() call that just does that:
- internally mark the device as broken
- set the DEVICE_NEEDS_RESET bit in the status
- send a configuration change notification
Unfortunately, virtio_notify_vector(), called by virtio_notify_config(),
returns right away when the device is marked as broken and the notification
isn't sent in this case.
The spec doesn't say whether a broken device can send notifications
in other situations or not. But since the driver isn't supposed to do
anything but to reset the device, it makes sense to keep the check in
virtio_notify_config().
Marking the device as broken AFTER the configuration change notification was
sent is enough to fix the issue.
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit 66453cff9e5e75344c601cd7674c8ef5fefee8a6)
Signed-off-by: Michael Roth <address@hidden>
Commit: 952cc382044af1f74cdae4256036ba121d75f528
https://github.com/qemu/qemu/commit/952cc382044af1f74cdae4256036ba121d75f528
Author: Fam Zheng <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M hw/scsi/virtio-scsi.c
Log Message:
-----------
virtio-scsi: Unset hotplug handler when unrealize
This matches the qbus_set_hotplug_handler in realize, and it releases
the final reference to the embedded VirtIODevice so that it is
properly finalized.
A use-after-free is fixed with this patch, indirectly:
virtio_device_instance_finalize wasn't called at hot-unplug, and the
vdev->listener would be a dangling pointer in the global and the per
address space listener list. See also RHBZ 1449031.
Cc: address@hidden
Signed-off-by: Fam Zheng <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 2cbe2de5454cf9af44b620b2b40d56361a12a45f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4921c573c81365f87be8fc5a5a0e4068914f0eb9
https://github.com/qemu/qemu/commit/4921c573c81365f87be8fc5a5a0e4068914f0eb9
Author: Sameeh Jubran <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M hw/net/e1000e_core.c
Log Message:
-----------
e1000e: Fix ICR "Other" causes clear logic
This commit fixes a bug which causes the guest to hang. The bug was
observed upon a "receive overrun" (bit #6 of the ICR register)
interrupt which could be triggered post migration in a heavy traffic
environment. Even though the "receive overrun" bit (#6) is masked out
by the IMS register (refer to the log below) the driver still receives
an interrupt as the "receive overrun" bit (#6) causes the "Other" -
bit #24 of the ICR register - bit to be set as documented below. The
driver handles the interrupt and clears the "Other" bit (#24) but
doesn't clear the "receive overrun" bit (#6) which leads to an
infinite loop. Apparently the Windows driver expects that the "receive
overrun" bit and other ones - documented below - to be cleared when
the "Other" bit (#24) is cleared.
So to sum that up:
1. Bit #6 of the ICR register is set by heavy traffic
2. As a results of setting bit #6, bit #24 is set
3. The driver receives an interrupt for bit 24 (it doesn't receieve an
interrupt for bit #6 as it is masked out by IMS)
4. The driver handles and clears the interrupt of bit #24
5. Bit #6 is still set.
6. 2 happens all over again
The Interrupt Cause Read - ICR register:
The ICR has the "Other" bit - bit #24 - that is set when one or more
of the following ICR register's bits are set:
LSC - bit #2, RXO - bit #6, MDAC - bit #9, SRPD - bit #16, ACK - bit
#17, MNG - bit #18
This bug can occur with any of these bits depending on the driver's
behaviour and the way it configures the device. However, trying to
reproduce it with any bit other than RX0 is challenging and came to
failure as the drivers don't implement most of these bits, trying to
reproduce it with LSC (Link Status Change - bit #2) bit didn't succeed
too as it seems that Windows handles this bit differently.
Log sample of the storm:
address@hidden:e1000e_irq_pending_interrupts ICR PENDING: 0x1000000 (ICR:
0x815000c2, IMS: 0x1a00004)
address@hidden:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2,
IMS: 0xa00004)
address@hidden:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2,
IMS: 0xa00004)
address@hidden:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2,
IMS: 0xa00004)
address@hidden:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2,
IMS: 0xa00004)
address@hidden:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2,
IMS: 0xa00004)
address@hidden:e1000e_irq_pending_interrupts ICR PENDING: 0x0 (ICR: 0x815000c2,
IMS: 0xa00004)
address@hidden:e1000e_irq_pending_interrupts ICR PENDING: 0x1000000 (ICR:
0x815000c2, IMS: 0x1a00004)
* This bug behaviour wasn't observed with the Linux driver.
This commit solves:
https://bugzilla.redhat.com/show_bug.cgi?id=1447935
https://bugzilla.redhat.com/show_bug.cgi?id=1449490
Cc: address@hidden
Signed-off-by: Sameeh Jubran <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit 82342e91b60a4a078811df4e1a545e57abffa11d)
Signed-off-by: Michael Roth <address@hidden>
Commit: f3676379cc9f2c803e5e35e1fb7e0ae2041f6f1a
https://github.com/qemu/qemu/commit/f3676379cc9f2c803e5e35e1fb7e0ae2041f6f1a
Author: Halil Pasic <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M hw/s390x/css.c
M hw/s390x/virtio-ccw.c
Log Message:
-----------
s390x/css: catch section mismatch on load
Prior to the virtio-ccw-2.7 machine (and commit 2a79eb1a), our virtio
devices residing under the virtual-css bus do not have qdev_path based
migration stream identifiers (because their qdev_path is NULL). The ids
are instead generated when the device is registered as a composition of
the so called idstr, which takes the vmsd name as its value, and an
instance_id, which is which is calculated as a maximal instance_id
registered with the same idstr plus one, or zero (if none was registered
previously).
That means, under certain circumstances, one device might try, and even
succeed, to load the state of a different device. This can lead to
trouble.
Let us fail the migration if the above problem is detected during load.
How to reproduce the problem:
1) start qemu-system-s390x making sure you have the following devices
defined on your command line:
-device virtio-rng-ccw,id=rng1,devno=fe.0.0001
-device virtio-rng-ccw,id=rng2,devno=fe.0.0002
2) detach the devices and reattach in reverse order using the monitor:
(qemu) device_del rng1
(qemu) device_del rng2
(qemu) device_add virtio-rng-ccw,id=rng2,devno=fe.0.0002
(qemu) device_add virtio-rng-ccw,id=rng1,devno=fe.0.0001
3) save the state of the vm into a temporary file and quit QEMU:
(qemu) migrate "exec:gzip -c > /tmp/tmp_vmstate.gz"
(qemu) q
4) use your command line from step 1 with
-incoming "exec:gzip -c -d /tmp/tmp_vmstate.gz"
appended to reproduce the problem (while trying to to load the saved vm)
CC: address@hidden
Signed-off-by: Halil Pasic <address@hidden>
Reviewed-by: Dong Jia Shi <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>
(cherry picked from commit 8ed179c937830143dc0e03daac30a55272ed89e3)
* removed context dep on d8d98db5
Signed-off-by: Michael Roth <address@hidden>
Commit: 0b185544c98671373a7ea9f2abc1de50a498a722
https://github.com/qemu/qemu/commit/0b185544c98671373a7ea9f2abc1de50a498a722
Author: Yunjian Wang <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
virtio-net: fix wild pointer when remove virtio-net queues
The tx_bh or tx_timer will free in virtio_net_del_queue() function, when
removing virtio-net queues if the guest doesn't support multiqueue. But
it might be still referenced by virtio_net_set_status(), which needs to
be set NULL. And also the tx_waiting needs to be set zero to prevent
virtio_net_set_status() accessing tx_bh or tx_timer.
Cc: address@hidden
Signed-off-by: Yunjian Wang <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit f989c30cf834ba8625e98b808eac30e4e7ec5008)
Signed-off-by: Michael Roth <address@hidden>
Commit: a1a3d603c4484ff06b4338e73713bdea8f298b45
https://github.com/qemu/qemu/commit/a1a3d603c4484ff06b4338e73713bdea8f298b45
Author: Eric Blake <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/blkdebug.c
Log Message:
-----------
blkdebug: Sanity check block layer guarantees
Commits 04ed95f4 and 1a62d0ac updated the block layer to auto-fragment
any I/O to fit within device boundaries. Additionally, when using a
minimum alignment of 4k, we want to ensure the block layer does proper
read-modify-write rather than requesting I/O on a slice of a sector.
Let's enforce that the contract is obeyed when using blkdebug. For
now, blkdebug only allows alignment overrides, and just inherits other
limits from whatever device it is wrapping, but a future patch will
further enhance things.
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit e0ef439588ce1ede747f82b77d893190c1cc9f4d)
* prereq for 81c219a
Signed-off-by: Michael Roth <address@hidden>
Commit: 138cf638bae7b42fe8d616636585050d88568604
https://github.com/qemu/qemu/commit/138cf638bae7b42fe8d616636585050d88568604
Author: Eric Blake <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/blkdebug.c
Log Message:
-----------
blkdebug: Refactor error injection
Rather than repeat the logic at each caller of checking if a Rule
exists that warrants an error injection, fold that logic into
inject_error(); and rename it to rule_check() for legibility.
This will help the next patch, which adds two more callers that
need to check rules for the potential of injecting errors.
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit d157ed5f7235f3d2d5596a514ad7507b18e24b88)
* prereq for 81c219a
Signed-off-by: Michael Roth <address@hidden>
Commit: 577cf9e6bb3af542b2ea691e1a1b367590b0c6a2
https://github.com/qemu/qemu/commit/577cf9e6bb3af542b2ea691e1a1b367590b0c6a2
Author: Eric Blake <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/blkdebug.c
Log Message:
-----------
blkdebug: Add pass-through write_zero and discard support
In order to test the effects of artificial geometry constraints
on operations like write zero or discard, we first need blkdebug
to manage these actions. It also allows us to inject errors on
those operations, just like we can for read/write/flush.
We can also test the contract promised by the block layer; namely,
if a device has specified limits on alignment or maximum size,
then those limits must be obeyed (for now, the blkdebug driver
merely inherits limits from whatever it is wrapping, but the next
patch will further enhance it to allow specific limit overrides).
This patch intentionally refuses to service requests smaller than
the requested alignments; this is because an upcoming patch adds
a qemu-iotest to prove that the block layer is correctly handling
fragmentation, but the test only works if there is a way to tell
the difference at artificial alignment boundaries when blkdebug is
using a larger-than-default alignment. If we let the blkdebug
layer always defer to the underlying layer, which potentially has
a smaller granularity, the iotest will be thwarted.
Tested by setting up an NBD server with export 'foo', then invoking:
$ ./qemu-io
qemu-io> open -o driver=blkdebug blkdebug::nbd://localhost:10809/foo
qemu-io> d 0 15M
qemu-io> w -z 0 15M
Pre-patch, the server never sees the discard (it was silently
eaten by the block layer); post-patch it is passed across the
wire. Likewise, pre-patch the write is always passed with
NBD_WRITE (with 15M of zeroes on the wire), while post-patch
it can utilize NBD_WRITE_ZEROES (for less traffic).
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 63188c245013dbe383e8b031e665f813e2452ea5)
* prereq for 81c219a
Signed-off-by: Michael Roth <address@hidden>
Commit: 3ae74003b55d821a1b3ee92d04cfa18528e0334d
https://github.com/qemu/qemu/commit/3ae74003b55d821a1b3ee92d04cfa18528e0334d
Author: Eric Blake <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/blkdebug.c
Log Message:
-----------
blkdebug: Simplify override logic
Rather than store into a local variable, then copy to the struct
if the value is valid, then reporting errors otherwise, it is
simpler to just store into the struct and report errors if the
value is invalid. This however requires that the struct store
a 64-bit number, rather than a narrower type. Likewise, setting
a sane errno value in ret prior to the sequence of parsing and
jumping to out: on error makes it easier for the next patch to
add a chain of similar checks.
Signed-off-by: Eric Blake <address@hidden>
Message-id: address@hidden
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 3dc834f8795a46f919d90b1e5369308628858601)
* prereq for 81c219a
Signed-off-by: Michael Roth <address@hidden>
Commit: 48f2dc0657874fcaec71d414534ee8558e65bd32
https://github.com/qemu/qemu/commit/48f2dc0657874fcaec71d414534ee8558e65bd32
Author: Eric Blake <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/blkdebug.c
M qapi/block-core.json
Log Message:
-----------
blkdebug: Add ability to override unmap geometries
Make it easier to simulate various unusual hardware setups (for
example, recent commits 3482b9b and b8d0a98 affect the Dell
Equallogic iSCSI with its 15M preferred and maximum unmap and
write zero sizing, or b2f95fe deals with the Linux loopback
block device having a max_transfer of 64k), by allowing blkdebug
to wrap any other device with further restrictions on various
alignments.
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 430b26a82da61876c4eaf559ae02332582968043)
* prereq for 81c219a
Signed-off-by: Michael Roth <address@hidden>
Commit: 3f3fe284efba3021b8a06bddcff75efa4e62c615
https://github.com/qemu/qemu/commit/3f3fe284efba3021b8a06bddcff75efa4e62c615
Author: Eric Blake <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
A tests/qemu-iotests/177
A tests/qemu-iotests/177.out
M tests/qemu-iotests/group
Log Message:
-----------
tests: Add coverage for recent block geometry fixes
Use blkdebug's new geometry constraints to emulate setups that
have needed past regression fixes: write zeroes asserting
when running through a loopback block device with max-transfer
smaller than cluster size, and discard rounding away portions
of requests not aligned to preferred boundaries. Also, add
coverage that the block layer is honoring max transfer limits.
For now, a single iotest performs all actions, with the idea
that we can add future blkdebug constraint test cases in the
same file; but it can be split into multiple iotests if we find
reason to run one portion of the test in more setups than what
are possible in the other.
For reference, the final portion of the test (checking whether
discard passes as much as possible to the lowest layers of the
stack) works as follows:
qemu-io: discard 30M at 80000001, passed to blkdebug
blkdebug: discard 511 bytes at 80000001, -ENOTSUP (smaller than
blkdebug's 512 align)
blkdebug: discard 14371328 bytes at 80000512, passed to qcow2
qcow2: discard 739840 bytes at 80000512, -ENOTSUP (smaller than
qcow2's 1M align)
qcow2: discard 13M bytes at 77M, succeeds
blkdebug: discard 15M bytes at 90M, passed to qcow2
qcow2: discard 15M bytes at 90M, succeeds
blkdebug: discard 1356800 bytes at 105M, passed to qcow2
qcow2: discard 1M at 105M, succeeds
qcow2: discard 308224 bytes at 106M, -ENOTSUP (smaller than qcow2's
1M align)
blkdebug: discard 1 byte at 111457280, -ENOTSUP (smaller than
blkdebug's 512 align)
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Message-id: address@hidden
[mreitz: For cooperation with image locking, add -r to the qemu-io
invocation which verifies the image content]
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 40812d937392fddc11f72a668aef251039cc15ce)
Conflicts:
tests/qemu-iotests/group
* dropped context dependency on other test groups
* prereq for 81c219a
Signed-off-by: Michael Roth <address@hidden>
Commit: 6a3f9c5c6e54d05e35bad786ce619d72d02c29de
https://github.com/qemu/qemu/commit/6a3f9c5c6e54d05e35bad786ce619d72d02c29de
Author: Eric Blake <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/io.c
Log Message:
-----------
block: Simplify BDRV_BLOCK_RAW recursion
Since we are already in coroutine context during the body of
bdrv_co_get_block_status(), we can shave off a few layers of
wrappers when recursing to query the protocol when a format driver
returned BDRV_BLOCK_RAW.
Note that we are already using the correct recursion later on in
the same function, when probing whether the protocol layer is sparse
in order to find out if we can add BDRV_BLOCK_ZERO to an existing
BDRV_BLOCK_DATA|BDRV_BLOCK_OFFSET_VALID.
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit ee29d6adefcca7e76abb124183814ed3acc74fac)
* prereq for 81c219a
Signed-off-by: Michael Roth <address@hidden>
Commit: 64945cb5f35f6b52ddc5ef0e4396b93d5bf87e1e
https://github.com/qemu/qemu/commit/64945cb5f35f6b52ddc5ef0e4396b93d5bf87e1e
Author: Eric Blake <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/io.c
M tests/qemu-iotests/177
M tests/qemu-iotests/177.out
Log Message:
-----------
block: Guarantee that *file is set on bdrv_get_block_status()
We document that *file is valid if the return is not an error and
includes BDRV_BLOCK_OFFSET_VALID, but forgot to obey this contract
when a driver (such as blkdebug) lacks a callback. Messed up in
commit 67a0fd2 (v2.6), when we added the file parameter.
Enhance qemu-iotest 177 to cover this, using a sequence that would
print garbage or even SEGV, because it was dererefencing through
uninitialized memory. [The resulting test output shows that we
have less-than-ideal block status from the blkdebug driver, but
that's a separate fix coming up soon.]
Setting *file on all paths that return BDRV_BLOCK_OFFSET_VALID is
enough to fix the crash, but we can go one step further: always
setting *file, even on error, means that a broken caller that
blindly dereferences file without checking for error is now more
likely to get a reliable SEGV instead of randomly acting on garbage,
making it easier to diagnose such buggy callers. Adding an
assertion that file is set where expected doesn't hurt either.
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 81c219ac6ce0d6182e35f3976f2caa4cefcaf9f0)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0ebbef1fa11a19296037695d37053dc18f0d89db
https://github.com/qemu/qemu/commit/0ebbef1fa11a19296037695d37053dc18f0d89db
Author: Kevin Wolf <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M block/mirror.c
Log Message:
-----------
mirror: Drop permissions on s->target on completion
This fixes an assertion failure that was triggered by qemu-iotests 129
on some CI host, while the same test case didn't seem to fail on other
hosts.
Essentially the problem is that the blk_unref(s->target) in
mirror_exit() doesn't necessarily mean that the BlockBackend goes away
immediately. It is possible that the job completion was triggered nested
in mirror_drain(), which looks like this:
BlockBackend *target = s->target;
blk_ref(target);
blk_drain(target);
blk_unref(target);
In this case, the write permissions for s->target are retained until
after blk_drain(), which makes removing mirror_top_bs fail for the
active commit case (can't have a writable backing file in the chain
without the filter driver).
Explicitly dropping the permissions first means that the additional
reference doesn't hurt and the job can complete successfully even if
called from the nested blk_drain().
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
(cherry picked from commit 63c8ef289087a225d445319d047501d4fe593687)
Signed-off-by: Michael Roth <address@hidden>
Commit: 11bac2f941db77de1aab79e4a74374fa0c6c6107
https://github.com/qemu/qemu/commit/11bac2f941db77de1aab79e4a74374fa0c6c6107
Author: Ladi Prosek <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M hw/char/virtio-serial-bus.c
Log Message:
-----------
virtio-serial-bus: Unset hotplug handler when unrealize
Virtio serial device controls the lifetime of virtio-serial-bus and
virtio-serial-bus links back to the device via its hotplug-handler
property. This extra ref-count prevents the device from getting
finalized, leaving the VirtIODevice memory listener registered and
leading to use-after-free later on.
This patch addresses the same issue as Fam Zheng's
"virtio-scsi: Unset hotplug handler when unrealize"
only for a different virtio device.
Cc: address@hidden
Signed-off-by: Ladi Prosek <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>
(cherry picked from commit f811f97040a48358b456b46ecbc9167f0131034f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 3b428e9512d341b9678a98c032256ae770daed47
https://github.com/qemu/qemu/commit/3b428e9512d341b9678a98c032256ae770daed47
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M pc-bios/linuxboot_dma.bin
M pc-bios/optionrom/Makefile
Log Message:
-----------
linuxboot_dma: compile for i486
The ROM uses the cmovne instruction, which is new in Pentium Pro and does not
work when running QEMU with "-cpu 486". Avoid producing that instruction.
Suggested-by: Richard W.M. Jones <address@hidden>
Suggested-by: Thomas Huth <address@hidden>
Reported-by: Rob Landley <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 7e018385103cd7a571b9ea0d6f994af6b1129fe7)
Signed-off-by: Michael Roth <address@hidden>
Commit: b0a3eadd8cffda0f7de821fab7062d95d78e8ed0
https://github.com/qemu/qemu/commit/b0a3eadd8cffda0f7de821fab7062d95d78e8ed0
Author: Michael Roth <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M tests/check-qom-proplist.c
Log Message:
-----------
tests: check-qom-proplist: add checks for cmdline-created objects
check-qom-proplist originally added tests for verifying that
object-creation helpers object_new_with_{props,propv} behaved in
similar fashion to the "traditional" method involving setting each
individual property separately after object creation rather than
via a single call.
Another similar "helper" for creating Objects exists in the form of
objects specified via -object command-line parameters. By that
rationale, we extend check-qom-proplist to include similar checks
for command-line-created objects by employing the same
qemu_opts_parse()-based parsing the vl.c employs.
This parser has a side-effect of parsing the object's options into
a QemuOpt structure and registering this in the global QemuOptsList
using the Object's ID. This can conflict with future Object instances
that attempt to use the same ID if we don't ensure this is cleaned
up as part of Object finalization, so we include a FIXME stub to test
for this case, which will then be resolved in a subsequent patch.
Suggested-by: Daniel Berrange <address@hidden>
Cc: "Dr. David Alan Gilbert" <address@hidden>
Cc: Markus Armbruster <address@hidden>
Cc: Eric Blake <address@hidden>
Cc: Daniel Berrange <address@hidden>
Cc: address@hidden
Signed-off-by: Michael Roth <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
[Comment formatting tidied up]
Signed-off-by: Markus Armbruster <address@hidden>
(cherry picked from commit a1af255f065ccf3f47a7bfe88f1dbc9eeca36935)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1775fe6148ae11a4e8ad6f6c2813a41e70e12f76
https://github.com/qemu/qemu/commit/1775fe6148ae11a4e8ad6f6c2813a41e70e12f76
Author: Michael Roth <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M qom/object_interfaces.c
M tests/check-qom-proplist.c
Log Message:
-----------
monitor: fix object_del for command-line-created objects
Currently objects specified on the command-line are only partially
cleaned up when 'object_del' is issued in either HMP or QMP: the
object itself is fully finalized, but the QemuOpts are not removed.
This results in the following behavior:
x86_64-softmmu/qemu-system-x86_64 -monitor stdio \
-object memory-backend-ram,id=ram1,size=256M
QEMU 2.7.91 monitor - type 'help' for more information
(qemu) object_del ram1
(qemu) object_del ram1
object 'ram1' not found
(qemu) object_add memory-backend-ram,id=ram1,size=256M
Duplicate ID 'ram1' for object
Try "help object_add" for more information
which can be an issue for use-cases like memory hotplug.
This happens on the HMP side because hmp_object_add() attempts to
create a temporary QemuOpts entry with ID 'ram1', which ends up
conflicting with the command-line-created entry, since it was never
cleaned up during the previous hmp_object_del() call.
We address this by adding a check in user_creatable_del(), which
is called by both qmp_object_del() and hmp_object_del() to handle
the actual object cleanup, to determine whether an option group entry
matching the object's ID is present and removing it if it is.
Note that qmp_object_add() never attempts to create a temporary
QemuOpts entry, so it does not encounter the duplicate ID error,
which is why this isn't generally visible in libvirt.
Cc: "Dr. David Alan Gilbert" <address@hidden>
Cc: Markus Armbruster <address@hidden>
Cc: Eric Blake <address@hidden>
Cc: Daniel Berrange <address@hidden>
Cc: address@hidden
Signed-off-by: Michael Roth <address@hidden>
Reviewed-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>
(cherry picked from commit c645d5acee0ae022534cb609184277ec2b4a8577)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2401d8a490e728f2a63ac7a0c875f969cd298c46
https://github.com/qemu/qemu/commit/2401d8a490e728f2a63ac7a0c875f969cd298c46
Author: Eduardo Habkost <address@hidden>
Date: 2017-08-03 (Thu, 03 Aug 2017)
Changed paths:
M include/hw/i386/pc.h
M tests/test-x86-cpuid-compat.c
Log Message:
-----------
pc: Use "min-[x]level" on compat_props
Since the automatic cpuid-level code was introduced in commit
c39c0edf9bb3b968ba95484465a50c7b19f4aa3a ("target-i386: Automatically
set level/xlevel/xlevel2 when needed"), the CPU model tables just define
the default CPUID level code (set using "min-level"). Setting
"[x]level" forces CPUID level to a specific value and disable the
automatic-level logic.
But the PC compat code was not updated and the existing "[x]level"
compat properties broke compatibility for people using features that
triggered the auto-level code. To keep previous behavior, we should set
"min-[x]level" instead of "[x]level" on compat_props.
This was not a problem for most cases, because old machine-types don't
have full-cpuid-auto-level enabled. The only common use case it broke
was the CPUID[7] auto-level code, that was already enabled since the
first CPUID[7] feature was introduced (in QEMU 1.4.0).
This causes the regression reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=1454641
Change the PC compat code to use "min-[x]level" instead of "[x]level" on
compat_props, and add new test cases to ensure we don't break this
again.
Reported-by: "Guo, Zhiyi" <address@hidden>
Fixes: c39c0edf9bb ("target-i386: Automatically set level/xlevel/xlevel2 when
needed")
Cc: address@hidden
Acked-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 1f43571604da85c62f25f3ba6d275b1b5ea76ca2)
Signed-off-by: Michael Roth <address@hidden>
Commit: 917a5b9f2ff2d9005c4229ac87dff8e54660154a
https://github.com/qemu/qemu/commit/917a5b9f2ff2d9005c4229ac87dff8e54660154a
Author: Greg Kurz <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M target/ppc/kvm.c
M target/ppc/kvm_ppc.h
Log Message:
-----------
target/ppc: pass const string to kvmppc_is_mem_backend_page_size_ok()
This function has three implementations. Two are stubs that do nothing
and the third one only passes the obj_path argument to:
Object *object_resolve_path(const char *path, bool *ambiguous);
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit ec69355beffe138c0f97306e65410e5dbc605554)
Signed-off-by: Michael Roth <address@hidden>
Commit: 592ee4007ee9c4ab89e0e163b2b0a313420e95de
https://github.com/qemu/qemu/commit/592ee4007ee9c4ab89e0e163b2b0a313420e95de
Author: Greg Kurz <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M target/ppc/kvm.c
Log Message:
-----------
target/ppc: fix memory leak in kvmppc_is_mem_backend_page_size_ok()
The string returned by object_property_get_str() is dynamically allocated.
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 2d3e302ec2246d703ffa8d8f8769a3fa448d8145)
Signed-off-by: Michael Roth <address@hidden>
Commit: 7f4c9f5f3be4392479c00633a0bb92b7b4980d6b
https://github.com/qemu/qemu/commit/7f4c9f5f3be4392479c00633a0bb92b7b4980d6b
Author: Laurent Vivier <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: add pre_plug function for memory
This allows to manage errors before the memory
has started to be hotplugged. We already have
the function for the CPU cores.
Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
[dwg: Fixed a couple of style nits]
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit c871bc70bb22d1d70451bc813ecb008fe98cc92b)
Signed-off-by: Michael Roth <address@hidden>
Commit: 3b2f3a4691a18b52969e64cafa703e0fff7711c4
https://github.com/qemu/qemu/commit/3b2f3a4691a18b52969e64cafa703e0fff7711c4
Author: Greg Kurz <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: fix memory leak in spapr_memory_pre_plug()
The string returned by object_property_get_str() is dynamically allocated.
(Spotted by Coverity, CID 1375942)
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 8a9e0e7b890b2598da94646bf6a7272f3d3924de)
Signed-off-by: Michael Roth <address@hidden>
Commit: bace1f90f9207ec79e9d28eb668532b43ac8b81f
https://github.com/qemu/qemu/commit/bace1f90f9207ec79e9d28eb668532b43ac8b81f
Author: Max Filippov <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M target/xtensa/gdbstub.c
Log Message:
-----------
target/xtensa: handle unknown registers in gdbstub
Xtensa cores may have registers of types/sizes not supported by the
gdbstub accessors. Ignore writes to such registers and return zero on
read, but always return correct register size, so that gdb on the other
side is able to access all registers in the packet holding unsupported
registers in the middle. This fixes gdb interaction with cores that have
vector/custom TIE registers.
Cc: address@hidden
Signed-off-by: Max Filippov <address@hidden>
(cherry picked from commit dd7b952b793e341c905355581a21cdbaa8b13c31)
Signed-off-by: Michael Roth <address@hidden>
Commit: f28b8906dd38816ed4da5a98bdeb5ff797afae8a
https://github.com/qemu/qemu/commit/f28b8906dd38816ed4da5a98bdeb5ff797afae8a
Author: Kevin Wolf <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block/commit.c
Log Message:
-----------
commit: Fix use after free in completion
The final bdrv_set_backing_hd() could be working on already freed nodes
because the commit job drops its references (through BlockBackends) to
both overlay_bs and top already a bit earlier.
One way to trigger the bug is hot unplugging a disk for which
blockdev_mark_auto_del() cancels the block job.
Fix this by taking BDS-level references while we're still using the
nodes.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: John Snow <address@hidden>
(cherry picked from commit 19ebd13ed45ad5d5f277f5914d55b83f13eb09eb)
Signed-off-by: Michael Roth <address@hidden>
Commit: ec49c8ac57885db3c9475d9fc9a80e2200dc26de
https://github.com/qemu/qemu/commit/ec49c8ac57885db3c9475d9fc9a80e2200dc26de
Author: Eric Blake <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M nbd/server.c
M qemu-nbd.c
Log Message:
-----------
nbd: Fully initialize client in case of failed negotiation
If a non-NBD client connects to qemu-nbd, we would end up with
a SIGSEGV in nbd_client_put() because we were trying to
unregister the client's association to the export, even though
we skipped inserting the client into that list. Easy trigger
in two terminals:
$ qemu-nbd -p 30001 --format=raw file
$ nmap 127.0.0.1 -p 30001
nmap claims that it thinks it connected to a pago-services1
server (which probably means nmap could be updated to learn the
NBD protocol and give a more accurate diagnosis of the open
port - but that's not our problem), then terminates immediately,
so our call to nbd_negotiate() fails. The fix is to reorder
nbd_co_client_start() to ensure that all initialization occurs
before we ever try talking to a client in nbd_negotiate(), so
that the teardown sequence on negotiation failure doesn't fault
while dereferencing a half-initialized object.
While debugging this, I also noticed that nbd_update_server_watch()
called by nbd_client_closed() was still adding a channel to accept
the next client, even when the state was no longer RUNNING. That
is fixed by making nbd_can_accept() pay attention to the current
state.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1451614
Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit df8ad9f128c15aa0a0ebc7b24e9a22c9775b67af)
Signed-off-by: Michael Roth <address@hidden>
Commit: ecc7a24c11e2ef0ea5965af36bc0aca833435141
https://github.com/qemu/qemu/commit/ecc7a24c11e2ef0ea5965af36bc0aca833435141
Author: Eric Blake <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M blockdev-nbd.c
M include/block/nbd.h
M nbd/server.c
M qemu-nbd.c
Log Message:
-----------
nbd: Fix regression on resiliency to port scan
Back in qemu 2.5, qemu-nbd was immune to port probes (a transient
server would not quit, regardless of how many probe connections
came and went, until a connection actually negotiated). But we
broke that in commit ee7d7aa when removing the return value to
nbd_client_new(), although that patch also introduced a bug causing
an assertion failure on a client that fails negotiation. We then
made it worse during refactoring in commit 1a6245a (a segfault
before we could even assert); the (masked) assertion was cleaned
up in d3780c2 (still in 2.6), and just recently we finally fixed
the segfault ("nbd: Fully intialize client in case of failed
negotiation"). But that still means that ever since we added
TLS support to qemu-nbd, we have been vulnerable to an ill-timed
port-scan being able to cause a denial of service by taking down
qemu-nbd before a real client has a chance to connect.
Since negotiation is now handled asynchronously via coroutines,
we no longer have a synchronous point of return by re-adding a
return value to nbd_client_new(). So this patch instead wires
things up to pass the negotiation status through the close_fn
callback function.
Simple test across two terminals:
$ qemu-nbd -f raw -p 30001 file
$ nmap 127.0.0.1 -p 30001 && \
qemu-io -c 'r 0 512' -f raw nbd://localhost:30001
Note that this patch does not change what constitutes successful
negotiation (thus, a client must enter transmission phase before
that client can be considered as a reason to terminate the server
when the connection ends). Perhaps we may want to tweak things
in a later patch to also treat a client that uses NBD_OPT_ABORT
as being a 'successful' negotiation (the client correctly talked
the NBD protocol, and informed us it was not going to use our
export after all), but that's a discussion for another day.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1451614
Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 0c9390d978cbf61e8f16c9f580fa96b305c43568)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1dd3ba38f6ebf5c11194b420c0539c05cfed1f51
https://github.com/qemu/qemu/commit/1dd3ba38f6ebf5c11194b420c0539c05cfed1f51
Author: Kevin Wolf <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block/commit.c
Log Message:
-----------
commit: Fix completion with extra reference
commit_complete() can't assume that after its block_job_completed() the
job is actually immediately freed; someone else may still be holding
references. In this case, the op blockers on the intermediate nodes make
the graph reconfiguration in the completion code fail.
Call block_job_remove_all_bdrv() manually so that we know for sure that
any blockers on intermediate nodes are given up.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
(cherry picked from commit 4f78a16fee462471416dc49b409d57b2071cf3d9)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1828d47845ca92ec3fcfd82399f036526afc6a31
https://github.com/qemu/qemu/commit/1828d47845ca92ec3fcfd82399f036526afc6a31
Author: Max Reitz <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block/blkdebug.c
Log Message:
-----------
blkdebug: Catch bs->exact_filename overflow
The bs->exact_filename field may not be sufficient to store the full
blkdebug node filename. In this case, we should not generate a filename
at all instead of an unusable one.
Cc: address@hidden
Reported-by: Qu Wenruo <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Alberto Garcia <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit de81d72d3d13a19edf4d461be3b0f5a877be0234)
Signed-off-by: Michael Roth <address@hidden>
Commit: 21827917342bac938e462513afee6c7d39f28adc
https://github.com/qemu/qemu/commit/21827917342bac938e462513afee6c7d39f28adc
Author: Max Reitz <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block/blkverify.c
Log Message:
-----------
blkverify: Catch bs->exact_filename overflow
The bs->exact_filename field may not be sufficient to store the full
blkverify node filename. In this case, we should not generate a filename
at all instead of an unusable one.
Cc: address@hidden
Reported-by: Qu Wenruo <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Alberto Garcia <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 05cc758a3dfc79488d0a8eb7f5830a41871e78d0)
Signed-off-by: Michael Roth <address@hidden>
Commit: 40ed5cdf724598f42907dd5a6b33f4f93dce398a
https://github.com/qemu/qemu/commit/40ed5cdf724598f42907dd5a6b33f4f93dce398a
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block/nbd-client.c
Log Message:
-----------
nbd: fix NBD over TLS
When attaching the NBD QIOChannel to an AioContext, the TLS channel should
be used, not the underlying socket channel. This is because, trivially,
the TLS channel will be the one that we read/write to and thus the one
that will get the qio_channel_yield() call.
Fixes: ff82911cd3f69f028f2537825c9720ff78bc3f19
Cc: address@hidden
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Daniel P. Berrange <address@hidden>
Tested-by: Daniel P. Berrange <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 96d06835dc40007673cdfab6322e9042c4077113)
Signed-off-by: Michael Roth <address@hidden>
Commit: 438cd1e6aacbb0755ab8ec8a03d34998c3ab0ea3
https://github.com/qemu/qemu/commit/438cd1e6aacbb0755ab8ec8a03d34998c3ab0ea3
Author: Max Reitz <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block/nbd.c
M block/nfs.c
M block/sheepdog.c
M block/ssh.c
Log Message:
-----------
block: Do not strcmp() with NULL uri->scheme
uri_parse(...)->scheme may be NULL. In fact, probably every field may be
NULL, and the callers do test this for all of the other fields but not
for scheme (except for block/gluster.c; block/vxhs.c does not access
that field at all).
We can easily fix this by using g_strcmp0() instead of strcmp().
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit f69165a8feca055cf4a37d13ab0fc5beec3cb372)
Signed-off-by: Michael Roth <address@hidden>
Commit: e0398ccdf42e5a54c62ae617d374b5df9684ac0d
https://github.com/qemu/qemu/commit/e0398ccdf42e5a54c62ae617d374b5df9684ac0d
Author: Bruce Rogers <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/9pfs/9p-local.c
Log Message:
-----------
9pfs: local: remove: use correct path component
Commit a0e640a8 introduced a path processing error.
Pass fstatat the dirpath based path component instead
of the entire path.
Signed-off-by: Bruce Rogers <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
(cherry picked from commit 790db7efdbe1536acf1c4f4f95a0316dbda59433)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0060a3e93632c3930ac010f4a576a6673f7dcef4
https://github.com/qemu/qemu/commit/0060a3e93632c3930ac010f4a576a6673f7dcef4
Author: Alexander Graf <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/input/hid.c
Log Message:
-----------
hid: Reset kbd modifiers on reset
When resetting the keyboard, we need to reset not just the pending keystrokes,
but also any pending modifiers. Otherwise there's a race when we're getting
reset while running an escape sequence (modifier 0x100).
Cc: address@hidden
Signed-off-by: Alexander Graf <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 51dbea77a29ea46173373a6dad4ebd95d4661f42)
Signed-off-by: Michael Roth <address@hidden>
Commit: 19284a0141a1a11ef02b5f633590489ddf88d3fc
https://github.com/qemu/qemu/commit/19284a0141a1a11ef02b5f633590489ddf88d3fc
Author: Laurent Vivier <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/ppc/spapr_pci.c
Log Message:
-----------
spapr: fix migration to pseries machine < 2.8
since commit 5c4537bd ("spapr: Fix 2.7<->2.8 migration of PCI host bridge"),
some migration fields are forged from the new ones in spapr_pci_pre_save().
It works well, except when the number of MSI devices is 0,
because in this case the function exits immediately.
This fix moves the migration code before the exit code.
The problem can be reproduced with these commands:
source qemu-2.9:
qemu-system-ppc64 -monitor stdio -M pseries-2.6 -nodefaults -S
destination qemu-2.6:
qemu-system-ppc64 -monitor stdio -M pseries-2.6 -nodefaults \
-incoming tcp:0:4444
on the source:
migrate tcp:localhost:4444
Destination fails with the following error:
qemu-system-ppc64: error while loading state for
instance 0x0 of device 'spapr_pci'
qemu-system-ppc64: load of migration failed: Invalid argument
Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit e806b4db1477a1c6bfda7bba28c7f26c47f18e1e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 70da03f10c4949ad933e122d77b721f8ff1fc368
https://github.com/qemu/qemu/commit/70da03f10c4949ad933e122d77b721f8ff1fc368
Author: Jason Wang <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/scsi/virtio-scsi.c
Log Message:
-----------
virtio-scsi: finalize IOMMU support
After converting to use DMA api for virtio devices, we should use
dma_as instead of address_space_memory. Otherwise it won't work if
IOMMU is enabled.
Fixes: commit 8607f5c3072c ("virtio: convert to use DMA api")
Cc: address@hidden
Signed-off-by: Jason Wang <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 025bdeab3c163aee9604a60b2332a5fcbcc00f8d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2e40aad231fbb8944bc2557fd9dce0d4e8d2523e
https://github.com/qemu/qemu/commit/2e40aad231fbb8944bc2557fd9dce0d4e8d2523e
Author: Kevin Wolf <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block/commit.c
Log Message:
-----------
commit: Add NULL check for overlay_bs
I can't see how overlay_bs could become NULL with the current code, but
other code in this function already checks it and we can make Coverity
happy with this check, so let's add it.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit b1e1fa0c3afc7f671fbc24645bdf67949a5657e5)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2a7526b0ce649b5c3b06790b9ea7a7b318d38ef4
https://github.com/qemu/qemu/commit/2a7526b0ce649b5c3b06790b9ea7a7b318d38ef4
Author: Greg Kurz <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: fix memory leak in spapr_core_pre_plug()
In case of error, we must ensure the dynamically allocated base_core_type
is freed, like it is done everywhere else in this function.
This is a regression introduced in QEMU 2.9 by commit 8149e2992f78.
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit df8658de43db242ea82183d75cc957c2b0fa013a)
Conflicts:
hw/ppc/spapr.c
* fix context dep on 459264ef2
Signed-off-by: Michael Roth <address@hidden>
Commit: 9527514ceb2383f269927cf81e604597078a0684
https://github.com/qemu/qemu/commit/9527514ceb2383f269927cf81e604597078a0684
Author: Jason Wang <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
virtio-net: fix offload ctrl endian
Spec said offloads should be le64, so use virtio_ldq_p() to guarantee
valid endian.
Fixes: 644c98587d4c ("virtio-net: dynamic network offloads configuration")
Cc: address@hidden
Cc: Dmitry Fleytman <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit 189ae6bb5ce1f5a322f8691d00fe942ba43dd601)
Signed-off-by: Michael Roth <address@hidden>
Commit: f8d050a20a40113a6b6945fa364b655a6a327ac8
https://github.com/qemu/qemu/commit/f8d050a20a40113a6b6945fa364b655a6a327ac8
Author: Gerd Hoffmann <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M ui/input.c
Log Message:
-----------
input: limit kbd queue depth
Apply a limit to the number of items we accept into the keyboard queue.
Impact: Without this limit vnc clients can exhaust host memory by
sending keyboard events faster than qemu feeds them to the guest.
Fixes: CVE-2017-8379
Cc: P J P <address@hidden>
Cc: Huawei PSIRT <address@hidden>
Reported-by: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
Message-id: address@hidden
(cherry picked from commit fa18f36a461984eae50ab957e47ec78dae3c14fc)
Signed-off-by: Michael Roth <address@hidden>
Commit: ad480ab20b057209b959b948f073c5baea8ef8f1
https://github.com/qemu/qemu/commit/ad480ab20b057209b959b948f073c5baea8ef8f1
Author: Alexander Graf <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M ui/input.c
Log Message:
-----------
input: Decrement queue count on kbd delay
Delays in the input layer are special cased input events. Every input
event is accounted for in a global intput queue count. The special cased
delays however did not get removed from the queue, leading to queue overruns
and thus silent key drops after typing quite a few characters.
Signed-off-by: Alexander Graf <address@hidden>
Message-id: address@hidden
Fixes: be1a7176 ("input: add support for kbd delays")
Cc: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 77b0359bf414ad666d1714dc9888f1017c08e283)
Signed-off-by: Michael Roth <address@hidden>
Commit: d445e0a022e37f8b8155a8b48c680286957711d4
https://github.com/qemu/qemu/commit/d445e0a022e37f8b8155a8b48c680286957711d4
Author: Kevin Wolf <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M tests/qemu-iotests/040
M tests/qemu-iotests/040.out
Log Message:
-----------
qemu-iotests: Test automatic commit job cancel on hot unplug
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: John Snow <address@hidden>
(cherry picked from commit c3971b883a596abc6af45f53d2f43fb2f59ccd3b)
*prereq for d3c8c674
Signed-off-by: Michael Roth <address@hidden>
Commit: a0ddbcfb681fd3341058f5d7ccfb3f208a7dc16a
https://github.com/qemu/qemu/commit/a0ddbcfb681fd3341058f5d7ccfb3f208a7dc16a
Author: Kevin Wolf <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block.c
M block/commit.c
M block/mirror.c
M block/qapi.c
M include/block/block.h
M include/block/block_int.h
M qapi/block-core.json
M tests/qemu-iotests/040
M tests/qemu-iotests/040.out
M tests/qemu-iotests/041
M tests/qemu-iotests/041.out
Log Message:
-----------
block: Skip implicit nodes in query-block/blockstats
Commits 0db832f and 6cdbceb introduced the automatic insertion of filter
nodes above the top layer of mirror and commit block jobs. The
assumption made there was that since libvirt doesn't do node-level
management of the block layer yet, it shouldn't be affected by added
nodes.
This is true as far as commands issued by libvirt are concerned. It only
uses BlockBackend names to address nodes, so any operations it performs
still operate on the root of the tree as intended.
However, the assumption breaks down when you consider query commands,
which return data for the wrong node now. These commands also return
information on some child nodes (bs->file and/or bs->backing), which
libvirt does make use of, and which refer to the wrong nodes, too.
One of the consequences is that oVirt gets wrong information about the
image size and stops the VM in response as long as a mirror or commit
job is running:
https://bugzilla.redhat.com/show_bug.cgi?id=1470634
This patch fixes the problem by hiding the implicit nodes created
automatically by the mirror and commit block jobs in the output of
query-block and BlockBackend-based query-blockstats as long as the user
doesn't indicate that they are aware of those nodes by providing a node
name for them in the QMP command to start the block job.
The node-based commands query-named-block-nodes and query-blockstats
with query-nodes=true still show all nodes, including implicit ones.
This ensures that users that are capable of node-level management can
still access the full information; users that only know BlockBackends
won't use these commands.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Peter Krempa <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Tested-by: Eric Blake <address@hidden>
(cherry picked from commit d3c8c67469ee70fcae116d5abc277a7ebc8a19fd)
Conflicts:
block/qapi.c
include/block/block_int.h
* fix context deps on 46eade7b and 5a9347c6
Signed-off-by: Michael Roth <address@hidden>
Commit: de9b6728ff712610a4f49a37f20a428f12d3623f
https://github.com/qemu/qemu/commit/de9b6728ff712610a4f49a37f20a428f12d3623f
Author: Laurent Vivier <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/cpu/core.c
Log Message:
-----------
cpu: don't allow negative core id
With pseries machine type a negative core-id is not managed properly:
-1 gives an inaccurate error message ("core -1 already populated"),
-2 crashes QEMU (core dump)
As it seems a negative value is invalid for any architecture,
instead of checking this in spapr_core_pre_plug() I think it's better
to check this in the generic part, core_prop_set_core_id()
Signed-off-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Reviewed-by: Eduardo Habkost <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit be2960baae07e5257cde8c814cbd91647e235147)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5f7f7e4f0562508df96e26da3ed3ce3a42247114
https://github.com/qemu/qemu/commit/5f7f7e4f0562508df96e26da3ed3ce3a42247114
Author: Aleksandr Bezzubikov <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/i386/acpi-build.c
Log Message:
-----------
hw/i386: allow SHPC for Q35 machine
Unmask previously masked SHPC feature in _OSC method.
Signed-off-by: Aleksandr Bezzubikov <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit a41c78c135eb1850826e96b2154690323ff66719)
Signed-off-by: Michael Roth <address@hidden>
Commit: f4f3529cfef70c87df94c00691fbea531aa59166
https://github.com/qemu/qemu/commit/f4f3529cfef70c87df94c00691fbea531aa59166
Author: Jeff Cody <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M block/nfs.c
Log Message:
-----------
block/nfs: fix mutex assertion in nfs_file_close()
Commit c096358e747e88fc7364e40e3c354ee0bb683960 introduced assertion
checks for when qemu_mutex() functions are called without the
corresponding qemu_mutex_init() having initialized the mutex.
This uncovered a latent bug in qemu's nfs driver - in
nfs_client_close(), the NFSClient structure is overwritten with zeros,
prior to the mutex being destroyed.
Go ahead and destroy the mutex in nfs_client_close(), and change where
we call qemu_mutex_init() so that it is correctly balanced.
There are also a couple of memory leaks obscured by the memset, so this
fixes those as well.
Finally, we should be able to get rid of the memset(), as it isn't
necessary.
Cc: address@hidden
Signed-off-by: Jeff Cody <address@hidden>
Reviewed-by: Peter Lieven <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 113fe792fd4931dd0538f03859278b8719ee4fa2)
Signed-off-by: Michael Roth <address@hidden>
Commit: 077a67e929b083704d265eb883aa84a368f4ad4a
https://github.com/qemu/qemu/commit/077a67e929b083704d265eb883aa84a368f4ad4a
Author: Greg Kurz <address@hidden>
Date: 2017-08-24 (Thu, 24 Aug 2017)
Changed paths:
M hw/9pfs/9p-local.c
M hw/9pfs/9p-util.h
Log Message:
-----------
9pfs: local: fix fchmodat_nofollow() limitations
This function has to ensure it doesn't follow a symlink that could be used
to escape the virtfs directory. This could be easily achieved if fchmodat()
on linux honored the AT_SYMLINK_NOFOLLOW flag as described in POSIX, but
it doesn't. There was a tentative to implement a new fchmodat2() syscall
with the correct semantics:
https://patchwork.kernel.org/patch/9596301/
but it didn't gain much momentum. Also it was suggested to look at an O_PATH
based solution in the first place.
The current implementation covers most use-cases, but it notably fails if:
- the target path has access rights equal to 0000 (openat() returns EPERM),
=> once you've done chmod(0000) on a file, you can never chmod() again
- the target path is UNIX domain socket (openat() returns ENXIO)
=> bind() of UNIX domain sockets fails if the file is on 9pfs
The solution is to use O_PATH: openat() now succeeds in both cases, and we
can ensure the path isn't a symlink with fstat(). The associated entry in
"/proc/self/fd" can hence be safely passed to the regular chmod() syscall.
The previous behavior is kept for older systems that don't have O_PATH.
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Tested-by: Zhi Yong Wu <address@hidden>
Acked-by: Philippe Mathieu-Daudé <address@hidden>
(cherry picked from commit 4751fd5328dfcd4fe2f9055728a72a0e3ae56512)
Signed-off-by: Michael Roth <address@hidden>
Commit: c152efc943d4e3a1aa2986d7388b89b87cc59520
https://github.com/qemu/qemu/commit/c152efc943d4e3a1aa2986d7388b89b87cc59520
Author: Philipp Kern <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M target/s390x/misc_helper.c
Log Message:
-----------
target-s390x: Mask the SIGP order_code to 8bit.
According to "CPU Signaling and Response", "Signal-Processor Orders",
the order field is bit position 56-63. Without this, the Linux
guest kernel is sometimes unable to stop emulation and enters
an infinite loop of "XXX unknown sigp: 0xffffffff00000005".
Signed-off-by: Philipp Kern <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
[agraf: add comment according to email]
Signed-off-by: Alexander Graf <address@hidden>
(cherry picked from commit 601b9a9008c5a612d76073bb3f178621cff41980)
Signed-off-by: Michael Roth <address@hidden>
Commit: e8679f5b456afdc2278913245b491a3e907cd899
https://github.com/qemu/qemu/commit/e8679f5b456afdc2278913245b491a3e907cd899
Author: Thomas Huth <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M monitor.c
Log Message:
-----------
monitor: Check whether TCG is enabled before running the "info jit" code
The "info jit" command currently aborts on Mac OS X with the message
"qemu_mutex_lock: Invalid argument" when running with "-M accel=qtest".
We should only call into the TCG code here if TCG has really been
enabled and initialized.
Signed-off-by: Thomas Huth <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Tested-by: Peter Maydell <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
(cherry picked from commit b7da97eef74bf834be244de0796ccb01db3985c9)
Signed-off-by: Michael Roth <address@hidden>
Commit: 746e1fd00094b6fa13ec6a9cc3f9d7437c0f9d81
https://github.com/qemu/qemu/commit/746e1fd00094b6fa13ec6a9cc3f9d7437c0f9d81
Author: Marc-André Lureau <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M slirp/tftp.c
Log Message:
-----------
slirp: tftp, copy sockaddr_size
ASAN detects an "unknown-crash" when running pxe-test:
/ppc64/pxe/spapr-vlan:
=================================================================
==7143==ERROR: AddressSanitizer: unknown-crash on address 0x7f6dcd298d30 at pc
0x55e22218830d bp 0x7f6dcd2989e0 sp 0x7f6dcd2989d0
READ of size 128 at 0x7f6dcd298d30 thread T2
#0 0x55e22218830c in tftp_session_allocate
/home/elmarco/src/qq/slirp/tftp.c:73
#1 0x55e22218a1f8 in tftp_handle_rrq /home/elmarco/src/qq/slirp/tftp.c:289
#2 0x55e22218b54c in tftp_input /home/elmarco/src/qq/slirp/tftp.c:446
#3 0x55e2221833fe in udp6_input /home/elmarco/src/qq/slirp/udp6.c:82
#4 0x55e222137b17 in ip6_input /home/elmarco/src/qq/slirp/ip6_input.c:67
Address 0x7f6dcd298d30 is located in stack of thread T2 at offset 96 in frame
#0 0x55e222182420 in udp6_input /home/elmarco/src/qq/slirp/udp6.c:13
This frame has 3 object(s):
[32, 48) '<unknown>'
[96, 124) 'lhost' <== Memory access at offset 96 partially overflows this
variable
[160, 200) 'save_ip' <== Memory access at offset 96 partially underflows
this variable
The sockaddr_storage pointer is the sockaddr_in6 lhost on the
stack. Copy only the source addr size.
Signed-off-by: Marc-André Lureau <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Samuel Thibault <address@hidden>
(cherry picked from commit 17eb587aeb492fe68f8130b027154ff0921fc0b4)
Signed-off-by: Michael Roth <address@hidden>
Commit: 62708c7c1236f6219f9395f00faf8ce655a2aec6
https://github.com/qemu/qemu/commit/62708c7c1236f6219f9395f00faf8ce655a2aec6
Author: Samuel Thibault <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M slirp/socket.c
Log Message:
-----------
slirp: fix clearing ifq_so from pending packets
The if_fastq and if_batchq contain not only packets, but queues of packets
for the same socket. When sofree frees a socket, it thus has to clear ifq_so
from all the packets from the queues, not only the first.
Signed-off-by: Samuel Thibault <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Cc: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 1201d308519f1e915866d7583d5136d03cc1d384)
Signed-off-by: Michael Roth <address@hidden>
Commit: ac0038f18299353580388e969992dab49ae90531
https://github.com/qemu/qemu/commit/ac0038f18299353580388e969992dab49ae90531
Author: Thomas Huth <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/s390x/ipl.c
Log Message:
-----------
hw/s390x/ipl: Fix crash with virtio-scsi-pci device
qemu-system-s390x currently crashes when it is started with a
virtio-scsi-pci device, e.g.:
qemu-system-s390x -nographic -enable-kvm -device virtio-scsi-pci \
-drive file=/tmp/disk.dat,if=none,id=d1,format=raw \
-device scsi-cd,drive=d1,bootindex=1
The problem is that the code in s390_gen_initial_iplb() currently assumes
that all SCSI devices are also CCW devices, which is not the case for
virtio-scsi-pci of course. Fix it by adding an appropriate check for
TYPE_CCW_DEVICE here.
Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: Christian Borntraeger <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Christian Borntraeger <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 99efaa2696caaf6182958e27d553449674894b27)
Signed-off-by: Michael Roth <address@hidden>
Commit: cfc65be6fb1ea5eab086817021962986ecd0d993
https://github.com/qemu/qemu/commit/cfc65be6fb1ea5eab086817021962986ecd0d993
Author: Eduardo Otubo <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/unicore32/puv3.c
Log Message:
-----------
fix qemu-system-unicore32 crashing when calling without -kernel
Starting qemu-system-unicore32 without the -kernel parameter results in
an assert() returns false and aborts qemu. This patch replaces it with a
proper error message followed by exit(1).
Signed-off-by: Eduardo Otubo <address@hidden>
Tested-by: Thomas Huth <address@hidden>
Signed-off-by: Michael Tokarev <address@hidden>
(cherry picked from commit 36bed541ca886da735bef1e8d76d09f8849ed5dd)
Signed-off-by: Michael Roth <address@hidden>
Commit: aab00230aaa89bd1862d5fa235d476646415fdee
https://github.com/qemu/qemu/commit/aab00230aaa89bd1862d5fa235d476646415fdee
Author: Eduardo Habkost <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/acpi/piix4.c
M hw/arm/spitz.c
M hw/audio/marvell_88w8618.c
M hw/audio/pcspk.c
M hw/core/or-irq.c
M hw/core/qdev.c
M hw/core/register.c
M hw/dma/i8257.c
M hw/dma/sparc32_dma.c
M hw/gpio/omap_gpio.c
M hw/i2c/omap_i2c.c
M hw/i2c/smbus_eeprom.c
M hw/i2c/smbus_ich9.c
M hw/i386/pc.c
M hw/input/vmmouse.c
M hw/intc/apic_common.c
M hw/intc/etraxfs_pic.c
M hw/intc/grlib_irqmp.c
M hw/intc/i8259_common.c
M hw/intc/nios2_iic.c
M hw/intc/omap_intc.c
M hw/isa/lpc_ich9.c
M hw/isa/piix4.c
M hw/isa/vt82c686.c
M hw/mips/gt64xxx_pci.c
M hw/misc/vmport.c
M hw/net/dp8393x.c
M hw/net/etraxfs_eth.c
M hw/net/lance.c
M hw/pci-bridge/dec.c
M hw/pci-bridge/pci_expander_bridge.c
M hw/pci-host/apb.c
M hw/pci-host/bonito.c
M hw/pci-host/gpex.c
M hw/pci-host/grackle.c
M hw/pci-host/piix.c
M hw/pci-host/ppce500.c
M hw/pci-host/prep.c
M hw/pci-host/q35.c
M hw/pci-host/uninorth.c
M hw/pci-host/versatile.c
M hw/pci-host/xilinx-pcie.c
M hw/ppc/ppc4xx_pci.c
M hw/ppc/spapr_drc.c
M hw/s390x/s390-pci-bus.c
M hw/sd/milkymist-memcard.c
M hw/sd/pl181.c
M hw/sh4/sh_pci.c
M hw/timer/i8254_common.c
M hw/timer/mc146818rtc.c
M include/hw/qdev-core.h
M include/hw/qdev-properties.h
M monitor.c
M qdev-monitor.c
M qom/cpu.c
M target/i386/cpu.c
Log Message:
-----------
qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable
cannot_instantiate_with_device_add_yet was introduced by commit
efec3dd631d94160288392721a5f9c39e50fb2bc to replace no_user. It was
supposed to be a temporary measure.
When it was introduced, we had 54
cannot_instantiate_with_device_add_yet=true lines in the code.
Today (3 years later) this number has not shrunk: we now have
57 cannot_instantiate_with_device_add_yet=true lines. I think it
is safe to say it is not a temporary measure, and we won't see
the flag go away soon.
Instead of a long field name that misleads people to believe it
is temporary, replace it a shorter and less misleading field:
user_creatable.
Except for code comments, changes were generated using the
following Coccinelle patch:
@@
expression DC;
@@
(
-DC->cannot_instantiate_with_device_add_yet = false;
+DC->user_creatable = true;
|
-DC->cannot_instantiate_with_device_add_yet = true;
+DC->user_creatable = false;
)
@@
typedef ObjectClass;
expression dc;
identifier class, data;
@@
static void device_class_init(ObjectClass *class, void *data)
{
...
dc->hotpluggable = true;
+dc->user_creatable = true;
...
}
@@
@@
struct DeviceClass {
...
-bool cannot_instantiate_with_device_add_yet;
+bool user_creatable;
...
}
@@
expression DC;
@@
(
-!DC->cannot_instantiate_with_device_add_yet
+DC->user_creatable
|
-DC->cannot_instantiate_with_device_add_yet
+!DC->user_creatable
)
Cc: Alistair Francis <address@hidden>
Cc: Laszlo Ersek <address@hidden>
Cc: Marcel Apfelbaum <address@hidden>
Cc: Markus Armbruster <address@hidden>
Cc: Peter Maydell <address@hidden>
Cc: Thomas Huth <address@hidden>
Acked-by: Alistair Francis <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Acked-by: Marcel Apfelbaum <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
[ehabkost: kept "TODO remove once we're there" comment]
Reviewed-by: Markus Armbruster <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit e90f2a8c3e0e677eeea46a9b401c3f98425ffa37)
Conflicts:
include/hw/qdev-core.h
* remove context dep on 08f00df
Signed-off-by: Michael Roth <address@hidden>
Commit: 980e8260e6fbbea5fd068781522b241c6df4f127
https://github.com/qemu/qemu/commit/980e8260e6fbbea5fd068781522b241c6df4f127
Author: Thomas Huth <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/ppc/spapr_rtc.c
Log Message:
-----------
hw/ppc/spapr_rtc: Mark the RTC device with user_creatable = false
QEMU currently aborts unexpectedly when a user tries to do something
like this:
$ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio
QEMU 2.9.92 monitor - type 'help' for more information
(qemu) device_add spapr-rtc,id=spapr-rtc
(qemu) device_del spapr-rtc
**
ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl)
Aborted (core dumped)
The RTC device is not meant to be hot-pluggable - it's an internal
device only and it even should not be possible to create it a
second time with the "-device" parameter, so let's mark this
with "user_creatable = false".
Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 8ccccff9dd7ba24c7a78861172e8dc6b07f1c392)
Signed-off-by: Michael Roth <address@hidden>
Commit: 9b9b4423d7c868309df4b142527310a60584b4d2
https://github.com/qemu/qemu/commit/9b9b4423d7c868309df4b142527310a60584b4d2
Author: Thomas Huth <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/ppc/spapr_iommu.c
Log Message:
-----------
hw/ppc/spapr_iommu: Fix crash when removing the "spapr-tce-table" device
QEMU currently aborts unexpectedly when the user tries to add and
remove a "spapr-tce-table" device:
$ qemu-system-ppc64 -nographic -S -nodefaults -monitor stdio
QEMU 2.9.92 monitor - type 'help' for more information
(qemu) device_add spapr-tce-table,id=x
(qemu) device_del x
**
ERROR:qemu/qdev-monitor.c:872:qdev_unplug: assertion failed: (hotplug_ctrl)
Aborted (core dumped)
The device should not be accessable for the users at all, it's just
used internally, so mark it with user_creatable = false.
Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 1f98e55385d11da1dc0de6440e66f19d191d2a1b)
Signed-off-by: Michael Roth <address@hidden>
Commit: 40a7d47c5a88e4045b471dff38182d5a21cae682
https://github.com/qemu/qemu/commit/40a7d47c5a88e4045b471dff38182d5a21cae682
Author: P J P <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/scsi/vmw_pvscsi.c
Log Message:
-----------
vmw_pvscsi: check message ring page count at initialisation
A guest could set the message ring page count to zero, resulting in
infinite loop. Add check to avoid it.
Reported-by: YY Z <address@hidden>
Signed-off-by: P J P <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Dmitry Fleytman <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit f68826989cd4d1217797251339579c57b3c0934e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 3c6913263555bf43963d6ee8aa30b0ce1bd89b8d
https://github.com/qemu/qemu/commit/3c6913263555bf43963d6ee8aa30b0ce1bd89b8d
Author: Gerd Hoffmann <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M audio/audio.c
Log Message:
-----------
audio: release capture buffers
AUD_add_capture() allocates two buffers which are never released.
Add the missing calls to AUD_del_capture().
Impact: Allows vnc clients to exhaust host memory by repeatedly
starting and stopping audio capture.
Fixes: CVE-2017-8309
Cc: P J P <address@hidden>
Cc: Huawei PSIRT <address@hidden>
Reported-by: "Jiangxin (hunter, SCC)" <address@hidden>
Signed-off-by: Gerd Hoffmann <address@hidden>
Reviewed-by: Prasad J Pandit <address@hidden>
Message-id: address@hidden
(cherry picked from commit 3268a845f41253fb55852a8429c32b50f36f349a)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0f590e798fe6a8bbff4c5b833f4e751dd98d7aa4
https://github.com/qemu/qemu/commit/0f590e798fe6a8bbff4c5b833f4e751dd98d7aa4
Author: Prasad J Pandit <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
scsi: avoid an off-by-one error in megasas_mmio_write
While reading magic sequence(MFI_SEQ) in megasas_mmio_write,
an off-by-one error could occur as 's->adp_reset' index is not
reset after reading the last sequence.
Reported-by: YY Z <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 24dfa9fa2f90a95ac33c7372de4f4f2c8a2c141f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 7442018a001c8e626a46d19488f470c1fdb162cf
https://github.com/qemu/qemu/commit/7442018a001c8e626a46d19488f470c1fdb162cf
Author: Greg Kurz <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/9pfs/9p-local.c
Log Message:
-----------
9pfs: local: forbid client access to metadata (CVE-2017-7493)
When using the mapped-file security mode, we shouldn't let the client mess
with the metadata. The current code already tries to hide the metadata dir
from the client by skipping it in local_readdir(). But the client can still
access or modify it through several other operations. This can be used to
escalate privileges in the guest.
Affected backend operations are:
- local_mknod()
- local_mkdir()
- local_open2()
- local_symlink()
- local_link()
- local_unlinkat()
- local_renameat()
- local_rename()
- local_name_to_path()
Other operations are safe because they are only passed a fid path, which
is computed internally in local_name_to_path().
This patch converts all the functions listed above to fail and return
EINVAL when being passed the name of the metadata dir. This may look
like a poor choice for errno, but there's no such thing as an illegal
path name on Linux and I could not think of anything better.
This fixes CVE-2017-7493.
Reported-by: Leo Gaspard <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
(cherry picked from commit 7a95434e0ca8a037fd8aa1a2e2461f92585eb77b)
Signed-off-by: Michael Roth <address@hidden>
Commit: 20fd62d374659269977426cacd9a655c022ff774
https://github.com/qemu/qemu/commit/20fd62d374659269977426cacd9a655c022ff774
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
megasas: do not read sense length more than once from frame
Avoid TOC-TOU bugs depending on how the compiler behaves.
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 134550bf81a026e18cf58b81e2c2cceaf516f92e)
Signed-off-by: Michael Roth <address@hidden>
Commit: d016071ca577e32ea9ebc0ed6fa39c8b22cb6788
https://github.com/qemu/qemu/commit/d016071ca577e32ea9ebc0ed6fa39c8b22cb6788
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
megasas: do not read iovec count more than once from frame
Avoid TOC-TOU bugs depending on how the compiler behaves.
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 24c0c77af515acbf0f9705e8096f33ef24d37430)
Signed-off-by: Michael Roth <address@hidden>
Commit: 50b93533153b1e49aa26e289a49d3c9773e189f5
https://github.com/qemu/qemu/commit/50b93533153b1e49aa26e289a49d3c9773e189f5
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
megasas: do not read DCMD opcode more than once from frame
Avoid TOC-TOU bugs by storing the DCMD opcode in the MegasasCmd
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 5104fac8539eaf155fc6de93e164be43e1e62242)
Signed-off-by: Michael Roth <address@hidden>
Commit: 578fb5003f4f86d332c8ec7584d1f586ba58b0f8
https://github.com/qemu/qemu/commit/578fb5003f4f86d332c8ec7584d1f586ba58b0f8
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
megasas: do not read command more than once from frame
Avoid TOC-TOU bugs by passing the frame_cmd down, and checking
cmd->dcmd_opcode instead of cmd->frame->header.frame_cmd.
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 36c327a69d723571f02a7691631667cdb1865ee1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 244a3ef947ec21020459d6f6f81626d70aeae1c2
https://github.com/qemu/qemu/commit/244a3ef947ec21020459d6f6f81626d70aeae1c2
Author: Paolo Bonzini <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
megasas: do not read SCSI req parameters more than once from frame
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit b356807fcdfc45583c437f761fc579ab2a8eab11)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4e6889b76b379bef932bf93dd158ca4676efa61e
https://github.com/qemu/qemu/commit/4e6889b76b379bef932bf93dd158ca4676efa61e
Author: Gerd Hoffmann <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M hw/usb/redirect.c
Log Message:
-----------
usb-redir: fix stack overflow in usbredir_log_data
Don't reinvent a broken wheel, just use the hexdump function we have.
Impact: low, broken code doesn't run unless you have debug logging
enabled.
Reported-by: 李强 <address@hidden>
Signed-off-by: Gerd Hoffmann <address@hidden>
Message-id: address@hidden
(cherry picked from commit bd4a683505b27adc1ac809f71e918e58573d851d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 20920f4db6dee3be9d875cc9e006e42ee0eff3d0
https://github.com/qemu/qemu/commit/20920f4db6dee3be9d875cc9e006e42ee0eff3d0
Author: Max Reitz <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M qemu-nbd.c
Log Message:
-----------
qemu-nbd: Ignore SIGPIPE
qemu proper has done so for 13 years
(8a7ddc38a60648257dc0645ab4a05b33d6040063), qemu-img and qemu-io have
done so for four years (526eda14a68d5b3596be715505289b541288ef2a).
Ignoring this signal is especially important in qemu-nbd because
otherwise a client can easily take down the qemu-nbd server by dropping
the connection when the server wants to send something, for example:
$ qemu-nbd -x foo -f raw -t null-co:// &
[1] 12726
$ qemu-io -c quit nbd://localhost/bar
can't open device nbd://localhost/bar: No export with name 'bar' available
[1] + 12726 broken pipe qemu-nbd -x foo -f raw -t null-co://
In this case, the client sends an NBD_OPT_ABORT and closes the
connection (because it is not required to wait for a reply), but the
server replies with an NBD_REP_ACK (because it is required to reply).
Signed-off-by: Max Reitz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 041e32b8d9d076980b4e35317c0339e57ab888f1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 503518416597cff41d4439555e5fceecdcc43400
https://github.com/qemu/qemu/commit/503518416597cff41d4439555e5fceecdcc43400
Author: Alexander Graf <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M qemu-options.hx
M ui/vnc.c
Log Message:
-----------
vnc: Set default kbd delay to 10ms
The current VNC default keyboard delay is 1ms. With that we're constantly
typing faster than the guest receives keyboard events from an XHCI attached
USB HID device.
The default keyboard delay time in the input layer however is 10ms. I don't know
how that number came to be, but empirical tests on some OpenQA driven ARM
systems show that 10ms really is a reasonable default number for the delay.
This patch moves the VNC delay also to 10ms. That way our default is much
safer (good!) and also consistent with the input layer default (also good!).
Signed-off-by: Alexander Graf <address@hidden>
Reviewed-by: Daniel P. Berrange <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit d3b0db6dfea6b3a9ee0d96aceb796bdcafa84314)
Signed-off-by: Michael Roth <address@hidden>
Commit: e22e199b2bb1df99ec66a801f89669f0683f32c5
https://github.com/qemu/qemu/commit/e22e199b2bb1df99ec66a801f89669f0683f32c5
Author: Farhan Ali <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M pc-bios/s390-ccw/cio.h
Log Message:
-----------
s390-ccw: Fix alignment for CCW1
The commit 198c0d1f9df8c4 s390x/css: check ccw address validity
exposes an alignment issue in ccw bios.
According to PoP the CCW must be doubleword aligned. Let's fix
this in the bios.
Cc: address@hidden
Signed-off-by: Farhan Ali <address@hidden>
Reviewed-by: Halil Pasic <address@hidden>
Reviewed-by: Eric Farman <address@hidden>
Acked-by: Christian Borntraeger <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 3a1e4561ad63b303b092387ae006bd41468ece63)
Signed-off-by: Michael Roth <address@hidden>
Commit: 167e76494e0ae3250585b98c32004ae340283a97
https://github.com/qemu/qemu/commit/167e76494e0ae3250585b98c32004ae340283a97
Author: Michael Roth <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M roms/u-boot
Log Message:
-----------
PPC: E500: update u-boot to match shipped binary
Previous submodule commit contained some unused files with comments
that made redistribution requirements unclear, and the submodule commit
should really match the blob we're shipped anyway.
Suggested-by: Peter Maydell <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: 53206753ba1e0eb1e2b508c2608962a194d0df25
https://github.com/qemu/qemu/commit/53206753ba1e0eb1e2b508c2608962a194d0df25
Author: Dr. David Alan Gilbert <address@hidden>
Date: 2017-08-31 (Thu, 31 Aug 2017)
Changed paths:
M vl.c
Log Message:
-----------
vl.c/exit: pause cpus before closing block devices
There's a rare exit seg if the guest is accessing
IO during exit.
It's always hitting the atomic_inc(&bs->in_flight) with a NULL
bs. This was added recently in 99723548 but I don't see it
as the cause.
Flip vl.c around so we pause the cpus before closing the block devices,
that way we shouldn't have anything trying to access them when
they're gone.
This was originally Red Hat bz
https://bugzilla.redhat.com/show_bug.cgi?id=1451015
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
Reported-by: Cong Li <address@hidden>
--
This is a very rare race, I'll leave it running in a loop to see if
we hit anything else and to check this really fixes it.
I do worry if there are other cases that can trigger this - e.g.
hot-unplug or ejecting a CD.
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 452589b6b47e8dc6353df257fc803dfc1383bed8)
Signed-off-by: Michael Roth <address@hidden>
Commit: f9c313f70f3c269e301a04c6ba1dd9a813589d7a
https://github.com/qemu/qemu/commit/f9c313f70f3c269e301a04c6ba1dd9a813589d7a
Author: Gerd Hoffmann <address@hidden>
Date: 2017-09-01 (Fri, 01 Sep 2017)
Changed paths:
M hw/usb/hcd-xhci.c
Log Message:
-----------
xhci: only update dequeue ptr on completed transfers
The dequeue pointer should only be updated in case the transfer
is actually completed. If we update it for inflight transfers
we will not pick them up again after migration, which easily
triggers with HID devices as they typically have a pending
transfer, waiting for user input to happen.
Fixes: 243afe858b95765b98d16a1f0dd50dca262858ad
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1451631
Signed-off-by: Gerd Hoffmann <address@hidden>
Tested-by: Laurent Vivier <address@hidden>
Message-id: address@hidden
(cherry picked from commit d54fddea989ba4aa2912d49583d86ce01c0d27ea)
Signed-off-by: Michael Roth <address@hidden>
Commit: 15d8f91446fe922ccabb20b7e4ab4b32d8f7b5a7
https://github.com/qemu/qemu/commit/15d8f91446fe922ccabb20b7e4ab4b32d8f7b5a7
Author: Prasad J Pandit <address@hidden>
Date: 2017-09-01 (Fri, 01 Sep 2017)
Changed paths:
M exec.c
Log Message:
-----------
exec: use qemu_ram_ptr_length to access guest ram
When accessing guest's ram block during DMA operation, use
'qemu_ram_ptr_length' to get ram block pointer. It ensures
that DMA operation of given length is possible; And avoids
any OOB memory access situations.
Reported-by: Alex <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 04bf2526ce87f21b32c9acba1c5518708c243ad0)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2f64063f4e96eac79087c1eefb0b8b32097108e2
https://github.com/qemu/qemu/commit/2f64063f4e96eac79087c1eefb0b8b32097108e2
Author: Stefano Stabellini <address@hidden>
Date: 2017-09-01 (Fri, 01 Sep 2017)
Changed paths:
M exec.c
M include/sysemu/xen-mapcache.h
M xen-mapcache.c
Log Message:
-----------
xen/mapcache: store dma information in revmapcache entries for debugging
The Xen mapcache is able to create long term mappings, they are called
"locked" mappings. The third parameter of the xen_map_cache call
specifies if a mapping is a "locked" mapping.
>From the QEMU point of view there are two kinds of long term mappings:
[a] device memory mappings, such as option roms and video memory
[b] dma mappings, created by dma_memory_map & friends
After certain operations, ballooning a VM in particular, Xen asks QEMU
kindly to destroy all mappings. However, certainly [a] mappings are
present and cannot be removed. That's not a problem as they are not
affected by balloonning. The *real* problem is that if there are any
mappings of type [b], any outstanding dma operations could fail. This is
a known shortcoming. In other words, when Xen asks QEMU to destroy all
mappings, it is an error if any [b] mappings exist.
However today we have no way of distinguishing [a] from [b]. Because of
that, we cannot even print a decent warning.
This patch introduces a new "dma" bool field to MapCacheRev entires, to
remember if a given mapping is for dma or is a long term device memory
mapping. When xen_invalidate_map_cache is called, we print a warning if
any [b] mappings exist. We ignore [a] mappings.
Mappings created by qemu_map_ram_ptr are assumed to be [a], while
mappings created by address_space_map->qemu_ram_ptr_length are assumed
to be [b].
The goal of the patch is to make debugging and system understanding
easier.
Signed-off-by: Stefano Stabellini <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
Acked-by: Anthony PERARD <address@hidden>
(cherry picked from commit 1ff7c5986a515d2d936eba026ff19947bbc7cb92)
Signed-off-by: Michael Roth <address@hidden>
Commit: 30b76b24398e520b296d705393795f97005a540a
https://github.com/qemu/qemu/commit/30b76b24398e520b296d705393795f97005a540a
Author: Anthony PERARD <address@hidden>
Date: 2017-09-01 (Fri, 01 Sep 2017)
Changed paths:
M exec.c
Log Message:
-----------
exec: Add lock parameter to qemu_ram_ptr_length
Commit 04bf2526ce87f21b32c9acba1c5518708c243ad0 (exec: use
qemu_ram_ptr_length to access guest ram) start using qemu_ram_ptr_length
instead of qemu_map_ram_ptr, but when used with Xen, the behavior of
both function is different. They both call xen_map_cache, but one with
"lock", meaning the mapping of guest memory is never released
implicitly, and the second one without, which means, mapping can be
release later, when needed.
In the context of address_space_{read,write}_continue, the ptr to those
mapping should not be locked because it is used immediatly and never
used again.
The lock parameter make it explicit in which context qemu_ram_ptr_length
is called.
Signed-off-by: Anthony PERARD <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Stefano Stabellini <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit f5aa69bdc3418773f26747ca282c291519626ece)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2d1bbf51c2cb948da4b6fd5f91cf3ecc80b28156
https://github.com/qemu/qemu/commit/2d1bbf51c2cb948da4b6fd5f91cf3ecc80b28156
Author: Richard Henderson <address@hidden>
Date: 2017-09-04 (Mon, 04 Sep 2017)
Changed paths:
M target/arm/translate-a64.c
Log Message:
-----------
target/arm: Fix aa64 ldp register writeback
For "ldp x0, x1, [x0]", if the second load is on a second page and
the second page is unmapped, the exception would be raised with x0
already modified. This means the instruction couldn't be restarted.
Cc: address@hidden
Cc: address@hidden
Reported-by: Andrew <address@hidden>
Signed-off-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Fixes: https://bugs.launchpad.net/qemu/+bug/1713066
Signed-off-by: Richard Henderson <address@hidden>
[PMM: tweaked comment format]
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 3e4d91b94ce400326fae0850578d9e9f30a71adb)
Signed-off-by: Michael Roth <address@hidden>
Commit: c24c5910b78db714efe0698d9d7a8868656d22d8
https://github.com/qemu/qemu/commit/c24c5910b78db714efe0698d9d7a8868656d22d8
Author: Greg Kurz <address@hidden>
Date: 2017-09-05 (Tue, 05 Sep 2017)
Changed paths:
M vl.c
Log Message:
-----------
virtfs: error out gracefully when mandatory suboptions are missing
We internally convert -virtfs to -fsdev/-device. If the user doesn't
provide the path or security_model suboptions, and the fsdev backend
requires them, we hit an assertion when populating the internal -fsdev
option:
util/qemu-option.c:547: opt_set: Assertion `opt->str' failed.
Aborted (core dumped)
Let's test the suboption presence on the command line before trying
to set it in the internal -fsdev option, and let the backend code
error out gracefully (ie, like it already does when the user passes
-fsdev on the command line).
Reported-by: Thomas Huth <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
(cherry picked from commit 32b6943699948f7adc35ada233fbd25daffad5e9)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4cd42653f5c1df326a2678a84f24a78fb9601277
https://github.com/qemu/qemu/commit/4cd42653f5c1df326a2678a84f24a78fb9601277
Author: Michael Roth <address@hidden>
Date: 2017-09-07 (Thu, 07 Sep 2017)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 2.9.1 release
Signed-off-by: Michael Roth <address@hidden>
Compare: https://github.com/qemu/qemu/compare/27dd31f16404^...4cd42653f5c1
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 27dd31: qga-win: Enable 'can-offline' field in 'guest-get-...,
GitHub <=