~ubuntu-virt/qemu/+git/qemu-lp-import:stable-2.4

Last commit made on 2015-10-31
Get this branch:
git clone -b stable-2.4 https://git.launchpad.net/~ubuntu-virt/qemu/+git/qemu-lp-import

Branch merges

Branch information

Name:
stable-2.4
Repository:
lp:~ubuntu-virt/qemu/+git/qemu-lp-import

Recent commits

32d2413... by Michael Roth

Update version for 2.4.1 release

Signed-off-by: Michael Roth <email address hidden>

fc63922... by Pavel Butsykin <email address hidden>

virtio: sync the dataplane vring state to the virtqueue before virtio_save

When creating snapshot with the dataplane enabled, the snapshot file gets
not the actual state of virtqueue, because the current state is stored in
VirtIOBlockDataPlane. Therefore, before saving snapshot need to sync
the dataplane vring state to the virtqueue. The dataplane will resume its
work at the next notify virtqueue.

When snapshot loads with loadvm we get a message:
VQ 0 size 0x80 Guest index 0x15f5 inconsistent with Host index 0x0:
    delta 0x15f5
error while loading state for instance 0x0 of device
    '0000:00:08.0/virtio-blk'
Error -1 while loading VM state

to reproduce the error I used the following hmp commands:
savevm snap1
loadvm snap1

qemu parameters:
--enable-kvm -smp 4 -m 1024 -drive file=/var/lib/libvirt/images/centos6.4.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk0,id=virtio-disk0 -set device.virtio-disk0.x-data-plane=on

Signed-off-by: Pavel Butsykin <email address hidden>
Signed-off-by: Denis V. Lunev <email address hidden>
Message-id: <email address hidden>
CC: Stefan Hajnoczi <email address hidden>
CC: "Michael S. Tsirkin" <email address hidden>
CC: Kevin Wolf <email address hidden>
CC: Paolo Bonzini <email address hidden>
Signed-off-by: Stefan Hajnoczi <email address hidden>
(cherry picked from commit 10a06fd65f667a972848ebbbcac11bdba931b544)
Signed-off-by: Michael Roth <email address hidden>

36e1eee... by jcmvbkbc

target-xtensa: add window overflow check to L32E/S32E

Despite L32E and S32E primary use is for window underflow and overflow
exception handlers they are just normal instructions, and thus need to
check for window overflow.

Cc: <email address hidden>
Signed-off-by: Max Filippov <email address hidden>
(cherry picked from commit f822b7e497fa6a662094b491f86441015f363362)
Signed-off-by: Michael Roth <email address hidden>

9137bd2... by mst

net: don't set native endianness

commit 5be7d9f1b1452613b95c6ba70b8d7ad3d0797991
    vhost-net: tell tap backend about the vnet endianness
makes vhost net always try to set LE - even if that matches the
native endian-ness.

This makes it fail on older kernels on x86 without TUNSETVNETLE support.

To fix, make qemu_set_vnet_le/qemu_set_vnet_be skip the
ioctl if it matches the host endian-ness.

Reported-by: Marcel Apfelbaum <email address hidden>
Cc: Greg Kurz <email address hidden>
Cc: <email address hidden>
Signed-off-by: Michael S. Tsirkin <email address hidden>
Reviewed-by: Marcel Apfelbaum <email address hidden>
(cherry picked from commit 052bd52fa978d3f04bc476137ad6e1b9a697f9bd)
Signed-off-by: Michael Roth <email address hidden>

08231cb... by Markus Armbruster <email address hidden>

device-introspect-test: New, covering device introspection

The test doesn't check that the output makes any sense, only that QEMU
survives. Useful since we've had an astounding number of crash bugs
around there.

In fact, we have a bunch of them right now: a few devices crash or
hang, and some leave dangling pointers behind. The test skips testing
the broken parts. The next commits will fix them up, and drop the
skipping.

Signed-off-by: Markus Armbruster <email address hidden>
Reviewed-by: Eric Blake <email address hidden>
Message-Id: <email address hidden>
(cherry picked from commit 2d1abb850fd15fd6eb75a92290be5f93b2772ec5)
Signed-off-by: Michael Roth <email address hidden>

70a4483... by Markus Armbruster <email address hidden>

libqtest: New hmp() & friends

New convenience function hmp() to facilitate use of
human-monitor-command in tests. Use it to simplify its existing uses.

To blend into existing libqtest code, also add qtest_hmpv() and
qtest_hmp(). That, and the egregiously verbose GTK-Doc comment format
make this patch look bigger than it is.

