block: Add return value for bdrv_flush_all()

bdrv_flush() can fail, and bdrv_flush_all() should return an error as
well if this happens for a block device. It returns the first error
return now, but still at least tries to flush the remaining devices even
in error cases.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit f0f0fdfeec6c67ad374114ecc4b3e3ccde5e94d2)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
cpus: Add return value for vm_stop()

If flushing the block devices fails, return an error. The VM is stopped
anyway.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 5698346391b306c2c84358c68ee897c095d714cc)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
cpus: Let vm_stop[_force_state]() always flush block devices

Even if the VM is already stopped, we cannot assume that all data has
already been successfully flushed to disk. The flush during the previous
vm_stop() could have failed.

Run bdrv_flush_all() unconditionally so that we get an error each time
if the block device isn't really flushed.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 594a45ce64dbef1829996403506a1154eb2fd1cc)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
megasas: Legacy command line handling fix

Only apply legacy command line handling when the device has not been
hot-plugged. Propagate failure of legacy command line handling.

Cc: qemu-stable@nongnu.org
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit 22d6aa03fd87ba5f219d26bc1810646d0f95842a)

Conflicts:

	hw/scsi/megasas.c

* modified to avoid dependency on fancy new upcast macros

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
gtk: don't use g_object_unref on GdkCursor

It's not a GObject.

Cc: Gerd Hoffman <kraxel@redhat.com>
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
v1 -> v2
 - Fix summary to agree with code (Peter)
(cherry picked from commit 171392406d8e230d62e5ebf4805f71460854b8ec)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
gtk: Fix compiler warning (GTK 3 deprecated function)

With GTK 3, the function gdk_cursor_unref is deprecated:

qemu/ui/gtk.c: In function ‘gd_cursor_define’:
qemu/ui/gtk.c:380:5: error:
 ‘gdk_cursor_unref’ is deprecated (declared at /usr/include/gtk-3.0/gdk/gdkcursor.h:233): Use 'g_object_unref' instead [-Werror=deprecated-declarations]

Fix the gcc compiler warning by using conditional compilation.

Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1371391987-10795-1-git-send-email-sw@weilnetz.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit 030b4b7debf659dcd6fc66826564285fdce5057d)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
dataplane: refuse to start if device is already in use

Dataplane must check whether a block device is in use before launching
the dataplane thread.  This is necessary since the thread does not
synchronize with the main loop and I/O requests could cause corruption.

One example is when a drive is added and a block job is started before
hotplugging the virtio-blk-pci adapter.  In this case we must not use
dataplane mode.

Cc: qemu-stable@nongnu.org
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit b0f2027cde31c645524256763672e09eeb204a9a)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
xhci: handle USB_RET_IOERROR

https://bugzilla.redhat.com/show_bug.cgi?id=980377

Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit ed60ff024fdb0e7ca9c002af166e10683cf49805)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
qemu-char: Register ring buffer driver with correct name "ringbuf"

The driver is new in 1.4, with the documented name "ringbuf".
However, it's actual name is the completely undocumented "memory".
Screwed up in commit 3949e59.  Fix code to match documentation.

Keep the undocumented name working as an alias for compatibility.

Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1374849874-25531-3-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit c11ed9666d69abaf217c8800f299c519b487b7d3)

Conflicts:

	qemu-char.c

* removed dependency on command-line specifiable mux (bb6fb7c0)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
qapi: Rename ChardevBackend member "memory" to "ringbuf"

Commit 1da48c6 called the new member "memory" after commit 3949e59
standardized "ringbuf".  Rename for consistency.

However, member name "memory" is visible in QMP since 1.5.  It's
undocumented just like the driver name.  Keep it working anyway.

Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1374849874-25531-4-git-send-email-armbru@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit 3a1da42eb35a67d0dbc899dd571ea386fa11c4dd)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
virtio-console: Use exitfn for virtserialport, too

virtconsole and virtserialport are identical in every other aspect
except for the distinguishing VirtIOSerialPortClass::is_console field.

Cc: qemu-stable@nongnu.org
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Message-id: 1375313326-14966-1-git-send-email-afaerber@suse.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit 203439ce0a832e36b276f10892846bd91ee836eb)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
pci-bridge: update mappings for migration/restore

Fix for LP#1187529: Devices on PCI bridge stop working when
live-migrated. Update bridge mappings for all PCI bridge
devices in get_pci_config_device().

Signed-off-by: Don Koch <dkoch@verizon.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit e78e9ae4a933504d383703870d491615b0261801)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
xhci: fix segfault

