We override the error value r in fail_vq, this will cause the caller
can't detect the failure which may cause the caller may disable the
notifiers twice if vhost is failed to start. Fix this by using another
variable to keep track the return value of set_host_notifier().

Fixes b0b3db79 ("vhost-net: cleanup
host notifiers at last step")

Cc: qemu-stable@nongnu.org
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 16617e36)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This is done mainly for improving readability, and in preparation for the
next patch, but Markus pointed out another bonus for the string being
returned:

"No arbitrary length limit. Before the patch, it's 39 characters, and the
code breaks catastrophically when qdev_fw_name() is longer: the second
snprintf() is called with its first argument pointing beyond path[], and
its second argument underflowing to a huge size."

Cc: qemu-stable@nongnu.org
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
(cherry picked from commit 5ba03e2d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Due converting PIO to the new memory read/write api we no longer provide
separate I/O region lenghts for read and write operations. As a result,
reading from PIT Mode/Command register will end with accessing
pit->channels with invalid index.

Fix this by ignoring read from the Mode/Command register.

This is CVE-2015-3214.
Reported-by: NMatt Tait <matttait@google.com>
Fixes: 0505bcde
Cc: qemu-stable@nongnu.org
Signed-off-by: NPetr Matousek <pmatouse@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit d4862a87)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Although it is pretty unusual the stride for the guest image and the
mirror image maintained by spice-display can be different.  So use
separate variables for them.

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

Cc: qemu-stable@nongnu.org
Reported-by: Nperrier vincent <clownix@clownix.net>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit c6e48470)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The Ctrl-Alt-u keyboard shortcut restores the screen to its original
size. In the SDL2 UI this is done by destroying the window and
creating a new one. The old window emits SDL_WINDOWEVENT_HIDDEN when
it's destroyed, but trying to call SDL_GetWindowFromID() from that
event's window ID returns a null pointer. handle_windowevent() assumes
that the pointer is never null so it results in a crash.

Cc: qemu-stable@nongnu.org
Signed-off-by: NAlberto Garcia <berto@igalia.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 08d49df0)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 90df601f)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

It has the similar issue with b1649fae. Since the calculation
is repeated for a few times already, introduce a function so it can be
reused.
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 61f0ed1d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This adds a test case to test 103 for performing a COW operation in a
qcow2 image using an L2 cache with minimal size (which should be at
least two clusters so the COW can access both source and destination
simultaneously).
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NAlberto Garcia <berto@igalia.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit a4291eaf)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The L2 cache must cover at least two L2 tables, because during COW two
L2 tables are accessed simultaneously.
Reported-by: NAlexander Graf <agraf@suse.de>
Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Tested-by: NAlexander Graf <agraf@suse.de>
Reviewed-by: NAlberto Garcia <berto@igalia.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 57e21669)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This patch adds the two extra brazilian keys to the evdev keymap for
X11.  This patch gets the two keys going with the vnc, gtk and sdl1
UIs.

The SDL2 library complains it doesn't know these keys, so the SDL2
library must be fixed before we can update ui/sdl2-keymap.h

Cc: qemu-stable@nongnu.org
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NMichael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 33aa30ca)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The brazilian computer keyboard layout has two extra keys (compared to
the usual 105-key intl ps/2 keyboard).  This patch makes these two keys
known to qemu.

For historic reasons qemu has two ways to specify a key:  A QKeyCode
(name-based) or a number (ps/2 scancode based).  Therefore we have to
update multiple places to make new keys known to qemu:

  (1) The QKeyCode definition in qapi-schema.json
  (2) The QKeyCode <-> number mapping table in ui/input-keymap.c

This patch does just that.  With this patch applied you can send those
two keys to the guest using the send-key monitor command.

Cc: qemu-stable@nongnu.org
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NMichael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit b771f470)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The FITRIM ioctl updates the fstrim_range structure it receives. This
way the caller can determine how many bytes were trimmed. The
guest-fstrim logic reuses the same fstrim_range for each filesystem,
effectively limiting each filesystem to trim at most as much as the
previous was able to trim.

If a previous filesystem would have trimmed 0 bytes, than the next
filesystem would report an error 'Invalid argument' because a FITRIM
request with length 0 is not valid.

