pc, vhost: fixes for rc3

Fix up bugs and warnings in tests. Revert an experimental commit that I
put in by mistake: harmless but useless.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Wed 09 Aug 2017 02:23:17 BST
# gpg:                using RSA key 0x281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* remotes/mst/tags/for_upstream:
  libqtest: always set up signal handler for SIGABRT
  libvhost-user: quit when no more data received
  net: fix -netdev socket,fd= for UDP sockets
  Revert "cpu: add APIs to allocate/free CPU environment"
  acpi-test: update expected DSDT files
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Currently abort handlers only work for the first test function
in a testcase, because the list of abort handlers is not properly
cleared when qtest_quit() is called.

qtest_quit() only deletes the kill_qemu_hook but doesn't completely
clear the abrt_hooks list.  The effect is that abrt_hooks.is_setup is
never set to false and in a following test the abrt_hooks list is not
initialized and setup_sigabrt_handler() is not called.

One way to solve this is to clear the list in qtest_quit(), but
that means only asserts between qtest_start and qtest_quit will
be catched by the abort handler.

We can make abort handlers work in all cases if we always setup the
signal handler for SIGABRT in qtest_init.
Signed-off-by: NJens Freimann <jfreimann@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

End processing of messages when VHOST_USER_NONE
is received.

Without this we run into a vubr_panic() call and get
"PANIC: Unhandled request: 0"
Signed-off-by: NJens Freimann <jfreiman@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This patch fixes -netdev socket,fd= for UDP sockets
Currently -netdev socket,fd=<...> results in

  qemu: error: specified mcastaddr "127.0.0.1" (0x7f000001) does not
    contain a multicast address
  qemu-system-x86_64: -netdev
    socket,id=n1,fd=3: Device 'socket' could not be initialized

To fix these we need to allow specifying multicast and fd arguments
for the same netdev. With this the user can specify "-netdev
fd=3,mcast=<IP:port>"

Cc: Jason Wang <jasowang@redhat.com>
Fixes: 3d830459Signed-off-by: NJens Freimann <jfreimann@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit e2a7f286.

This was not supposed to go upstream yet. Reverting.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

* --help/--version improvements (Eric)
* GCC 7 workaround (Greg)
* Small SCSI fix (Hannes)
* SSE 4.1 fix (Joseph)
* RCU deadlock fix (myself)

# gpg: Signature made Tue 08 Aug 2017 16:28:56 BST
# gpg:                using RSA key 0xBFFBD25F78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>"
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* remotes/bonzini/tags/for-upstream:
  maint: Include bug-reporting info in --help output
  qga: Give more --version information
  qemu-io: Give more --version information
  qemu-img: Sort sub-command names in --help
  target/i386: set rip_offset for some SSE4.1 instructions
  scsi: clarify sense codes for LUN0 emulation
  kvm: workaround build break on gcc-7.1.1 / fedora26
  Revert "rcu: do not create thread in pthread_atfork callback"
  rcu: completely disable pthread_atfork callbacks as soon as possible
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

These days, many programs are including a bug-reporting address,
or better yet, a link to the project web site, at the tail of
their --help output.  However, we were not very consistent at
doing so: only qemu-nbd and qemu-qa mentioned anything, with the
latter pointing to an individual person instead of the project.

Add a new #define that sets up a uniform string, mentioning both
bug reporting instructions and overall project details, and which
a downstream vendor could tweak if they want bugs to go to a
downstream database.  Then use it in all of our binaries which
have --help output.

The canned text intentionally references http:// instead of https://
because our https website currently causes certificate errors in
some browsers.  That can be tweaked later once we have resolved the
web site issued.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Message-Id: <20170803163353.19558-5-eblake@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Include the package version information (useful for detecting
builds from git or downstream backports), and the copyright notice.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <20170803163353.19558-4-eblake@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Include the package version information (useful for detecting
builds from git or downstream backports), and the copyright notice.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Acked-by: NKevin Wolf <kwolf@redhat.com>
Message-Id: <20170803163353.19558-3-eblake@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

'amend' and 'create' were not listed alphabetically; hoist them
earlier.  Separate the @end table block to make it easier to
copy-and-paste the addition of future sub-commands.
Signed-off-by: NEric Blake <eblake@redhat.com>

Message-Id: <20170803163353.19558-2-eblake@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Block layer patches for 2.10.0-rc2

# gpg: Signature made Tue 08 Aug 2017 14:56:15 BST
# gpg:                using RSA key 0x7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>"
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74  56FE 7F09 B272 C88F 2FD6

