We've gotten reports from multiple testers (including Frank Yangjie
and myself) that RDMA IPv6 support over RocE (Ethernet) is broken
in linux.

A patch to Linux is still in review:

http://comments.gmane.org/gmane.linux.drivers.rdma/16448

If the user is listening on '[::]', then we will not have a opened a device
yet and have no way of verifying if the device is RoCE or not.

In this case, the source VM will throw an error for ALL types of
connections (both IPv4 and IPv6) if the destination machine does not have
a regular infiniband network available for use.

The only way to gaurantee that an error is thrown for broken kernels is
for the management software to choose a *specific* interface at bind time
and validate what time of hardware it is.

Unfortunately, this puts the user in a fix:

 If the source VM connects with an IPv4 address without knowing that the
 destination has bound to '[::]' the migration will unconditionally fail
 unless the management software is not explicitly listening on the the IPv4
 address while using a RoCE-based device.

 If the source VM connects with an IPv6 address, then we're OK because we can
 throw an error on the source (and similarly on the destination).

 But in mixed environments, this will be broken for a while until it is fixed
 inside linux.

We do provide a *tiny* bit of help in mixed environments, though in this patch:

We can list all of the devices in the system and check to see if all the
devices are RoCE or Infiniband.

If we detect that we have a *pure* RoCE environment, then we can safely
thrown an error even if the management sofware has specified '[::]' as the
bind address.

However, if there is are multiple hetergeneous devices, then we cannot make
this assumption and the user just has to be sure they know what they are doing.
Signed-off-by: NMichael R. Hines <mrhines@us.ibm.com>
Message-id: 1376078746-24948-6-git-send-email-mrhines@linux.vnet.ibm.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

getaddrinfo() already knows what it's doing,
but it can potentially return multiple addresses.
We need to handle that...
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>
Signed-off-by: NMichael R. Hines <mrhines@us.ibm.com>
Message-id: 1376078746-24948-5-git-send-email-mrhines@linux.vnet.ibm.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

RDMAControlHeader::len is provided from remote, so check if the value
match the actual transferred byte_len.
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>
Reviewed-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NIsaku Yamahata <yamahata@private.email.ne.jp>
Signed-off-by: NMichael R. Hines <mrhines@us.ibm.com>
Message-id: 1376078746-24948-4-git-send-email-mrhines@linux.vnet.ibm.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

RMDAControlHeader::len is provided from remote, so validate it.
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>
Reviewed-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NIsaku Yamahata <yamahata@private.email.ne.jp>
Signed-off-by: NMichael R. Hines <mrhines@us.ibm.com>
Message-id: 1376078746-24948-3-git-send-email-mrhines@linux.vnet.ibm.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

resp.len is given from remote host. So should be validated before use.
Otherwise memcpy can access beyond the buffer.

Cc: Michael R. Hines <mrhines@us.ibm.com>
Reviewed-by: NOrit Wasserman <owasserm@redhat.com>
Reviewed-by: NMichael R. Hines <mrhines@us.ibm.com>
Signed-off-by: NIsaku Yamahata <yamahata@private.email.ne.jp>
Signed-off-by: NMichael R. Hines <mrhines@us.ibm.com>
Message-id: 1376078746-24948-2-git-send-email-mrhines@linux.vnet.ibm.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Move the code to hw/i386, the sole remaining property is available
as !pci_enabled.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-id: 1376069702-22330-4-git-send-email-aliguori@us.ibm.com

Rebased.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

With the new semantics of pc_sysfw (no -pflash implies "old-style" ROM setup,
-pflash implies "new-style" ROM setup), there is no need anymore for a compat
property.  Old machines simply will never use -pflash, and thus will always
use old-style setup.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1376069702-22330-3-git-send-email-aliguori@us.ibm.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The variable is not written anymore.

This cleans up after 9e1c2ec8 (which accidentally left variable
pc_sysfw_flash_vs_rom_bug_compatible behind, value always zero), and
buries dead code from commit dafb82e0 (which resurrected the pc_sysfw
code for pc_sysfw_flash_vs_rom_bug_compatible by mistake).
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1376069702-22330-2-git-send-email-aliguori@us.ibm.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

