This is a bug fix for aarch64.  At present, we have branches using
the 32-bit (translate.c) versions of cpu_[NZCV]F, but we set the flags
using the 64-bit (translate-a64.c) versions of cpu_[NZCV]F.  From
the view of the TCG code generator, these are unrelated variables.

The bug is hard to see because we currently only read these variables
from branches, and upon reaching a branch TCG will first spill live
variables and then reload the arguments of the branch.  Since the
32-bit versions were never live until reaching the branch, we'd re-read
the data that had just been spilled from the 64-bit versions.

There is currently no such problem with the cpu_exclusive_* variables,
but there's no point in tempting fate.

Cc: qemu-stable@nongnu.org
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Message-id: 1441909103-24666-2-git-send-email-rth@twiddle.net
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 78bcaa3e)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Let dataplane allocate different region for the desc/avail/used
ring regions.
Take VIRTIO_RING_F_EVENT_IDX into account to increase the used/avail
rings accordingly.

[Fix 32-bit builds by changing 16lx format specifier to HWADDR_PRIx.
--Stefan]
Signed-off-by: NPierre Morel <pmorel@linux.vnet.ibm.com>
Tested-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Message-id: 1441625636-23773-1-git-send-email-pmorel@linux.vnet.ibm.com
(changed __virtio16 into uint16_t,
 map descriptor table and available ring read-only)
Signed-off-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

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

When QEMU starts the RCU thread executes qemu_mutex_lock_thread
causing error "qemu:qemu_cpu_kick_thread: No such process" and exits.

This isn't occur frequently but in glibc the thread id can exist and
this not guarantee that the thread is on active/running state. If is
inserted a sleep(1) after newthread assignment [1] the issue appears.

So not make assumption that thread exist if first_cpu->thread is set
then change the validation of cpu to created that is set into cpu
threads (kvm, tcg, dummy).

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_create.c;h=d10f4ea8004e1d8f3a268b95cc0f8d93b8d89867;hb=HEAD#l621

Cc: qemu-stable@nongnu.org
Signed-off-by: NAníbal Limón <anibal.limon@linux.intel.com>
Message-Id: <1441313313-3040-1-git-send-email-anibal.limon@linux.intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 46036b24)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

When operation in standard mode, we currently return the size
of packet during buffer overflow.  This consumes the overflow
packet.  Return 0 instead so we can re-process the overflow packet
when we have room.

This fixes issues with lost/dropped fragments of large messages.
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Reviewed-by: NJason Wang <jasowang@redhat.com>
Message-id: 1441121206-6997-3-git-send-email-vyasevic@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 26c4e7ca)
*removed dependency on b76f21a7
*removed context dependency on 4cbea598Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

rtl8139_do_receive() tries to check for the overflow condition
by making sure that packet_size + 8 does not exceed the
available buffer space.  The issue here is that RxBuffAddr,
used to calculate available buffer space, is aligned to a
a 4 byte boundry after every update.  So it is possible that
every packet ends up being slightly padded when written
to the receive buffer.  This padding is not taken into
account when checking for overflow and we may end up missing
the overflow condition can causing buffer overwrite.

This patch takes alignment into consideration when
checking for overflow condition.
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Reviewed-by: NJason Wang <jasowang@redhat.com>
Message-id: 1441121206-6997-2-git-send-email-vyasevic@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit fabdcd33)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

When executing the start function, we should start with a clear state
regarding subchannel and device status; it is easy to forget updating one
of them after the ccw has been processed.

Note that we don't need to care about resetting the various control
fields: They are cleared by tsch(), and if they were still pending,
we wouldn't be able to execute the start function in the first
place.

Also note that we don't want to clear cstat/dstat if a suspended
subchannel is resumed.

This fixes a bug where we would continue to present channel-program
check in cstat even though later ccw requests for the subchannel
finished without error (i.e. cstat should be 0).

Cc: qemu-stable@nongnu.org
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
(cherry picked from commit 6b7741c2)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The current U-Boot binary in QEMU has a bug where it fails to support
dynamic CCSR addressing. Without this support, u-boot can not boot the
ppce500 machine anymore. This has been fixed upstream in u-boot commit
e834975b.

Update the u-boot blob we carry in QEMU to the latest u-boot upstream,
so that we can successfully run u-boot with the ppce500 machine again.

CC: qemu-stable@nongnu.org
Signed-off-by: NAlexander Graf <agraf@suse.de>
Tested-by: NThomas Huth <thuth@redhat.com>
(cherry picked from commit d4574435)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

commit 9b8424d5
    "exec: split length -> used_length/max_length"
changed field names in struct RAMBlock

It turns out that scripts/dump-guest-memory.py was
poking at this field, update it accordingly.

Cc: qemu-stable@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Message-Id: <1440666378-3152-1-git-send-email-mst@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 0c71d41e)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