This change resets the fstrim_range structure for each filesystem.
Signed-off-by: NJustin Ossevoort <justin@quarantainenet.nl>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit 73a652a1)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Signed-off-by: NShannon Zhao <zhaoshenglong@huawei.com>
Signed-off-by: NShannon Zhao <shannon.zhao@linaro.org>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
(cherry picked from commit afcf905c)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Test zero write in byte range 512~1024 for 4k alignment.
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NKevin Wolf <kwolf@redhat.com>
Message-id: 1431522721-3266-4-git-send-email-famz@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit ab53c447)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

For zero write, callers pass in NULL qiov (qemu-io "write -z" or
scsi-disk "write same").

Commit fc3959e4 fixed bdrv_co_write_zeroes which is the common case
for this bug, but it still exists in bdrv_aio_write_zeroes. A simpler
fix would be in bdrv_co_do_pwritev which is the NULL dereference point
and covers both cases.

So don't access it in bdrv_co_do_pwritev in this case, use three aligned
writes.

[Initialize ret to 0 in bdrv_co_do_zero_pwritev() to avoid uninitialized
variable warning with gcc 4.9.2.
--Stefan]
Signed-off-by: NFam Zheng <famz@redhat.com>
Message-id: 1431522721-3266-3-git-send-email-famz@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 9eeb6dd1)
Conflicts:
	block/io.c

* moved hunks into corresponding location in block.c due to lack of
  61007b31 in v2.3.0
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This reverts commit fc3959e4.

From upstream commit d01c07f2:
  This reverts commit fc3959e4.

  The core write code already handles the case, so remove this
  duplication.

  Because commit 61007b31 moved the touched code from block.c to
  block/io.c, the change is manually reverted.
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NKevin Wolf <kwolf@redhat.com>

v2.3.0 does not contain 61007b31 so we can revert the change
directly.
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

During processing of certain commands such as FD_CMD_READ_ID and
FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could
get out of bounds leading to memory corruption with values coming
from the guest.

Fix this by making sure that the index is always bounded by the
allocated memory.

This is CVE-2015-3456.
Signed-off-by: NPetr Matousek <pmatouse@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Signed-off-by: NJohn Snow <jsnow@redhat.com>
(cherry picked from commit e9077462)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

A LDRD or STRD where rd is not an even number is UNPREDICTABLE.
We were letting this fall through, which is OK unless rd is 15,
in which case we would attempt to do a load_reg or store_reg
to a nonexistent r16 for the second half of the double-word.
Catch the odd-numbered-rd cases and UNDEF them instead.

To do this we rearrange the structure of the code a little
so we can put the UNDEF catches at the top before we've
allocated TCG temporaries.

Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1431348973-21315-1-git-send-email-peter.maydell@linaro.org
(cherry picked from commit 3960c336)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Virtqueue were indexed from zero, so don't delete virtqueue whose
index is n->max_queues * 2 + 1.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: NJason Wang <jasowang@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

(cherry picked from commit 27a46dcf)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The dev->config pointer isn't set until guest
system initializes usb devices (via
usb_desc_set_config). However qemu networking can
go through some motions prior to that, e.g.:

 #0  is_rndis (s=0x555557261970) at hw/usb/dev-network.c:653
 #1  0x000055555585f723 in usbnet_can_receive (nc=0x55555641e820) at hw/usb/dev-network.c:1315
 #2  0x000055555587635e in qemu_can_send_packet (sender=0x5555572660a0) at net/net.c:470
 #3  0x0000555555878e34 in net_hub_port_can_receive (nc=0x5555562d7800) at net/hub.c:101
 #4  0x000055555587635e in qemu_can_send_packet (sender=0x5555562d7980) at net/net.c:470
 #5  0x000055555587dbca in tap_can_send (opaque=0x5555562d7980) at net/tap.c:172

The command to reproduce most reliably was:

 qemu-system-i386 -usb -device usb-net,vlan=0 -net tap,vlan=0

This wasn't strictly a problem with tap. Other
networking endpoints (vde, user) could trigger
this problem as well.

Fixes: https://bugs.launchpad.net/qemu/+bug/1050823
Cc: qemu-stable@nongnu.org
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 278412d0)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Before a freed cluster can be reused, pending discards for this cluster
must be processed.

The original assumption was that this was not a problem because discards
are only cached during discard/write zeroes operations, which are
synchronous so that no concurrent write requests can cause cluster
allocations.

However, the discard/write zeroes operation itself can allocate a new L2
table (and it has to in order to put zero flags there), so make sure we
can cope with the situation.