QEMU executables for w32, w64 had included meta information built from
version.rc. These rules were changed several times some months ago.

The latest version added version.o to the tools, but not to the system
emulations.

This patch adds the meta information to all system emulations again.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Message-id: 1375985887-3984-1-git-send-email-sw@weilnetz.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Commit 6d4cd408 fixed qemu_opts_set_defaults() for an existing corner
case, but broke it for another one that can't be reached in current
code.

Quote from its commit message:

    I believe [opts_parse()] attempts to do the following:

        If options don't yet exist, create new options
        Else, if defaults, modify the existing options
        Else, if list->merge_lists, modify the existing options
        Else, fail

The only caller that passes true for defaults is
qemu_opts_set_defaults().

The commit message then claims:

    A straightforward call of qemu_opts_create() does exactly that.

Wrong.  When !list->merge_lists, and the option string doesn't contain
id=, and options without ID exist, then we don't actually modify the
existing options, we create new ones.

Not reachable, because we never pass lists with !list->merge_lists to
qemu_opts_set_defaults().

Guard against possible (if unlikely) future misuse with assert().
Reported-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1375428840-5275-1-git-send-email-armbru@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

1) The GPL says that "if the Program does not specify a version number
of this License, you may choose any version ever published by the Free
Software Foundation".  This is not true, QEMU includes parts that are
v2-only.

2) Provide a default for files with no licensing information.

3) It is not just hardware emulation that is under BSD license.

4) Restrict GPLv2-only contributions to user mode emulation (due to
code from Linux) and PCI passthrough (due to code from Neocleus).

5) The rules were initially set by Fabrice but are being amended by
other people (already in commit ee12e1f3, LICENSE: There is no libqemu.a
anymore, 2011-11-15).  Do not put words in his mouth.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Acked-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1375251592-2537-3-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Most of the block layer is under the BSD license, thus it is reasonable
to license block/raw.c the same way.  CCed people should ACK by replying
with a Signed-off-by line.

Cc: Christoph Hellwig <hch@lst.de>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>
Cc: Peter Lieven <pl@kamp.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NPeter Lieven <pl@kamp.de>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NJeff Cody <jcody@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1375251592-2537-2-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

pci,virtio fixes for 1.6

This includes some last-minute bugfixes for 1.6.
All very small patches that also look very safe to me.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Mon 12 Aug 2013 04:28:57 AM CDT using RSA key ID D28D5469
# gpg: Can't check signature: public key not found

# By Michael S. Tsirkin (2) and others
# Via Michael S. Tsirkin
* mst/tags/for_anthony:
  vhost: clear signalled_used_valid on vhost stop
  virtio: clear signalled_used_valid when switching from dataplane
  i82801b11: Fix i82801b11 PCI host bridge config space
  pc: disable pci-info for 1.6

Message-id: 1376308831-19978-1-git-send-email-mst@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

arm-devs queue

# gpg: Signature made Mon 12 Aug 2013 05:58:14 AM CDT using RSA key ID 14360CDE
# gpg: Can't check signature: public key not found

# By Peter Maydell
# Via Peter Maydell
* pmaydell/tags/pull-arm-devs-20130812:
  hw/virtio/virtio-mmio: Make QueueNumMax read 0 for unavailable queues
  hw/virtio/virtio: Don't allow guests to add/remove queues

Message-id: 1376305261-29561-1-git-send-email-peter.maydell@linaro.org
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

# By Mike Qiu
# Via Kevin Wolf
* kwolf/for-anthony:
  block: Bugfix 'format' and 'snapshot' used in drive option

Message-id: 1376071141-3214-1-git-send-email-kwolf@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

# By Laszlo Ersek
# Via Luiz Capitulino
* luiz/queue/qmp:
  dump: rebase from host-private RAMBlock offsets to guest-physical addresses
  dump: populate guest_phys_blocks
  dump: introduce GuestPhysBlockList
  dump: clamp guest-provided mapping lengths to ramblock sizes