vhost-scsi bootindex does't work because Qemu passes
wrong fireware path to seabios.

before:
  /pci@i0cf8/scsi@7channel@0/vhost-scsi@0,0
after applying the patch:
  /pci@i0cf8/scsi@7/channel@0/vhost-scsi@0,0
Reported-by: NSubo <subo7@huawei.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Message-Id: <1440553971-11108-1-git-send-email-arei.gonglei@huawei.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit f42bf6a2)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The code to flush the DBDMA channel was effectively duplicated in
dbdma_control_write(), except for the fact that the copy executed outside of a
RUN bit transition was broken by not clearing the FLUSH bit once the flush was
complete.

Newer PPC Linux kernels would timeout waiting for the FLUSH bit to clear again
after submitting a FLUSH command. Fix this by always clearing the FLUSH bit
once the channel flush is complete and removing the repeated code.
Reported-by: NAurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: NAurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NAlexander Graf <agraf@suse.de>
(cherry picked from commit 1cde732d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Example:
$ ./qemu-img create -f qcow2 /tmp/t.qcow2 64M
$ ./qemu-img amend -f qcow2 -o backing_file=/tmp/t.qcow2, -o help \
    /tmp/t.qcow2

This should not crash. This actually is tested by iotest 082, but not
caught due to the segmentation fault being silent (which is something
that needs to be fixed, too).
Reported-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Cc: qemu-stable <qemu-stable@nongnu.org>
Signed-off-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
(cherry picked from commit e814dffc)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

st.st_blocks is always counted in 512 byte units. Do not
use st.st_blksize as multiplicator which may be larger.

Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Lieven <pl@kamp.de>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Message-id: 1440067607-14547-1-git-send-email-pl@kamp.de
Signed-off-by: NJeff Cody <jcody@redhat.com>
(cherry picked from commit 055c6f91)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This subtraction of return addresses applies directly to TCI as well as
host-TCG. This fixes Linux boots for at least Microblaze, CRIS, ARM and
SH4 when using TCI.

[sw: Removed indentation for preprocessor statement]
[sw: The patch also fixes Linux boot for x86_64]
Reviewed-by: NRichard Henderson <rth@twiddle.net>
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
(cherry picked from commit a17d4482)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

It has been reported that at least tgtd returns a block size of 0
for LUN 0. To avoid running into divide by zero later on and protect
against other problematic block sizes validate the block size right
at connection time.

Cc: qemu-stable@nongnu.org
Reported-by: NAndrey Korolyov <andrey@xdel.ru>
Signed-off-by: NPeter Lieven <pl@kamp.de>
Message-Id: <1439552016-8557-1-git-send-email-pl@kamp.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 6d1f252d)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

A spurious trailing "\n" in the gdb syscall format string used
for SYS_WRITE0 meant that gdb would reject the remote syscall,
with the effect that the output from the guest was silently dropped.
Remove the newline so that gdb accepts the packet.

Cc: qemu-stable@nongnu.org
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 857b55ad)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

This fixes a regression introduced by commit dcfb3beb ("mirror: Do zero
write on target if sectors not allocated"), which was reported to cause
aborts with the message "Co-routine re-entered recursively".

The cause for this bug is the following code in mirror_iteration_done():

    if (s->common.busy) {
        qemu_coroutine_enter(s->common.co, NULL);
    }

This has always been ugly because - unlike most places that reenter - it
doesn't have a specific yield that it pairs with, but is more
uncontrolled.  What we really mean here is "reenter the coroutine if
it's in one of the four explicit yields in mirror.c".

This used to be equivalent with s->common.busy because neither
mirror_run() nor mirror_iteration() call any function that could yield.
However since commit dcfb3beb this doesn't hold true any more:
bdrv_get_block_status_above() can yield.

So what happens is that bdrv_get_block_status_above() wants to take a
lock that is already held, so it adds itself to the queue of waiting
coroutines and yields. Instead of being woken up by the unlock function,
however, it gets woken up by mirror_iteration_done(), which is obviously
wrong.

In most cases the code actually happens to cope fairly well with such
cases, but in this specific case, the unlock must already have scheduled
the coroutine for wakeup when mirror_iteration_done() reentered it. And
then the coroutine happened to process the scheduled restarts and tried
to reenter itself recursively.

This patch fixes the problem by pairing the reenter in
mirror_iteration_done() with specific yields instead of abusing
s->common.busy.

Cc: qemu-stable@nongnu.org
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NJeff Cody <jcody@redhat.com>
Message-id: 1439455310-11263-1-git-send-email-kwolf@redhat.com
Signed-off-by: NJeff Cody <jcody@redhat.com>
(cherry picked from commit e424aff5)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The last portion of an unaligned WRITE SAME command could fail the
assertion in bdrv_aligned_pwritev:

    assert(!qiov || bytes == qiov->size);

Because we updated data->iov.iov_len right above this if block, but
data->qiov still has the old size.

Reinitialize the qiov to make them equal and keep block layer happy.

Cc: qemu-stable@nongnu.org
Signed-off-by: NFam Zheng <famz@redhat.com>
Message-Id: <1438159512-3871-2-git-send-email-famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit a56537a1)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

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