This fixes https://bugs.launchpad.net/bugs/1349972.

Cc: qemu-stable@nongnu.org
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
(cherry picked from commit ecbda7a2)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Richard Jones caught this bug with afl fuzzer.

In fact, that's the only possible value to overflow (extent->l1_size =
0x20000000) l1_size:

l1_size = extent->l1_size * sizeof(long) => 0x80000000;

g_try_malloc returns NULL because l1_size is interpreted as negative
during type casting from 'int' to 'gsize', which yields a enormous
value. Hence, by coincidence, we get a "not too bad" behavior:

qemu-img: Could not open '/tmp/afl6.img': Could not open
'/tmp/afl6.img': Cannot allocate memory

Values larger than 0x20000000 will be refused by the validation in
vmdk_add_extent.

Values smaller than 0x20000000 will not overflow l1_size.

Cc: qemu-stable@nongnu.org
Reported-by: NRichard W.M. Jones <rjones@redhat.com>
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Tested-by: NRichard W.M. Jones <rjones@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 13c4941c)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This fixes the bug introduced by commit c6ac36e1 (vmdk: Optimize cluster
allocation).

Sometimes, write_len could be larger than cluster size, because it
contains both data and marker.  We must advance next_cluster_sector in
this case, otherwise the image gets corrupted.

Cc: qemu-stable@nongnu.org
Reported-by: NAntoni Villalonga <qemu-list@friki.cat>
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 5e82a31e)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This fixes ioctl behavior on powerpc e6500 platforms with 64bit kernel and 32bit
userspace. The current type cast has no effect there and the value passed to the
kernel is still 0. Probably an issue related to the compiler, since I'm assuming
the same configuration works on a similar setup on x86.