Signed-off-by: Markus Armbruster <email address hidden>
Reviewed-by: Eric Blake <email address hidden>
Reviewed-by: Thomas Huth <email address hidden>
Message-Id: <email address hidden>
(cherry picked from commit 5fb48d9673b76fc53507a0e717a12968e57d846e)
Signed-off-by: Michael Roth <email address hidden>

3980985... by Markus Armbruster <email address hidden>

tests: Fix how qom-test is run

We want to run qom-test for every architecture, without having to
manually add it to every architecture's list of tests. Commit 3687d53
accomplished this by adding it to every architecture's list
automatically.

However, some architectures inherit their tests from others, like this:

    check-qtest-x86_64-y = $(check-qtest-i386-y)
    check-qtest-microblazeel-y = $(check-qtest-microblaze-y)
    check-qtest-xtensaeb-y = $(check-qtest-xtensa-y)

For such architectures, we ended up running the (slow!) test twice.
Commit 2b8419c attempted to avoid this by adding the test only when
it's not already present. Works only as long as we consider adding
the test to the architectures on the left hand side *after* the ones
on the right hand side: x86_64 after i386, microblazeel after
microblaze, xtensaeb after xtensa.

Turns out we consider them in $(SYSEMU_TARGET_LIST) order. Defined as

    SYSEMU_TARGET_LIST := $(subst -softmmu.mak,,$(notdir \
       $(wildcard $(SRC_PATH)/default-configs/*-softmmu.mak)))

On my machine, this results in the oder xtensa, x86_64, microblazeel,
microblaze, i386. Consequently, qom-test runs twice for microblazeel
and x86_64.

Replace this complex and flawed machinery with a much simpler one: add
generic tests (currently just qom-test) to check-qtest-generic-y
instead of check-qtest-$(target)-y for every target, then run
$(check-qtest-generic-y) for every target.

Signed-off-by: Markus Armbruster <email address hidden>
Reviewed-by: Andreas Färber <email address hidden>
Message-Id: <email address hidden>
(cherry picked from commit e253c287153c6f3ce4177686ac12c196f9bd8292)
Signed-off-by: Michael Roth <email address hidden>

db97d9d... by Paolo Bonzini <email address hidden>

macio: move DBDMA_init from instance_init to realize

DBDMA_init is not idempotent, and calling it from instance_init
breaks a simple object_new/object_unref pair. Work around this,
pending qdev-ification of DBDMA, by moving the call to realize.

Reported-by: Markus Armbruster <email address hidden>
Signed-off-by: Paolo Bonzini <email address hidden>
Reviewed-by: Thomas Huth <email address hidden>
Signed-off-by: Markus Armbruster <email address hidden>
Message-Id: <email address hidden>
(cherry picked from commit c7104402353bf32ac1d3a276e3619a20e910506b)
Signed-off-by: Michael Roth <email address hidden>

243b80c... by Paolo Bonzini <email address hidden>

hw: do not pass NULL to memory_region_init from instance_init

This causes the region to outlive the object, because it attaches the
region to /machine. This is not nice for the "realize" method, but
much worse for "instance_init" because it can cause dangling pointers
after a simple object_new/object_unref pair.

Reported-by: Markus Armbruster <email address hidden>
Signed-off-by: Paolo Bonzini <email address hidden>
Reviewed-by: Peter Maydell <email address hidden>
Tested-by: Markus Armbruster <email address hidden>
Signed-off-by: Markus Armbruster <email address hidden>
Message-Id: <email address hidden>
Reviewed-by: Thomas Huth <email address hidden>
(cherry picked from commit 81e0ab48dda611e9571dc2e166840205a4208567)

Conflicts:
 hw/display/cg3.c
 hw/display/tcx.c

* removed context dependencies on &error_fatal/&error_abort

Signed-off-by: Michael Roth <email address hidden>

91232d9... by Paolo Bonzini <email address hidden>

memory: allow destroying a non-empty MemoryRegion

This is legal; the MemoryRegion will simply unreference all the
existing subregions and possibly bring them down with it as well.
However, it requires a bit of care to avoid an infinite loop.
Finalizing a memory region cannot trigger an address space update,
but memory_region_del_subregion errs on the side of caution and
might trigger a spurious update: avoid that by resetting mr->enabled
first.

Signed-off-by: Paolo Bonzini <email address hidden>
Signed-off-by: Markus Armbruster <email address hidden>
Message-Id: <email address hidden>
(cherry picked from commit 2e2b8eb70fdb7dfbec39f3a19b20f9a73f2f813e)
Signed-off-by: Michael Roth <email address hidden>