Ne2000 NIC uses ring buffer of NE2000_MEM_SIZE(49152)
bytes to process network packets. While receiving packets
via ne2000_receive() routine, a local 'index' variable
could exceed the ring buffer size, leading to an infinite
loop situation.
Reported-by: NQinghao Tang <luodalongde@gmail.com>
Signed-off-by: NP J P <pjp@fedoraproject.org>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 737d2b3c)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

Ne2000 NIC uses ring buffer of NE2000_MEM_SIZE(49152)
bytes to process network packets. While receiving packets
via ne2000_receive() routine, a local 'index' variable
could exceed the ring buffer size, which could lead to a
memory buffer overflow. Added other checks at initialisation.
Reported-by: NQinghao Tang <luodalongde@gmail.com>
Signed-off-by: NP J P <pjp@fedoraproject.org>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 9bbdbc66)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

While processing transmit descriptors, it could lead to an infinite
loop if 'bytes' was to become zero; Add a check to avoid it.

[The guest can force 'bytes' to 0 by setting the hdr_len and mss
descriptor fields to 0.
--Stefan]
Signed-off-by: NP J P <pjp@fedoraproject.org>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Message-id: 1441383666-6590-1-git-send-email-stefanha@redhat.com
(cherry picked from commit b947ac2b)
Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>

The _cmp_bytes variable added by commit "bea60dd7 ui/vnc: fix potential
memory corruption issues" can become negative.  Result is (possibly
exploitable) memory corruption.  Reason for that is it uses the stride
instead of bytes per scanline to apply limits.

For the server surface is is actually fine.  vnc creates that itself,
there is never any padding and thus scanline length always equals stride.

For the guest surface scanline length and stride are typically identical
too, but it doesn't has to be that way.  So add and use a new variable
(guest_ll) for the guest scanline length.  Also rename min_stride to
line_bytes to make more clear what it actually is.  Finally sprinkle
in an assert() to make sure we never use a negative _cmp_bytes again.
Reported-by: N范祚至(库特) <zuozhi.fzz@alibaba-inc.com>
Reviewed-by: NP J P <ppandit@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit eb8934b0)
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>

virtio fix for 2.4

Fixes migration in virtio 1 mode.
We still have a known bug with memory hotplug, it doesn't
look like we can fix that in time for 2.4.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

# gpg: Signature made Wed 05 Aug 2015 15:57:39 BST using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg:                 aka "Michael S. Tsirkin <mst@redhat.com>"

* remotes/mst/tags/for_upstream:
  virtio: fix 1.0 virtqueue migration
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Commit 488981a4 [block: convert quorum blockdrv to use crypto APIs]
broke qemu-iotest 041 on hosts with GnuTLS < 2.10.0. It converted a
compile-time check to a run-time check at device open time. The result
is that we now advertise a feature (the quorum block driver) that will
never work (on those hosts). There's no way (short of parsing
human-readable error messages) for qemu-iotests or any other API
consumer to recognise that the quorum block driver isn't _actually_
available and shouldn't be used or tested.

Move the run-time check to bdrv_quorum_init() to avoid registering the
quorum block driver if we know it cannot work. This way API consumers
can recognise it's unavailable.

Fixes: 488981a4Signed-off-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NAlberto Garcia <berto@igalia.com>
Message-id: 1438699705-21761-1-git-send-email-silbe@linux.vnet.ibm.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

1.0 does not requires physically-contiguous pages layout for a
virtqueue. So we could not infer avail and used from desc. This means
we need to migrate vring.avail and vring.used when host support virtio
1.0. This fixes malfunction of virtio 1.0 device after migration.

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Dr. David Alan Gilbert <dgilbert@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>

X86 queue, 2015-08-04

# gpg: Signature made Tue 04 Aug 2015 16:49:42 BST using RSA key ID 984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>"
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg:          It is not certain that the signature belongs to the owner.
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D C5A6

* remotes/ehabkost/tags/x86-pull-request:
  target-i386: fix IvyBridge xlevel in PC_COMPAT_2_3
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Previous patch changed xlevel and missed the compatibility code.

Fixes: 3046bb5d ("target-i386: emulate CPUID level of real hardware")
Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

MIPS patches 2015-08-04

Changes:
* fix semihosting for microMIPS R6
* fix an abort when booting mips64 kernel with --enable-tcg-debug