Message-id: 1375974809-1757-1-git-send-email-lcapitulino@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

# By Gerd Hoffmann
# Via Gerd Hoffmann
* kraxel/usb.87:
  xhci: implement warm port reset

Message-id: 1375961495-20970-1-git-send-email-kraxel@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

* origin/master:
  mips: revert commit b332d24a
  tcg/mips: fix invalid op definition errors

Necessary because patches got pushed by Aurelien before I pushed
the -rc2 tag.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The virtio-mmio spec says that QueueNumMax must read zero for queues
which are unavailable; implement this, rather than always returning
VIRTQUEUE_MAX_SIZE.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1374853288-9912-3-git-send-email-peter.maydell@linaro.org
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>

When vhost device stops, its implementation synchronizes kernel state
back to virtio.c so we can continue emulating the device
in userspace.

This patch ensures that virtio.c's signalled_used_valid flag is reset so
that userspace does not suppress guest notifications due to stale
signalled_used values.

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

When the dataplane thread stops, its vring.c implementation synchronizes
vring state back to virtio.c so we can continue emulating the virtio
device.

This patch ensures that virtio.c's signalled_used_valid flag is reset so
that we do not suppress guest notifications due to stale signalled_used
values.
Suggested-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

pci_bridge_write_config() was not being used.

Cc: qemu-stable@nongnu.org
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The BIOS that we ship in 1.6 does not use pci info
from host (yet). Several issues turned up
(e.g. around winXP boot crashes). So it's safest to disable that
interface for 1.6 machine types for now, leave it on for 1.7
as we have enough time to fix issues if any.
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

When use -drive file='xxx',format=qcow2,snapshot=on the error
message "Can't use snapshot=on with driver-specific options"
can be show, and fail to start the qemu.

This should not be happened, and there is no file.driver option
in qemu command line.

It is because the commit 74fe54f2,
it puts 'driver' option if the command line use 'format' option.

This patch is to solve this bug.
Signed-off-by: NMike Qiu <qiudayu@linux.vnet.ibm.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>

A queue size of 0 is used to indicate a nonexistent queue, so
don't allow the guest to flip a queue between zero-size and
non-zero-size. Don't permit setting of negative queue sizes
either.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1374853288-9912-2-git-send-email-peter.maydell@linaro.org
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>

Now that this code path is not triggered anymore during the tests,
revert commit b332d24a. Booting a MIPS
target without kernel nor bios doesn't really make sense. At the same
time replace fprintf(stderr, ...) by error_report().
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

tcg/mips/tcg-target.h defines various operations conditionally depending
upon the isa revision, however these operations are included in
mips_op_defs[] unconditionally resulting in the following runtime errors
if CONFIG_DEBUG_TCG is defined:

Invalid op definition for movcond_i32
Invalid op definition for rotl_i32
Invalid op definition for rotr_i32
Invalid op definition for deposit_i32
Invalid op definition for bswap16_i32
Invalid op definition for bswap32_i32
tcg/tcg.c:1196: tcg fatal error

Fix with ifdefs like the i386 backend does for movcond_i32.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>

RAMBlock.offset                   --> GuestPhysBlock.target_start
RAMBlock.offset + RAMBlock.length --> GuestPhysBlock.target_end
RAMBlock.length                   --> GuestPhysBlock.target_end -
                                      GuestPhysBlock.target_start

"GuestPhysBlock.host_addr" is only used when writing the dump contents.

This patch enables "crash" to work with the vmcore by rebasing the vmcore
from the left side of the following diagram to the right side:

host-private
offset
relative
to ram_addr   RAMBlock                  guest-visible paddrs
            0 +-------------------+.....+-------------------+ 0
              |         ^         |     |        ^          |
              |       640 KB      |     |      640 KB       |
              |         v         |     |        v          |
  0x0000a0000 +-------------------+.....+-------------------+ 0x0000a0000
              |         ^         |     |XXXXXXXXXXXXXXXXXXX|
              |       384 KB      |     |XXXXXXXXXXXXXXXXXXX|
              |         v         |     |XXXXXXXXXXXXXXXXXXX|
  0x000100000 +-------------------+.....+-------------------+ 0x000100000
              |         ^         |     |        ^          |
              |       3583 MB     |     |      3583 MB      |
              |         v         |     |        v          |
  0x0e0000000 +-------------------+.....+-------------------+ 0x0e0000000
              |         ^         |.    |XXXXXXXXXXXXXXXXXXX|
              | above_4g_mem_size | .   |XXXX PCI hole XXXXX|
              |         v         |  .  |XXXX          XXXXX|
     ram_size +-------------------+   . |XXXX  512 MB  XXXXX|
                                   .   .|XXXXXXXXXXXXXXXXXXX|
                                    .   +-------------------+ 0x100000000
                                     .  |         ^         |
                                      . | above_4g_mem_size |
                                       .|         v         |
                                        +-------------------+ ram_size
                                                              + 512 MB

Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

While the machine is paused, in guest_phys_blocks_append() we register a
one-shot MemoryListener, solely for the initial collection of the valid
guest-physical memory ranges that happens at listener registration time.

For each range that is reported to guest_phys_blocks_region_add(), we
attempt to merge the range with the preceding one.

Ranges can only be joined if they are contiguous in both guest-physical
address space, and contiguous in host virtual address space.

The "maximal" ranges that remain in the end constitute the guest-physical
memory map that the dump will be based on.

Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

The vmcore must use physical addresses that are visible to the guest, not
addresses that point into linear RAMBlocks. As first step, introduce the
list type into which we'll collect the physical mappings in effect at the
time of the dump.

Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Even a trusted & clean-state guest can map more memory than what it was
given. Since the vmcore contains RAMBlocks, mapping sizes should be
clamped to RAMBlock sizes. Otherwise such oversized mappings can exceed
the entire file size, and ELF parsers might refuse even the valid portion
of the PT_LOAD entry.

Related RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=981582Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Without this patch windows can't do port resets for usb3 devices.

https://bugzilla.redhat.com/show_bug.cgi?id=949514Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

The I/O port variant of fw_cfg is used by sparc64, which is a big-endian machine.
Firmware swaps bytes before sending them to fw_cfg, so we need to unswap them in
the device.

This is only used on sparc64 and on (little-endian) x86, so it does not affect
any other target.  32-bit Sparc and PPC all use memory-mapped fw_cfg.
Reported-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Message-id: 1375014954-31916-2-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Running "make install" modified the *.po files because
they were no longer up to date.

Synchronize them with latest ui/gtk.c and modified build
rules which use paths relative to the project root.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Message-id: 1375731922-24259-1-git-send-email-sw@weilnetz.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Let's avoid -cpu host barfing at this PVR.
Linux recognizes it as "POWER5+ (gs) v2.1".
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1375321323-29954-5-git-send-email-afaerber@suse.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

It is ISA 2.03. Modelled as 970FX minus AltiVec flag.

Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1375321323-29954-4-git-send-email-afaerber@suse.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1375321323-29954-3-git-send-email-afaerber@suse.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1375321323-29954-2-git-send-email-afaerber@suse.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Commit 03a15a54 claimed to add a POWER7+
model but instead added a "POWER7P" model, with an unhelpful "POWER7P"
description on top. Fix this to "POWER7+" as we already have "POWER3+",
"POWER4+" and "POWER5+" and there being no reason to deviate with the
user-visible command line -cpu POWER7P from the marketing name POWER7+.

Further, don't needlessly deviate from the scheme of naming PVR constant,
QOM type and device description after the exact revision that is in fact
encoded in the PVR used.
That way, we can change the user-friendly alias -cpu POWER7+ to point to a
different revision if we so desire, while not polluting the type namespace.

This naming scheme is sensible and completely orthogonal to how PVRs may
or may not get matched to CPU types.

Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Message-id: 1375736387-8429-1-git-send-email-afaerber@suse.de
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>