Also ensure consistency with previous type cast in TRACE message.
Signed-off-by: NBogdan Purcareata <bogdan.purcareata@freescale.com>
Message-Id: <1428058914-32050-1-git-send-email-bogdan.purcareata@freescale.com>
Cc: qemu-stable@nongnu.org
[Fix parens as noticed by Michael. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

(cherry picked from commit d064d9f3)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Commit v2.2.0-1530-ge5560329 vnc: switch to inet_listen_opts
bypassed the use of inet_parse in inet_listen, making literal
IPv6 addresses enclosed in brackets fail:

qemu-kvm: -vnc [::1]:0: Failed to start VNC server on `(null)': address
resolution failed for [::1]:5900: Name or service not known

Strip the brackets to make it work again.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 274c3b52)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

We actually were always impolitely dropping the connection and
not cleanly logging out.

CC: qemu-stable@nongnu.org
Signed-off-by: NPeter Lieven <pl@kamp.de>
Message-id: 1429193313-4263-2-git-send-email-pl@kamp.de
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 20474e9a)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The binary search in sdp_uuid_match() only works when the number of
elements to search is a power of two.

  lo = record->uuid;
  hi = record->uuids;
  while (hi >>= 1)
      if (lo[hi] <= val)
          lo += hi;

  return *lo == val;

I noticed that the record->uuids calculation in
sdp_service_record_build() was suspect:

  record->uuids = 1 << ffs(record->uuids - 1);

Unlike most ffs(val) - 1 users, the expression is ffs(val - 1)!

Actually ffs() is the wrong function to use for power-of-2.  Use
pow2ceil() to achieve the correct effect.  Now the record->uuid[] array
is sized correctly and the binary search in sdp_uuid_match() should
work.

I'm not sure how to run/test this code.

Cc: Andrzej Zaborowski <balrog@zabor.org>
Cc: qemu-stable@nongnu.org
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1427124571-28598-2-git-send-email-stefanha@redhat.com
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit 588ef9d4)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

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

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

VHOST_SET_LOG_BASE got an incorrect address, causing
migration errors and potentially even memory corruption.
Reported-by: NWen Congyang <wency@cn.fujitsu.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NAmos Kong <akong@redhat.com>
Message-id: 1429283565-32265-1-git-send-email-mst@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The image field in BlockDeviceInfo should never be null, however
bdrv_block_device_info() is not filling it in.

This makes the 'info block -n -v' command crash QEMU.

The proper solution is probably to move the relevant code from
bdrv_query_info() to bdrv_block_device_info(), but since we're too
close to the release for that this simpler workaround solves the
crash.
Signed-off-by: NAlberto Garcia <berto@igalia.com>
Message-id: 1429274688-8115-1-git-send-email-berto@igalia.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

MIPS patches 2015-04-17

Changes:
* fix broken fulong2e

# gpg: Signature made Fri Apr 17 12:14:37 2015 BST using RSA key ID 0B29DA6B
# gpg: Can't check signature: public key not found

* remotes/lalrae/tags/mips-20150417-2:
  mips: fix broken fulong2e machine
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

fw_cfg: add documentation file (docs/specs/fw_cfg.txt)

# gpg: Signature made Tue Apr 14 12:22:20 2015 BST using RSA key ID D3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>"
# gpg:                 aka "Gerd Hoffmann <gerd@kraxel.org>"
# gpg:                 aka "Gerd Hoffmann (private) <kraxel@gmail.com>"

* remotes/kraxel/tags/pull-fwcfg-20150414-1:
  fw_cfg: add documentation file (docs/specs/fw_cfg.txt)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

After commit 5312bd8b the bonito_readl() and bonito_writel() have been
accessing incorrect addresses. Consequently QEMU is crashing when trying
to boot Linux kernel on fulong2e machine.

Cc: qemu-stable@nongnu.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLeon Alrae <leon.alrae@imgtec.com>

The invalidation code introduced in commit 2360b works by inverting most bits
of env->msr to ensure that hreg_store_msr() will forcibly update the CPU env
state to reflect the new msr value post-migration. Unfortunately
hreg_store_msr() is called with alter_hv set to 0 which preserves the MSR_HVB
state from the CPU env which is now the opposite value to what it should be.

Ensure that we don't invalidate the msr MSR_HVB bit during cpu_post_load so
that the correct value is restored. This fixes suspend/resume for PPC64.
Reported-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Message-id: 1429255009-12751-1-git-send-email-mark.cave-ayland@ilande.co.uk
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

This document covers the guest-side hardware interface, as
well as the host-side programming API of QEMU's firmware
configuration (fw_cfg) device.
Signed-off-by: NJordan Justen <jordan.l.justen@intel.com>
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

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

Unfortunately it turns out that libseccomp 2.2 still does not work
correctly on non-x86 architectures; return to the previous configure
setup of insisting on libseccomp 2.1 or better and i386/x86_64 and
disabling seccomp support in all other situations.

This reverts the two commits:
 * "seccomp: libseccomp version varying according to arch"
   (commit 896848f0)
 * "seccomp: update libseccomp version and remove arch restriction"
   (commit 8e27fc20)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1428670681-23032-1-git-send-email-peter.maydell@linaro.org

Current QEMU crashes when specifying an illegal model with the
"-net nic,model=xxx" option, e.g.:

 $ qemu-system-x86_64 -net nic,model=n/a
 qemu-system-x86_64: Unsupported NIC model: n/a

 Program received signal SIGSEGV, Segmentation fault.

The gdb backtrace looks like this:

0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152
152	    return err->msg;
(gdb) bt
 0  0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152
 1  0x0000555555965ffd in error_report_err (err=0x0) at util/error.c:157
 2  0x0000555555809c90 in pci_nic_init_nofail (nd=0x555555e49860 <nd_table>, rootbus=0x5555564409b0,
    default_model=0x55555598c37b "e1000", default_devaddr=0x0) at hw/pci/pci.c:1663
 3  0x0000555555691e42 in pc_nic_init (isa_bus=0x555556f71900, pci_bus=0x5555564409b0)
    at hw/i386/pc.c:1506
 4  0x000055555569396b in pc_init1 (machine=0x5555562abbf0, pci_enabled=1, kvmclock_enabled=1)
    at hw/i386/pc_piix.c:248
 5  0x0000555555693d27 in pc_init_pci (machine=0x5555562abbf0) at hw/i386/pc_piix.c:310
 6  0x000055555572ddf5 in main (argc=3, argv=0x7fffffffe018, envp=0x7fffffffe038) at vl.c:4226

The problem is that pci_nic_init_nofail() does not check whether the err
parameter from pci_nic_init has been set up and thus passes a NULL pointer
to error_report_err(). Fix it by correctly checking the err parameter.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The type name for the SoC device, unlike those of its sub-devices,
did not follow the QOM naming conventions. While the usage is internal
only, this is exposed through QMP and HMP, so fix it before release.

Cc: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NAlistair Francis <alistair@alistair23.me>
Message-id: 1428676676-23056-1-git-send-email-afaerber@suse.de
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>