# gpg: Signature made Tue 04 Aug 2015 12:32:17 BST using RSA key ID 0B29DA6B
# gpg: Good signature from "Leon Alrae <leon.alrae@imgtec.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 8DD3 2F98 5495 9D66 35D4  4FC0 5211 8E3C 0B29 DA6B

* remotes/lalrae/tags/mips-20150804:
  target-mips: Copy restrictions from ext/ins to dext/dins
  target-mips: fix semihosting for microMIPS R6
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The checks in dins is required to avoid triggering an assertion
in tcg_gen_deposit_tl.  The check in dext is just for completeness.
Fold the other D cases in via fallthru.

In this case the errant dins appears to be data, not code, as
translation failed to stop after a break insn.
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Reviewed-by: NAurelien Jarno <aurelien@aurel32.net>
Reviewed-by: NLeon Alrae <leon.alrae@imgtec.com>
Signed-off-by: NLeon Alrae <leon.alrae@imgtec.com>

In semihosting mode the SDBBP 1 instructions should trigger UHI syscall,
but in QEMU this does not happen for recently added microMIPS R6.
Consequently bare metal microMIPS R6 programs supporting UHI will not run.
Signed-off-by: NLeon Alrae <leon.alrae@imgtec.com>
Reviewed-by: NAurelien Jarno <aurelien@aurel32.net>

cve-2015-5166

# gpg: Signature made Mon 03 Aug 2015 15:27:44 BST using RSA key ID 70E1AE90
# gpg: Good signature from "Stefano Stabellini <stefano.stabellini@eu.citrix.com>"

* remotes/sstabellini/tags/cve-2015-5166-tag:
  Fix release_drive on unplugged devices (pci_piix3_xen_ide_unplug)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

xen-migration-2.4

# gpg: Signature made Mon 03 Aug 2015 17:18:36 BST using RSA key ID 70E1AE90
# gpg: Good signature from "Stefano Stabellini <stefano.stabellini@eu.citrix.com>"

* remotes/sstabellini/tags/xen-migration-2.4-tag:
  migration: Fix regression for xenfv and pc,accel=xen machine.
  migration: Fix global state with Xen.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

This fix migration from the same QEMU version and from previous QEMU
version.

>From the global state section, we don't need runstate with Xen. Right now,
the way the Xen toolstack knows when QEMU is ready is when QEMU reach
"running" runstate.

The configuration section and the section footers are not going to be
present in previous version of QEMU with xenfv machine, so we skip them.

The Xen toolstack libxenlight does not specify a particular version of the
'pc' machine, so migration from older version of QEMU used by Xen to newer
one would break due to missing "configuration" section and section footers.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

When doing migration via the QMP command xen_save_devices_state, the
current runstate is not store into the global state section. Also the
current runstate is not the one we want on the receiver side.

During migration, the Xen toolstack paused QEMU before save the devices
state. Also, the toolstack expect QEMU to autostart when the migration is
finished.
So this patch store "running" as it's current runstate.
Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

Commit 8e9b0d24 (ui: convert VNC websockets to use crypto APIs) dropped
the --enable-vnc-ws option but forgot to update the help text. Fix this.

Cc: Daniel P. Berrange <berrange@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 1437749257-3313-1-git-send-email-afaerber@suse.de
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

pci_piix3_xen_ide_unplug should completely unhook the unplugged
IDEDevice from the corresponding BlockBackend, otherwise the next call
to release_drive will try to detach the drive again.
Suggested-by: NKevin Wolf <kwolf@redhat.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>

Merge remote-tracking branch 'remotes/stefanha/tags/rtl8139-cplus-tx-input-validation-pull-request' into staging

Pull request

# gpg: Signature made Mon Aug  3 13:08:25 2015 BST using RSA key ID 81AB73C8
# gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>"
# gpg:                 aka "Stefan Hajnoczi <stefanha@gmail.com>"

* remotes/stefanha/tags/rtl8139-cplus-tx-input-validation-pull-request:
  rtl8139: check TCP Data Offset field (CVE-2015-5165)
  rtl8139: skip offload on short TCP header (CVE-2015-5165)
  rtl8139: check IP Total Length field (CVE-2015-5165)
  rtl8139: check IP Header Length field (CVE-2015-5165)
  rtl8139: skip offload on short Ethernet/IP header (CVE-2015-5165)
  rtl8139: drop tautologous if (ip) {...} statement (CVE-2015-5165)
  rtl8139: avoid nested ifs in IP header parsing (CVE-2015-5165)
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The TCP Data Offset field contains the length of the header.  Make sure
it is valid and does not exceed the IP data length.
Reported-by: N朱东海(启路) <donghai.zdh@alibaba-inc.com>
Reviewed-by: NJason Wang <jasowang@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>