Guest trying to reset a endpoint of a disconnected device resulted in
xhci trying to dereference uport while being NULL, thereby crashing
qemu.  Fix that by adding a check.  Drop unused dev variable while
touching that code bit.

Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 75cc1c1fcba1987bdf3979c4289ab756c2b15742)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
chardev: fix CHR_EVENT_OPENED events for mux chardevs

As of bd5c51ee6c4f1c79cae5ad2516d711a27b4ea8ec, chardevs no longer use
bottom-halves to issue CHR_EVENT_OPENED events. To maintain past
semantics, we instead defer the CHR_EVENT_OPENED events toward the end
of chardev initialization.

For muxes, this isn't good enough, since a range of FEs must be able
to attach to the mux prior to any CHR_EVENT_OPENED being issued, else
each FE will immediately print it's initial output (prompts, banners,
etc.) just prior to us switching to the next FE as part of
initialization.

The is new and confusing behavior for users, as they'll see output for
things like the HMP monitor, even though their the current mux focus
may be a guest serial port with potentially no output.

We fix this by further deferring CHR_EVENT_OPENED events for FEs
associated with muxes until after machine init by flagging mux chardevs
with 'explicit_be_open', which suppresses emission of CHR_EVENT_OPENED
events until we explicitly set the mux as opened later.

Currently, we must defer till after machine init since we potentially
associate FEs with muxes as part of realize (for instance,
serial_isa_realizefn).

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Message-id: 1375207462-8141-1-git-send-email-mdroth@linux.vnet.ibm.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit 7b7ab18d0b9769b5f39e663fa55caed461b1202e)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
seccomp: add arch_prctl() to the syscall whitelist

It appears that even a very simple /etc/qemu-ifup configuration can
require the arch_prctl() syscall, see the example below:

	#!/bin/sh
	/sbin/ifconfig $1 0.0.0.0 up
	/usr/sbin/brctl addif <switch> $1

Signed-off-by: Paul Moore <pmoore@redhat.com>
Reviewed-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
Message-id: 20130718135703.8247.19213.stgit@localhost
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit d2509b667caf482b6f827ff2645cbeb9b39ce29e)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
seccomp: add additional asynchronous I/O syscalls

A previous commit, "seccomp: add the asynchronous I/O syscalls to the
whitelist", added several asynchronous I/O syscalls but left out the
io_submit() and io_cancel() syscalls.  This patch corrects this by
adding the two missing asynchronous I/O syscalls.

Signed-off-by: Paul Moore <pmoore@redhat.com>
Reviewed-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
Message-id: 20130715193201.943.4913.stgit@localhost
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit 94113bd8a1d9acd05a879bc309cc659ace09e287)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
iov: handle EOF in iov_send_recv

Without this patch, iov_send_recv() never returns when do_send_recv()
returns zero.

Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 840042901710c2dc1a3ac3e5af9bed449c339701)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target-i386: Fix X86CPU error handling

Error **errp argument is not for emitting warnings, it means an error
has occurred and the caller should not make any assumptions about the
state of other return values (unless otherwise documented).

Therefore cpu_x86_create() must unref the new X86CPU itself, and
pc_new_cpu() must check for an Error rather than NULL return value.

While at it, clean up a superfluous NULL check.

Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-stable@nongnu.org
Cc: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
(cherry picked from commit cd7b87ffe9b6b7b0089ec8c71555f3b942bc6daf)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
ignore SIGPIPE in qemu-img and qemu-io

This prevents the tools from being stopped when they write data to a
closed connection in the other side.

Signed-off-by: MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 526eda14a68d5b3596be715505289b541288ef2a)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
semaphore: fix a hangup problem under load on NetBSD hosts.

Fix following bugs in "fallback implementation of counting semaphores
with mutex+condvar" added in c166cb72f1676855816340666c3b618beef4b976:
 - waiting threads are not restarted properly if more than one threads
   are waiting unblock signals in qemu_sem_timedwait()
 - possible missing pthread_cond_signal(3) calls when waiting threads
   are returned by ETIMEDOUT
 - fix an uninitialized variable
The problem is analyzed by and fix is provided by Noriyuki Soda.

Also put additional cleanup suggested by Laszlo Ersek:
 - make QemuSemaphore.count unsigned (it won't be negative)
 - check a return value of in pthread_cond_wait() in qemu_sem_wait()

Signed-off-by: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-id: 1372841894-10634-1-git-send-email-tsutsui@ceres.dti.ne.jp
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit 79761c6681f0d1cc1c027116fcb4382d41ed3ece)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>