* remotes/kevin/tags/for-upstream:
  block/nfs: fix mutex assertion in nfs_file_close()
  qemu-iotests: Test reopen between read-only and read-write
  qemu-io: Allow reopen read-write
  block: Set BDRV_O_ALLOW_RDWR during rw reopen
  block: Allow reopen rw without BDRV_O_ALLOW_RDWR
  block: Fix order in bdrv_replace_child()
  parallels: drop check that bdrv_truncate() is working
  parallels: respect error code of bdrv_getlength() in allocate_clusters()
  block: respect error code from bdrv_getlength in handle_aiocb_write_zeroes
  vmdk: Fix error handling/reporting of vmdk_check
  block/null: Remove 'filename' option
  block: drop bdrv_set_key from BlockDriver
  block/vhdx: check error return of bdrv_truncate()
  block/vhdx: check error return of bdrv_flush()
  block/vhdx: check for offset overflow to bdrv_truncate()
  block/vhdx: check error return of bdrv_getlength()
  quorum: Set sectors-count to 0 when reporting a flush error
  qemu-iotests/109: Fix lock race condition
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Commit c096358e 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: qemu-stable@nongnu.org
Signed-off-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NPeter Lieven <pl@kamp.de>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

This serves as a regression test for the bugs that were just fixed for
bdrv_reopen() between read-only and read-write mode.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>

This allows qemu-iotests to test the switch between read-only and
read-write mode for block devices.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>

Reopening an image should be consistent with opening it, so we should
set BDRV_O_ALLOW_RDWR for any image that is reopened read-write like in
bdrv_open_inherit().
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>

BDRV_O_ALLOW_RDWR is a flag that tells whether qemu can internally
reopen a node read-write temporarily because the user requested
read-write for the top-level image, but qemu decided that read-only is
enough for this node (a backing file).

bdrv_reopen() is different, it is also used for cases where the user
changed their mind and wants to update the options. There is no reason
to forbid making a node read-write in that case.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>

Commit 8ee03995 refactored the code incorrectly and broke the release of
permissions on the old BDS. Instead of changing the permissions to the
new required values after removing the old BDS from the list of
children, it only re-obtains the permissions it already had.

Change the order of operations so that the old BDS is removed again
before calculating the new required permissions.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>

This would be actually strange and error prone. If truncate() nowadays
will fail, there is something fatally wrong. Let's check for that during
the actual work.

The only fallback case is when the file is not zero initialized. In this
case we should switch to preallocation via fallocate().
Signed-off-by: NDenis V. Lunev <den@openvz.org>
CC: Markus Armbruster <armbru@redhat.com>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Max Reitz <mreitz@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

If we can not get the file length, the state of BDS is broken completely.
Return error to the caller.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
CC: Markus Armbruster <armbru@redhat.com>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Max Reitz <mreitz@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Original idea beyond the code in question was the following: we have failed
to write zeroes with fallocate(FALLOC_FL_ZERO_RANGE) as the simplest
approach and via fallocate(FALLOC_FL_PUNCH_HOLE)/fallocate(0). We have the
only chance now: if the request comes beyond end of the file. Thus we
should calculate file length and respect the error code from that op.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
CC: Markus Armbruster <armbru@redhat.com>
CC: Kevin Wolf <kwolf@redhat.com>
CC: Max Reitz <mreitz@redhat.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Errors from the callees must be captured and propagated to our caller,
ensure this for both find_extent() and bdrv_getlength().
Reported-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

This option was only added to allow 'null-co://' and 'null-aio://' as
filenames, its value never served any actual purpose and was ignored.
Nevertheless it was accepted as '-drive driver=null,filename=foo'.

The correct way to enable the protocol prefixes (and that without adding
a useless -drive option) is implementing .bdrv_parse_filename. This is
what this patch does.

Technically, this is an incompatible change, but the null block driver
is only used for benchmarking, testing and debugging, and an option
without effect isn't likely to be used by anyone anyway, so no bad
effects are to be expected.
Reported-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>

This is not used anymore since c01c214b ("block: remove all encryption
handling APIs", 2017-07-11).
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Signed-off-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Reported-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

VHDX uses uint64_t types for most offsets, following the VHDX spec.
However, bdrv_truncate() takes an int64_t value for the truncating
offset.  Check for overflow before calling bdrv_truncate().

While we are here, replace the bit shifting with QEMU_ALIGN_UP as well.

N.B.: For a compliant image this is not an issue, as the maximum VHDX
image size is defined per the spec to be 64TB.
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

Calls to bdrv_getlength() were not checking for error.  In vhdx.c, this
can lead to truncating an image file, so it is a definite bug.  In
vhdx-log.c, the path for improper behavior is less clear, but it is best
to check in any case.

Some minor code movement of the log_guid intialization, as well.
Reported-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NJeff Cody <jcody@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

The QUORUM_REPORT_BAD event has fields to report the sector in which
the error was detected and the number of affected sectors starting
from that one. This is important for read and write errors, but not
for flush errors.

For flush errors the current code reports the total size of the disk
image. That is however not useful information in this case. Moreover,
the bdrv_getlength() call can fail, and there's no good way of
handling that failure.

Since we're reporting useless information and we cannot even guarantee
to do it in a consistent way, this patch changes the code to report 0
instead in all cases.
Reported-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAlberto Garcia <berto@igalia.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

A race condition is currently present between the clean up attempt of
the QEMU process and the execution of qemu-img.  The actual (bad)
output is:

 -Warning: Image size mismatch!
 -Images are identical.
 +qemu-img: Could not open '<build_dir>/tests/qemu-iotests/scratch/t.raw': Failed to get "consistent read" lock
 +Is another process using the image?

A KILL signal is sent to the QEMU process, but qemu-img may begin to
run before the QEMU process is really gone.  qemu-img will then
attempt to open the TEST_IMG file before it can secure a lock on it.

This attempts a more graceful shutdown, and waits for the QEMU process
to exit.
Signed-off-by: NCleber Rosa <crosa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

virtio: fix for rc2

It turns out there's a way to setup SHPC on Q35: just put
a PCI to PCI bridge behind a DMI to PCI one. Our _OSC is
thus incorrect.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Mon 07 Aug 2017 22:39:20 BST
# gpg:                using RSA key 0x281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17  0970 C350 3912 AFBE 8E67
#      Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA  8A0D 281F 0DB8 D28D 5469

* remotes/mst/tags/for_upstream:
  cpu: add APIs to allocate/free CPU environment
  hw/i386: allow SHPC for Q35 machine
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

When emulating various SSE4.1 instructions such as pinsrd, the address
of a memory operand is computed without allowing for the 8-bit
immediate operand located after the memory operand, meaning that the
memory operand uses the wrong address in the case where it is
rip-relative.  This patch adds the required rip_offset setting for
those instructions, so fixing some GCC test failures (13 in the gcc
testsuite in my GCC 6-based testing) when testing with a default CPU
setting enabling those instructions.
Signed-off-by: NJoseph Myers <joseph@codesourcery.com>

Message-Id: <alpine.DEB.2.20.1708080041391.28702@digraph.polyomino.org.uk>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The LUN0 emulation is just that, an emulation for a non-existing
LUN0. So we should be returning LUN_NOT_SUPPORTED for any request
coming from any other LUN.
And we should be aborting unhandled commands with INVALID OPCODE,
not LUN NOT SUPPORTED.
Signed-off-by: NHannes Reinecke <hare@suse.com>
Message-Id: <1501835795-92331-4-git-send-email-hare@suse.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Building QEMU on fedora26 with the latest gcc package fails:

  CC      ppc64-softmmu/target/ppc/kvm.o
In file included from include/sysemu/hw_accel.h:16:0,
                 from target/ppc/kvm.c:31:
target/ppc/kvm.c: In function ‘kvmppc_booke_watchdog_enable’:
include/sysemu/kvm.h:449:35: error: ‘args_tmp[i]’ may be used uninitialized
 in this function [-Werror=maybe-uninitialized]
             cap.args[i] = args_tmp[i];                               \
                                   ^
target/ppc/kvm.c: In function ‘kvmppc_set_papr’:
include/sysemu/kvm.h:449:35: error: ‘args_tmp[i]’ may be used uninitialized
 in this function [-Werror=maybe-uninitialized]
cc1: all warnings being treated as errors

$ rpm -q gcc
gcc-7.1.1-3.fc26.ppc64le

The compiler should obviously optimize this code away when no extra
agument is passed to kvm_vm_enable_cap() and kvm_vcpu_enable_cap(),
but it doesn't. This bug should be fixed one day in gcc, but we can
also change our code pattern so that we don't hit the issue anymore.
We workaround this, by using memcpy() instead of open-coding the copy.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Message-Id: <150210580404.1343.7325713896658799315.stgit@bahia.lan>
Acked-by: NCornelia Huck <cohuck@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This reverts commit a59629fc.
This is not needed anymore because the IOThread mutex is not
"magic" anymore (need not kick the CPU thread)and also because
fork callbacks are only enabled at the very beginning of
QEMU's execution.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Because of -daemonize, system mode QEMU sometimes needs to fork() and
keep RCU enabled in the child.  However, there is a possible deadlock
with synchronize_rcu:

- the CPU thread is inside a RCU critical section and wants to take
  the BQL in order to do MMIO

- the monitor thread, which is owning the BQL, calls rcu_init_lock
  which tries to take the rcu_sync_lock

- the call_rcu thread has taken rcu_sync_lock in synchronize_rcu, but
  synchronize_rcu needs the CPU thread to end the critical section
  before returning.

This cannot happen for user-mode emulation, because it does not have
a BQL.

To fix it, assume that system mode QEMU only forks in preparation for
exec (except when daemonizing) and disable pthread_atfork as soon as
the double fork has happened.
Reported-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Tested-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

These will be implemented and then used by follow-up patches.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Unmask previously masked SHPC feature in _OSC method.
Signed-off-by: NAleksandr Bezzubikov <zuban32s@gmail.com>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Add virt-2.10 machine type.
Signed-off-by: NEric Auger <eric.auger@redhat.com>
Reviewed-by: NAndrew Jones <drjones@redhat.com>
Message-id: 1502106581-11714-1-git-send-email-eric.auger@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>