[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] c1a77f: Merge tag 'ppc-for-2.7-20161013' into
|
From: |
GitHub |
|
Subject: |
[Qemu-commits] [qemu/qemu] c1a77f: Merge tag 'ppc-for-2.7-20161013' into stable-2.7-s... |
|
Date: |
Fri, 23 Dec 2016 10:00:07 -0800 |
Branch: refs/heads/stable-2.7
Home: https://github.com/qemu/qemu
Commit: c1a77fd6fa3c43caa9e361c06335062573bbe114
https://github.com/qemu/qemu/commit/c1a77fd6fa3c43caa9e361c06335062573bbe114
Author: Michael Roth <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/ppc/spapr.c
M include/standard-headers/linux/input-event-codes.h
M include/standard-headers/linux/input.h
M include/standard-headers/linux/virtio_config.h
M include/standard-headers/linux/virtio_ids.h
M include/standard-headers/linux/virtio_net.h
A include/standard-headers/linux/virtio_vsock.h
M linux-headers/asm-arm/kvm.h
M linux-headers/asm-arm64/kvm.h
M linux-headers/asm-s390/kvm.h
M linux-headers/asm-x86/unistd_x32.h
M linux-headers/linux/kvm.h
M linux-headers/linux/vhost.h
M target-ppc/kvm.c
M target-ppc/kvm_ppc.h
Log Message:
-----------
Merge tag 'ppc-for-2.7-20161013' into stable-2.7-staging
qemu-2.7 (stable): ppc patch queue 2016-10-13
TCG for ppc does not properly implement hardware transactional memory.
It has a stub implementation in which transactions always fail.
Unfortunately in v2.7.0, HTM is advertised as being available to
guests, which means guests may incorrectly attempt to use it and hang.
This has been the case for a while, but has become more urgent with
recent (guest) Linux kernel versions which attempt to lazily enable
TM. Under TCG that now triggers the problem regularly, instead of
just when running a TM aware userspace program.
The problem is already fixed in the 2.8/master branch, by correctly
advertising HTM as not being available with TCG. This series
backports the relevant patches to the qemu-2.7 stable branch to fix
the problem there.
* tag 'ppc-for-2.7-20161013':
ppc: Check the availability of transactional memory
hw/ppc/spapr: Fix the selection of the processor features
hw/ppc/spapr: Move code related to "ibm,pa-features" to a separate function
linux-headers: update
Commit: 4b6542dd17257dda43937839230f3eca4c8048e7
https://github.com/qemu/qemu/commit/4b6542dd17257dda43937839230f3eca4c8048e7
Author: Stefan Hajnoczi <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: zero vq->inuse in virtio_reset()
vq->inuse must be zeroed upon device reset like most other virtqueue
fields.
In theory, virtio_reset() just needs assert(vq->inuse == 0) since
devices must clean up in-flight requests during reset (requests cannot
not be leaked!).
In practice, it is difficult to achieve vq->inuse == 0 across reset
because balloon, blk, 9p, etc implement various different strategies for
cleaning up requests. Most devices call g_free(elem) directly without
telling virtio.c that the VirtQueueElement is cleaned up. Therefore
vq->inuse is not decremented during reset.
This patch zeroes vq->inuse and trusts that devices are not leaking
VirtQueueElements across reset.
I will send a follow-up series that refactors request life-cycle across
all devices and converts vq->inuse = 0 into assert(vq->inuse == 0) but
this more invasive approach is not appropriate for stable trees.
Signed-off-by: Stefan Hajnoczi <address@hidden>
Cc: qemu-stable <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Ladi Prosek <address@hidden>
(cherry picked from commit 4b7f91ed0270a371e1933efa21ba600b6da23ab9)
Signed-off-by: Michael Roth <address@hidden>
Commit: 520d4b288fa71ea2b3ff0e256cc6d9608d16e7c1
https://github.com/qemu/qemu/commit/520d4b288fa71ea2b3ff0e256cc6d9608d16e7c1
Author: Ladi Prosek <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: discard virtqueue element on reset
The one pending element is being freed but not discarded on device
reset, which causes svq->inuse to creep up, eventually hitting the
"Virtqueue size exceeded" error.
Properly discarding the element on device reset makes sure that its
buffers are unmapped and the inuse counter stays balanced.
Cc: Michael S. Tsirkin <address@hidden>
Cc: Roman Kagan <address@hidden>
Cc: Stefan Hajnoczi <address@hidden>
Signed-off-by: Ladi Prosek <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 104e70cae78bd4afd95d948c6aff188f10508a9c)
Signed-off-by: Michael Roth <address@hidden>
Commit: 91a2f462976aff1206e06271536422314d6d9348
https://github.com/qemu/qemu/commit/91a2f462976aff1206e06271536422314d6d9348
Author: Gonglei <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M ui/vnc.c
Log Message:
-----------
vnc: fix qemu crash because of SIGSEGV
The backtrace is:
0x00007f0b75cdf880 in pixman_image_get_stride () from /lib64/libpixman-1.so.0
0x00007f0b77bcb3cf in vnc_server_fb_stride (vd=0x7f0b7a1a2bb0) at ui/vnc.c:680
vnc_dpy_copy (dcl=0x7f0b7a1a2c00, src_x=224, src_y=263, dst_x=319, dst_y=363,
w=1, h=1) at ui/vnc.c:915
0x00007f0b77bbcc35 in dpy_gfx_copy (con=0x7f0b7a146210, address@hidden,
address@hidden, address@hidden,
address@hidden, w=1, h=1) at ui/console.c:1575
0x00007f0b77bbda4e in qemu_console_copy (con=<optimized out>, address@hidden,
address@hidden, address@hidden,
address@hidden, w=<optimized out>, h=<optimized out>) at ui/console.c:2111
0x00007f0b77ac0980 in cirrus_do_copy (h=<optimized out>, w=<optimized out>,
src=<optimized out>, dst=<optimized out>, s=0x7f0b7b086090) at
hw/display/cirrus_vga.c:774
cirrus_bitblt_videotovideo_copy (s=0x7f0b7b086090) at
hw/display/cirrus_vga.c:793
cirrus_bitblt_videotovideo (s=0x7f0b7b086090) at hw/display/cirrus_vga.c:915
cirrus_bitblt_start (s=0x7f0b7b086090) at hw/display/cirrus_vga.c:1056
0x00007f0b77965cfb in memory_region_write_accessor (mr=0x7f0b7b096e40,
addr=320, value=<optimized out>, size=1, shift=<optimized out>,mask=<optimized
out>, attrs=...) at /root/rpmbuild/BUILD/master/qemu/memory.c:525
0x00007f0b77963f59 in access_with_adjusted_size (address@hidden,
address@hidden, address@hidden,
access_size_min=<optimized out>, access_size_max=<optimized out>,
address@hidden <memory_region_write_accessor>,
address@hidden, address@hidden) at /root/rpmbuild/BUILD/master/qemu/memory.c:591
0x00007f0b77968315 in memory_region_dispatch_write (address@hidden,
address@hidden, data=18446744073709551362,
address@hidden, address@hidden) at
/root/rpmbuild/BUILD/master/qemu/memory.c:1262
0x00007f0b779256a9 in address_space_write_continue (mr=0x7f0b7b096e40, l=4,
addr1=320, len=4, buf=0x7f0b77713028 "\002\377\377\377",
attrs=..., addr=4273930560, as=0x7f0b7827d280 <address_space_memory>) at
/root/rpmbuild/BUILD/master/qemu/exec.c:2544
address_space_write (as=<optimized out>, addr=<optimized out>, attrs=...,
buf=<optimized out>, len=<optimized out>) at
/root/rpmbuild/BUILD/master/qemu/exec.c:2601
0x00007f0b77925c1d in address_space_rw (as=<optimized out>, addr=<optimized
out>, attrs=..., address@hidden,
address@hidden "\002\377\377\377", len=<optimized out>, is_write=<optimized
out>) at /root/rpmbuild/BUILD/master/qemu/exec.c:2703
0x00007f0b77962f53 in kvm_cpu_exec (address@hidden) at
/root/rpmbuild/BUILD/master/qemu/kvm-all.c:1965
0x00007f0b77950cc6 in qemu_kvm_cpu_thread_fn (arg=0x7f0b79fcc2d0) at
/root/rpmbuild/BUILD/master/qemu/cpus.c:1078
0x00007f0b744b3dc5 in start_thread (arg=0x7f0b69a27700) at pthread_create.c:308
0x00007f0b70d3d66d in clone () from /lib64/libc.so.6
The code path while meeting segfault:
vnc_dpy_copy
vnc_update_client
vnc_disconnect_finish [while vnc_disconnect_start() is invoked because
somethins wrong]
vnc_update_server_surface
vd->server = NULL;
vnc_server_fb_stride
pixman_image_get_stride(vd->server)
Let's add a non-NULL check before calling vnc_server_fb_stride() to avoid
segmentation fault.
Cc: Gerd Hoffmann <address@hidden>
Cc: Daniel P. Berrange <address@hidden>
Reported-by: Yanying Zhuang <address@hidden>
Signed-off-by: Gonglei <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 3e10c3ecfcaf604d8b400d6e463e1a186ce97d9b)
Signed-off-by: Michael Roth <address@hidden>
Commit: d06c61f31001474a73b7fcc7a2c2067ed3f489d4
https://github.com/qemu/qemu/commit/d06c61f31001474a73b7fcc7a2c2067ed3f489d4
Author: Greg Kurz <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/9pfs/9p.c
Log Message:
-----------
9pfs: fix potential segfault during walk
If the call to fid_to_qid() returns an error, we will call v9fs_path_free()
on uninitialized paths.
It is a regression introduced by the following commit:
56f101ecce0e 9pfs: handle walk of ".." in the root directory
Let's fix this by initializing dpath and path before calling fid_to_qid().
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Cédric Le Goater <address@hidden>
[groug: updated the changelog to indicate this is regression and to provide
the offending commit SHA1]
Signed-off-by: Greg Kurz <address@hidden>
(cherry picked from commit 13fd08e631ec0c3ff5ad1bdcb6a4474c7d9a024f)
Signed-off-by: Michael Roth <address@hidden>
Commit: c6a7b922f8ab4af286da90124b1669e9b553e957
https://github.com/qemu/qemu/commit/c6a7b922f8ab4af286da90124b1669e9b553e957
Author: Li Qiang <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/scsi/mptsas.c
Log Message:
-----------
scsi: mptsas: use g_new0 to allocate MPTSASRequest object
When processing IO request in mptsas, it uses g_new to allocate
a 'req' object. If an error occurs before 'req->sreq' is
allocated, It could lead to an OOB write in mptsas_free_request
function. Use g_new0 to avoid it.
Reported-by: Li Qiang <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 670e56d3ed2918b3861d9216f2c0540d9e9ae0d5)
Signed-off-by: Michael Roth <address@hidden>
Commit: bfb15f77bbd2e3f9c72b5505192caf50a2080381
https://github.com/qemu/qemu/commit/bfb15f77bbd2e3f9c72b5505192caf50a2080381
Author: Prasad J Pandit <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/scsi/vmw_pvscsi.c
Log Message:
-----------
scsi: pvscsi: limit process IO loop to ring size
Vmware Paravirtual SCSI emulator while processing IO requests
could run into an infinite loop if 'pvscsi_ring_pop_req_descr'
always returned positive value. Limit IO loop to the ring size.
Cc: address@hidden
Reported-by: Li Qiang <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit d251157ac1928191af851d199a9ff255d330bec9)
Signed-off-by: Michael Roth <address@hidden>
Commit: 069e885d83a56af4fda1fa9d4298d119767d4189
https://github.com/qemu/qemu/commit/069e885d83a56af4fda1fa9d4298d119767d4189
Author: Lin Ma <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M backends/msmouse.c
M qemu-char.c
Log Message:
-----------
qemu-char: avoid segfault if user lacks of permisson of a given logfile
Function qemu_chr_alloc returns NULL if it failed to open logfile by any reason,
says no write permission. For backends tty, stdio and msmouse, They need to
check this return value to avoid segfault in this case.
Signed-off-by: Lin Ma <address@hidden>
Cc: qemu-stable <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 71200fb9664c2967a1cdd22b68b0da3a8b2b3eb7)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2f8e8c7396b399c014c922de800fae85ed956ae1
https://github.com/qemu/qemu/commit/2f8e8c7396b399c014c922de800fae85ed956ae1
Author: Rony Weng <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/scsi/scsi-disk.c
Log Message:
-----------
scsi-disk: change disk serial length from 20 to 36
Openstack Cinder assigns volume a 36 characters uuid as serial.
QEMU will shrinks the uuid to 20 characters, which does not match
the original uuid.
Note that there is no limit to the length of the serial number in
the SCSI spec. 20 was copy-pasted from virtio-blk which in turn was
copy-pasted from ATA; 36 is even more arbitrary. However, bumping it
up too much might cause issues (e.g. 252 seems to make sense because
then the maximum amount of returned data is 256; but who knows there's
no off-by-one somewhere for such a nicely rounded number).
Signed-off-by: Rony Weng <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 48b6206305b8d56524ac2ee347b68e6e0a528559)
Signed-off-by: Michael Roth <address@hidden>
Commit: 742886578d76e088d7fffdfce3bd2f4001e30558
https://github.com/qemu/qemu/commit/742886578d76e088d7fffdfce3bd2f4001e30558
Author: Prasad J Pandit <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/scsi/vmw_pvscsi.c
Log Message:
-----------
vmw_pvscsi: check page count while initialising descriptor rings
Vmware Paravirtual SCSI emulation uses command descriptors to
process SCSI commands. These descriptors come with their ring
buffers. A guest could set the page count for these rings to
an arbitrary value, leading to infinite loop or OOB access.
Add check to avoid it.
Reported-by: Tom Victor <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 7f61f4690dd153be98900a2a508b88989e692753)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0b6ab25367c1dde9ecbd1bc331795fee0554bd54
https://github.com/qemu/qemu/commit/0b6ab25367c1dde9ecbd1bc331795fee0554bd54
Author: Prasad J Pandit <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/scsi/mptconfig.c
Log Message:
-----------
scsi: mptconfig: fix an assert expression
When LSI SAS1068 Host Bus emulator builds configuration page
headers, mptsas_config_pack() should assert that the size
fits in a byte. However, the size is expressed in 32-bit
units, so up to 1020 bytes fit. The assertion was only
allowing replies up to 252 bytes, so fix it.
Suggested-by: Paolo Bonzini <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit cf2bce203a45d7437029d108357fb23fea0967b6)
Signed-off-by: Michael Roth <address@hidden>
Commit: 8342e1240b70bbf72813a48c1475b025da87b017
https://github.com/qemu/qemu/commit/8342e1240b70bbf72813a48c1475b025da87b017
Author: Paolo Bonzini <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/scsi/mptconfig.c
Log Message:
-----------
scsi: mptconfig: fix misuse of MPTSAS_CONFIG_PACK
These issues cause respectively a QEMU crash and a leak of 2 bytes of
stack. They were discovered by VictorV of 360 Marvel Team.
Reported-by: Tom Victor <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 65a8e1f6413a0f6f79894da710b5d6d43361d27d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 98b4465f7ded63ed3f3f97c1e244123182a1c687
https://github.com/qemu/qemu/commit/98b4465f7ded63ed3f3f97c1e244123182a1c687
Author: Daniel P. Berrange <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M crypto/cipher-gcrypt.c
M crypto/cipher-nettle.c
M tests/test-crypto-cipher.c
Log Message:
-----------
crypto: ensure XTS is only used with ciphers with 16 byte blocks
The XTS cipher mode needs to be used with a cipher which has
a block size of 16 bytes. If a mis-matching block size is used,
the code will either corrupt memory beyond the IV array, or
not fully encrypt/decrypt the IV.
This fixes a memory corruption crash when attempting to use
cast5-128 with xts, since the former has an 8 byte block size.
A test case is added to ensure the cipher creation fails with
such an invalid combination.
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>
(cherry picked from commit a5d2f44d0d3e7523670e103a8c37faed29ff2b76)
Signed-off-by: Michael Roth <address@hidden>
Commit: 316c2c9448a7666d29bb36651cd9b2a8a16c6ef7
https://github.com/qemu/qemu/commit/316c2c9448a7666d29bb36651cd9b2a8a16c6ef7
Author: Fam Zheng <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M include/sysemu/iothread.h
M iothread.c
M vl.c
Log Message:
-----------
iothread: Stop threads before main() quits
Right after main_loop ends, we release various things but keep iothread
alive. The latter is not prepared to the sudden change of resources.
Specifically, after bdrv_close_all(), virtio-scsi dataplane get a
surprise at the empty BlockBackend:
(gdb) bt
at /usr/src/debug/qemu-2.6.0/hw/scsi/virtio-scsi.c:543
at /usr/src/debug/qemu-2.6.0/hw/scsi/virtio-scsi.c:577
It is because the d->conf.blk->root is set to NULL, then
blk_get_aio_context() returns qemu_aio_context, whereas s->ctx is still
pointing to the iothread:
hw/scsi/virtio-scsi.c:543:
if (s->dataplane_started) {
assert(blk_get_aio_context(d->conf.blk) == s->ctx);
}
To fix this, let's stop iothreads before doing bdrv_close_all().
Cc: address@hidden
Signed-off-by: Fam Zheng <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit dce8921b2baaf95974af8176406881872067adfa)
Signed-off-by: Michael Roth <address@hidden>
Commit: 3550eeafcd0882846edceb95ab3b5be828f89684
https://github.com/qemu/qemu/commit/3550eeafcd0882846edceb95ab3b5be828f89684
Author: Fam Zheng <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/scsi/scsi-disk.c
Log Message:
-----------
scsi-disk: Cleaning up around tray open state
Even if tray is not open, it can be empty (blk_is_inserted() == false).
Handle both cases correctly by replacing the s->tray_open checks with
blk_is_available(), which is an AND of the two.
Also simplify successive checks of them into blk_is_available(), in a
couple cases.
Signed-off-by: Fam Zheng <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit cd723b85601baa7a0eeffbac83421357a70d81ee)
Signed-off-by: Michael Roth <address@hidden>
Commit: f5436d1daba9d5c50c9dc7240e9561e429c5aac4
https://github.com/qemu/qemu/commit/f5436d1daba9d5c50c9dc7240e9561e429c5aac4
Author: Fam Zheng <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/scsi/virtio-scsi.c
Log Message:
-----------
virtio-scsi: Don't abort when media is ejected
With an ejected block backend, blk_get_aio_context() would return
qemu_aio_context. In this case don't assert.
Signed-off-by: Fam Zheng <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 2a2d69f490c1b1dc6b6d2aef385ee7b654497a77)
Signed-off-by: Michael Roth <address@hidden>
Commit: 54c26b7340a6d76278a6c182afd6861626068b4a
https://github.com/qemu/qemu/commit/54c26b7340a6d76278a6c182afd6861626068b4a
Author: John Snow <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
ahci: clear aiocb in ncq_cb
Similar to existing fixes for IDE (87ac25fd) and ATAPI (7f951b2d), the
AIOCB must be cleared in the callback. Otherwise, we may accidentally
try to reset a dangling pointer in bdrv_aio_cancel() from a port reset.
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit df403bc58859c893ebd0accda07678e84d15dc5d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 533dedf059ef2ad047889ef8ba4643e2026e7f91
https://github.com/qemu/qemu/commit/533dedf059ef2ad047889ef8ba4643e2026e7f91
Author: Cornelia Huck <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/s390x/css.c
M include/hw/s390x/css.h
Log Message:
-----------
s390x/css: handle cssid 255 correctly
The cssid 255 is reserved but still valid from an architectural
point of view. However, feeding a bogus schid of 0xffffffff into
the virtio hypercall will lead to a crash:
Stack trace of thread 138363:
#0 0x00000000100d168c css_find_subch (qemu-system-s390x)
#1 0x00000000100d3290 virtio_ccw_hcall_notify
#2 0x00000000100cbf60 s390_virtio_hypercall
#3 0x000000001010ff7a handle_hypercall
#4 0x0000000010079ed4 kvm_cpu_exec (qemu-system-s390x)
#5 0x00000000100609b4 qemu_kvm_cpu_thread_fn
#6 0x000003ff8b887bb4 start_thread (libpthread.so.0)
#7 0x000003ff8b78df0a thread_start (libc.so.6)
This is because the css array was only allocated for 0..254
instead of 0..255.
Let's fix this by bumping MAX_CSSID to 255 and fencing off the
reserved cssid of 255 during css image allocation.
Reported-by: Christian Borntraeger <address@hidden>
Tested-by: Christian Borntraeger <address@hidden>
Cc: address@hidden
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 882b3b97697affb36ca3d174f42f846232008979)
Signed-off-by: Michael Roth <address@hidden>
Commit: a3a254550b45500c42e30967a9733ae8d46ef0d6
https://github.com/qemu/qemu/commit/a3a254550b45500c42e30967a9733ae8d46ef0d6
Author: David Gibson <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/vfio/pci.c
Log Message:
-----------
vfio/pci: Fix regression in MSI routing configuration
d1f6af6 "kvm-irqchip: simplify kvm_irqchip_add_msi_route" was a cleanup
of kvmchip routing configuration, that was mostly intended for x86.
However, it also contains a subtle change in behaviour which breaks EEH[1]
error recovery on certain VFIO passthrough devices on spapr guests. So far
it's only been seen on a BCM5719 NIC on a POWER8 server, but there may be
other hardware with the same problem. It's also possible there could be
circumstances where it causes a bug on x86 as well, though I don't know of
any obvious candidates.
Prior to d1f6af6, both vfio_msix_vector_do_use() and
vfio_add_kvm_msi_virq() used msg == NULL as a special flag to mark this
as the "dummy" vector used to make the host hardware state sync with the
guest expected hardware state in terms of MSI configuration.
Specifically that flag caused vfio_add_kvm_msi_virq() to become a no-op,
meaning the dummy irq would always be delivered via qemu. d1f6af6 changed
vfio_add_kvm_msi_virq() so it takes a vector number instead of the msg
parameter, and determines the correct message itself. The test for !msg
was removed, and not replaced with anything there or in the caller.
With an spapr guest which has a VFIO device, if an EEH error occurs on the
host hardware, then the device will be isolated then reset. This is a
combination of host and guest action, mediated by some EEH related
hypercalls. I haven't fully traced the mechanics, but somehow installing
the kvm irqchip route for the dummy irq on the BCM5719 means that after EEH
reset and recovery, at least some irqs are no longer delivered to the
guest.
In particular, the guest never gets the link up event, and so the NIC is
effectively dead.
[1] EEH (Enhanced Error Handling) is an IBM POWER server specific PCI-*
error reporting and recovery mechanism. The concept is somewhat
similar to PCI-E AER, but the details are different.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1373802
Cc: Alex Williamson <address@hidden>
Cc: Peter Xu <address@hidden>
Cc: Gavin Shan <address@hidden>
Signed-off-by: David Gibson <address@hidden>
Cc: address@hidden
Fixes: d1f6af6a17a6 ("kvm-irqchip: simplify kvm_irqchip_add_msi_route")
Signed-off-by: Alex Williamson <address@hidden>
(cherry picked from commit 6d17a018d09801a2b18133a4febd81433bb0cf85)
Signed-off-by: Michael Roth <address@hidden>
Commit: f9856029d59f4c6a580ebbf03d81c4016c19696a
https://github.com/qemu/qemu/commit/f9856029d59f4c6a580ebbf03d81c4016c19696a
Author: Daniel P. Berrange <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M block/qcow2-cluster.c
A tests/qemu-iotests/158
A tests/qemu-iotests/158.out
M tests/qemu-iotests/group
Log Message:
-----------
qcow2: fix encryption during cow of sectors
Broken in previous commit:
commit aaa4d20b4972bb1a811ce929502e6741835d584e
Author: Kevin Wolf <address@hidden>
Date: Wed Jun 1 15:21:05 2016 +0200
qcow2: Make copy_sectors() byte based
The copy_sectors() code was originally using the 'sector'
parameter for encryption, which was passed in by the caller
from the QCowL2Meta.offset field (aka the guest logical
offset).
After the change, the code is using 'cluster_offset' which
was passed in from QCow2L2Meta.alloc_offset field (aka the
host physical offset).
This would cause the data to be encrypted using an incorrect
initialization vector which will in turn cause later reads
to return garbage.
Although current qcow2 built-in encryption is blocked from
usage in the emulator, one could still hit this if writing
to the file via qemu-{img,io,nbd} commands.
Cc: address@hidden
Signed-off-by: Daniel P. Berrange <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit bb9f8dd0e15a9744b8d09d06ecb6a18ca3dcc173)
Conflicts:
tests/qemu-iotests/group
* drop context dependancy on non-2.7 iotest groups
Signed-off-by: Michael Roth <address@hidden>
Commit: d40d148feb7e7c45fdb36adb47b1f34467845460
https://github.com/qemu/qemu/commit/d40d148feb7e7c45fdb36adb47b1f34467845460
Author: Eric Blake <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M block/iscsi.c
Log Message:
-----------
iscsi: Fix divide-by-zero regression on raw SG devices
When qemu uses iscsi devices in sg mode, iscsilun->block_size
is left at 0. Prior to commits cf081fca and similar, when
block limits were tracked in sectors, this did not matter:
various block limits were just left at 0. But when we started
scaling by block size, this caused SIGFPE.
Then, in a later patch, commit a5b8dd2c added an assertion to
bdrv_open_common() that request_alignment is always non-zero;
which was not true for SG mode. Rather than relax that assertion,
we can just provide a sane value (we don't know of any SG device
with a block size smaller than qemu's default sizing of 512 bytes).
One possible solution for SG mode is to just blindly skip ALL
of iscsi_refresh_limits(), since we already short circuit so
many other things in sg mode. But this patch takes a slightly
more conservative approach, and merely guarantees that scaling
will succeed, while still using multiples of the original size
where possible. Resulting limits may still be zero in SG mode
(that is, we mostly only fix block_size used as a denominator
or which affect assertions, not all uses).
Reported-by: Holger Schranz <address@hidden>
Signed-off-by: Eric Blake <address@hidden>
CC: address@hidden
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 95eaa78537c734fa3cb3373d47ba8c0099a36ff0)
Signed-off-by: Michael Roth <address@hidden>
Commit: 8e94512568729c8dfaa9827b5417c7be3d2fb773
https://github.com/qemu/qemu/commit/8e94512568729c8dfaa9827b5417c7be3d2fb773
Author: John Snow <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M block/io.c
M include/block/block.h
Log Message:
-----------
block: reintroduce bdrv_flush_all
Commit fe1a9cbc moved the flush_all routine from the bdrv layer to the
block-backend layer. In doing so, however, the semantics of the routine
changed slightly such that flush_all now used blk_flush instead of
bdrv_flush.
blk_flush can fail if the attached device model reports that it is not
"available," (i.e. the tray is open.) This changed the semantics of
flush_all such that it can now fail for e.g. open CDROM drives.
Reintroduce bdrv_flush_all to regain the old semantics without having to
alter the behavior of blk_flush or blk_flush_all, which are already
'doing the right thing.'
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Acked-by: Fam Zheng <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 4085f5c7a239567a292876f46cb59d9b19bcf6ac)
Signed-off-by: Michael Roth <address@hidden>
Commit: 95200ebb5078a6718a8010528263994f9cb7ebaf
https://github.com/qemu/qemu/commit/95200ebb5078a6718a8010528263994f9cb7ebaf
Author: John Snow <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M cpus.c
Log Message:
-----------
qemu: use bdrv_flush_all for vm_stop et al
Reimplement bdrv_flush_all for vm_stop. In contrast to blk_flush_all,
bdrv_flush_all does not have device model restrictions. This allows
us to flush and halt unconditionally without error.
This allows us to do things like migrate when we have a device with
an open tray, but has a node that may need to be flushed, or nodes
that aren't currently attached to any device and need to be flushed.
Specifically, this allows us to migrate when we have a CDROM with
an open tray.
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Acked-by: Fam Zheng <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 22af08eacf6b5aa0e6c0581e547380b3eb4f95e9)
Conflicts:
cpus.c
* drop context dependancy on 6d0ceb80
Signed-off-by: Michael Roth <address@hidden>
Commit: 4a25ab2a04ff0ff80589608de527cc68216cd480
https://github.com/qemu/qemu/commit/4a25ab2a04ff0ff80589608de527cc68216cd480
Author: John Snow <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M block/block-backend.c
M hw/i386/xen/xen_platform.c
M hw/ide/piix.c
M include/sysemu/block-backend.h
Log Message:
-----------
block-backend: remove blk_flush_all
We can teach Xen to drain and flush each device as it needs to, instead
of trying to flush ALL devices. This removes the last user of
blk_flush_all.
The function is therefore removed under the premise that any new uses
of blk_flush_all would be the wrong paradigm: either flush the single
device that requires flushing, or use an appropriate flush_all mechanism
from outside of the BlkBackend layer.
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Acked-by: Fam Zheng <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 49137bf6845eaecad51a047fc06dd11c56118460)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4d45fe11d1032326dfb623e72f1379835a71b1c6
https://github.com/qemu/qemu/commit/4d45fe11d1032326dfb623e72f1379835a71b1c6
Author: Eric Blake <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hmp.c
Log Message:
-----------
migrate: Fix cpu-throttle-increment regression in HMP
Commit 69ef1f3 accidentally broke migrate_set_parameter's ability
to set the cpu-throttle-increment to anything other than the
default, because it forgot to parse the user's string into an
integer.
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Signed-off-by: Juan Quintela <address@hidden>
(cherry picked from commit bb2b777cf9a2862fe31a40256659ff49ae3d2006)
Signed-off-by: Michael Roth <address@hidden>
Commit: f72ca1ac6f7513537a4e8f2032aa0c4ca4013b72
https://github.com/qemu/qemu/commit/f72ca1ac6f7513537a4e8f2032aa0c4ca4013b72
Author: Emilio G. Cota <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M util/qht.c
Log Message:
-----------
qht: simplify qht_reset_size
Sometimes gcc doesn't pick up the fact that 'new' is properly
set if 'resize == true', which may generate an unnecessary
build warning.
Fix it by removing 'resize' and directly checking that 'new'
is non-NULL.
Signed-off-by: Emilio G. Cota <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit f555a9d0b3c785b698f32e6879e97d0a4b387314)
Signed-off-by: Michael Roth <address@hidden>
Commit: af29bd3193015865f6b2ca6f5c9e79aad1df3e28
https://github.com/qemu/qemu/commit/af29bd3193015865f6b2ca6f5c9e79aad1df3e28
Author: Emilio G. Cota <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M util/qht.c
Log Message:
-----------
qht: fix unlock-after-free segfault upon resizing
The old map's bucket locks are being unlocked *after*
that same old map has been passed to RCU for destruction.
This is a bug that can cause a segfault, since there's
no guarantee that the deletion will be deferred (e.g.
there may be no concurrent readers).
The segfault is easily triggered in RHEL6/CentOS6 with qht-test,
particularly on a single-core system or by pinning qht-test
to a single core.
Fix it by unlocking the map's bucket locks right after having
published the new map, and (crucially) before marking the map
for deletion via call_rcu().
While at it, expand qht_do_resize() to atomically do (1) a reset,
(2) a resize, or (3) a reset+resize. This simplifies the calling
code, since the new function (qht_do_resize_reset()) acquires
and releases the buckets' locks.
Note that no qht_do_reset inline is provided, since it would have
no users--qht_reset() already performs a reset without taking
ht->lock.
Reported-by: Peter Maydell <address@hidden>
Reported-by: Daniel P. Berrange <address@hidden>
Signed-off-by: Emilio G. Cota <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 76b553b308dc8671eb672b889b38889b1231cf1e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5be5335661a9c28f64e2b4e296063a7387ab498f
https://github.com/qemu/qemu/commit/5be5335661a9c28f64e2b4e296063a7387ab498f
Author: Daniel P. Berrange <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M qemu-char.c
Log Message:
-----------
char: fix missing return in error path for chardev TLS init
If the qio_channel_tls_new_(server|client) methods fail,
we disconnect the client. Unfortunately a missing return
means we then go on to try and run the TLS handshake on
a NULL I/O channel. This gives predictably segfaulty
results.
The main way to trigger this is to request a bogus TLS
priority string for the TLS credentials. e.g.
-object tls-creds-x509,id=tls0,priority=wibble,...
Most other ways appear impossible to trigger except
perhaps if OOM conditions cause gnutls initialization
to fail.
Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Michael Tokarev <address@hidden>
(cherry picked from commit 660a2d83e026496db6b3eaec2256a2cdd6c74de8)
Signed-off-by: Michael Roth <address@hidden>
Commit: f3467f56c14fe745b11ae9b37bb081c0967999d4
https://github.com/qemu/qemu/commit/f3467f56c14fe745b11ae9b37bb081c0967999d4
Author: Marc-André Lureau <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M qmp.c
Log Message:
-----------
qmp: fix object-add assert() without props
Since commit ad739706bbadee49, user_creatable_add_type() expects to be
given a qdict. However, if object-add is called without props, you reach
the assert: "qemu/qom/object_interfaces.c:115: user_creatable_add_type:
Assertion `qdict' failed.", because the qdict isn't created in this
case (it's optional).
Furthermore, qmp_input_visitor_new() is not meant to be called without a
dict, and a further commit will assert in this situation.
If none given, create an empty qdict in qmp to avoid the
user_creatable_add_type() assert(qdict).
Signed-off-by: Marc-André Lureau <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Tested-by: Xiao Long Jiang <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
Signed-off-by: Markus Armbruster <address@hidden>
(cherry picked from commit e64c75a9752c5d0fd64eb2e684c656a5ea7d03c6)
Signed-off-by: Michael Roth <address@hidden>
Commit: b34c7bd463ef1453b8661a7b59146c462bb1c621
https://github.com/qemu/qemu/commit/b34c7bd463ef1453b8661a7b59146c462bb1c621
Author: Marc-André Lureau <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M qapi/qmp-input-visitor.c
Log Message:
-----------
qapi: Fix crash when 'any' or 'null' parameter is missing
Unlike the other visit methods, visit_type_any() and visit_type_null()
neglect to check whether qmp_input_get_object() succeeded. They crash
when it fails. Reproducer:
{ "execute": "qom-set",
"arguments": { "path": "/machine", "property": "rtc-time" } }
Will crash with:
qapi/qapi-visit-core.c:277: visit_type_any: Assertion `!err != !*obj'
failed
Broken in commit 5c678ee. Fix by adding the missing error checks.
Signed-off-by: Marc-André Lureau <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
[Commit message rephrased]
Signed-off-by: Markus Armbruster <address@hidden>
(cherry picked from commit c489780203f9b22aca5539ec7589b7140bdc951f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 99837b0d363a94c4fda1789043128aa372773fd7
https://github.com/qemu/qemu/commit/99837b0d363a94c4fda1789043128aa372773fd7
Author: Markus Armbruster <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M tests/test-qmp-input-strict.c
Log Message:
-----------
tests/test-qmp-input-strict: Cover missing struct members
These tests would have caught the bug fixed by the previous commit.
Signed-off-by: Markus Armbruster <address@hidden>
Message-Id: <address@hidden>
(cherry picked from commit bce3035a44c40bd3ec29d3162025fd350f2d8dbf)
Signed-off-by: Michael Roth <address@hidden>
Commit: 857efecf91f41105f919844ef71992e247817e3e
https://github.com/qemu/qemu/commit/857efecf91f41105f919844ef71992e247817e3e
Author: Paolo Bonzini <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M block/rbd.c
Log Message:
-----------
rbd: shift byte count as a 64-bit value
Otherwise, reads of more than 2GB fail. Until commit
7bbca9e290a9c7c217b5a24fc6094e91e54bd05d, reads of 2^41
bytes succeeded at least theoretically.
In fact, pdiscard ought to receive a 64-bit integer as the
count for the same reason.
Reported by Coverity.
Fixes: 7bbca9e290a9c7c217b5a24fc6094e91e54bd05d
Cc: address@hidden
Cc: address@hidden
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit e948f663e9334249c394b88926addcdd3f9e35cd)
Signed-off-by: Michael Roth <address@hidden>
Commit: 61781984dbadc2ed7af51e1f818a7d8beec2ec7b
https://github.com/qemu/qemu/commit/61781984dbadc2ed7af51e1f818a7d8beec2ec7b
Author: Thomas Huth <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M target-ppc/kvm.c
Log Message:
-----------
ppc/kvm: Mark 64kB page size support as disabled if not available
QEMU currently refuses to start with KVM-PR and only prints out
qemu: fatal: Unknown MMU model 851972
when being started there. This is because commit 4322e8ced5aaac719
("ppc: Fix 64K pages support in full emulation") introduced a new
POWERPC_MMU_64K bit to indicate support for this page size, but
it never gets cleared on KVM-PR if the host kernel does not support
this. Thus we've got to turn off this bit in the mmu_model for KVM-PR.
Signed-off-by: Thomas Huth <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 0d594f5565837fe2886a8aa307ef8abb65eab8f7)
Signed-off-by: Michael Roth <address@hidden>
Commit: b1fdc9419322247fd7faaa8e795fa80176825459
https://github.com/qemu/qemu/commit/b1fdc9419322247fd7faaa8e795fa80176825459
Author: Alberto Garcia <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M block/throttle-groups.c
Log Message:
-----------
throttle: Correct access to wrong BlockBackendPublic structures
In 27ccdd52598290f0f8b58be56e235aff7aebfaf3 the throttling fields were
moved from BlockDriverState to BlockBackend. However in a few cases
the code started using throttling fields from the active BlockBackend
instead of the round-robin token, making the algorithm behave
incorrectly.
This can cause starvation if there's a throttling group with several
drives but only one of them has I/O.
Cc: address@hidden
Reported-by: Paolo Bonzini <address@hidden>
Signed-off-by: Alberto Garcia <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 6bf77e1c2dc24da1bade16e8a9a637f3b127314d)
Signed-off-by: Michael Roth <address@hidden>
Commit: e389e44a351dfeb5ebff15662c08816a8f1c6324
https://github.com/qemu/qemu/commit/e389e44a351dfeb5ebff15662c08816a8f1c6324
Author: Alberto Garcia <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M tests/qemu-iotests/093
M tests/qemu-iotests/093.out
Log Message:
-----------
qemu-iotests: Test I/O in a single drive from a throttling group
iotest 093 contains a test that creates a throttling group with
several drives and performs I/O in all of them. This patch adds a new
test that creates a similar setup but only performs I/O in one of the
drives at the same time.
This is useful to test that the round robin algorithm is behaving
properly in these scenarios, and is specifically written using the
regression introduced in 27ccdd52598290f0f8b58be56e as an example.
Signed-off-by: Alberto Garcia <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit a26ddb43963e77aeebc2a4f011d27b2d9c017f21)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2817466c555d89c22bdd1ec8626bce09ee96922e
https://github.com/qemu/qemu/commit/2817466c555d89c22bdd1ec8626bce09ee96922e
Author: Prasad J Pandit <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/net/rtl8139.c
Log Message:
-----------
net: rtl8139: limit processing of ring descriptors
RTL8139 ethernet controller in C+ mode supports multiple
descriptor rings, each with maximum of 64 descriptors. While
processing transmit descriptor ring in 'rtl8139_cplus_transmit',
it does not limit the descriptor count and runs forever. Add
check to avoid it.
Reported-by: Andrew Henderson <address@hidden>
Signed-off-by: Prasad J Pandit <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit c7c35916692fe010fef25ac338443d3fe40be225)
Signed-off-by: Michael Roth <address@hidden>
Commit: ca83f87a66d19fdaabf23d4f5ebb49396fe232c1
https://github.com/qemu/qemu/commit/ca83f87a66d19fdaabf23d4f5ebb49396fe232c1
Author: Alex Williamson <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M hw/vfio/common.c
M hw/vfio/spapr.c
M include/exec/memory.h
M memory.c
M memory_mapping.c
Log Message:
-----------
memory: Replace skip_dump flag with "ram_device"
Setting skip_dump on a MemoryRegion allows us to modify one specific
code path, but the restriction we're trying to address encompasses
more than that. If we have a RAM MemoryRegion backed by a physical
device, it not only restricts our ability to dump that region, but
also affects how we should manipulate it. Here we recognize that
MemoryRegions do not change to sometimes allow dumps and other times
not, so we replace setting the skip_dump flag with a new initializer
so that we know exactly the type of region to which we're applying
this behavior.
Signed-off-by: Alex Williamson <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 21e00fa55f3fdfcbb20da7c6876c91ef3609b387)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1b16ded6a512809f99c133a97f19026fe612b2de
https://github.com/qemu/qemu/commit/1b16ded6a512809f99c133a97f19026fe612b2de
Author: Alex Williamson <address@hidden>
Date: 2016-11-02 (Wed, 02 Nov 2016)
Changed paths:
M include/exec/memory.h
M memory.c
M trace-events
Log Message:
-----------
memory: Don't use memcpy for ram_device regions
With a vfio assigned device we lay down a base MemoryRegion registered
as an IO region, giving us read & write accessors. If the region
supports mmap, we lay down a higher priority sub-region MemoryRegion
on top of the base layer initialized as a RAM device pointer to the
mmap. Finally, if we have any quirks for the device (ie. address
ranges that need additional virtualization support), we put another IO
sub-region on top of the mmap MemoryRegion. When this is flattened,
we now potentially have sub-page mmap MemoryRegions exposed which
cannot be directly mapped through KVM.
This is as expected, but a subtle detail of this is that we end up
with two different access mechanisms through QEMU. If we disable the
mmap MemoryRegion, we make use of the IO MemoryRegion and service
accesses using pread and pwrite to the vfio device file descriptor.
If the mmap MemoryRegion is enabled and results in one of these
sub-page gaps, QEMU handles the access as RAM, using memcpy to the
mmap. Using either pread/pwrite or the mmap directly should be
correct, but using memcpy causes us problems. I expect that not only
does memcpy not necessarily honor the original width and alignment in
performing a copy, but it potentially also uses processor instructions
not intended for MMIO spaces. It turns out that this has been a
problem for Realtek NIC assignment, which has such a quirk that
creates a sub-page mmap MemoryRegion access.
To resolve this, we disable memory_access_is_direct() for ram_device
regions since QEMU assumes that it can use memcpy for those regions.
Instead we access through MemoryRegionOps, which replaces the memcpy
with simple de-references of standard sizes to the host memory.
With this patch we attempt to provide unrestricted access to the RAM
device, allowing byte through qword access as well as unaligned
access. The assumption here is that accesses initiated by the VM are
driven by a device specific driver, which knows the device
capabilities. If unaligned accesses are not supported by the device,
we don't want them to work in a VM by performing multiple aligned
accesses to compose the unaligned access. A down-side of this
philosophy is that the xp command from the monitor attempts to use
the largest available access weidth, unaware of the underlying
device. Using memcpy had this same restriction, but at least now an
operator can dump individual registers, even if blocks of device
memory may result in access widths beyond the capabilities of a
given device (RTL NICs only support up to dword).
Reported-by: Thorsten Kohfeldt <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>
Acked-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 4a2e242bbb306ef5c16ce9e7bb2da3bd8a4eb098)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1790a9d77d5d063f720907bec3fdb9b5a5e11d65
https://github.com/qemu/qemu/commit/1790a9d77d5d063f720907bec3fdb9b5a5e11d65
Author: Corey Minyard <address@hidden>
Date: 2016-11-18 (Fri, 18 Nov 2016)
Changed paths:
M hw/acpi/ipmi.c
Log Message:
-----------
acpi/ipmi: Initialize the fwinfo before fetching it
The initialization was missed before, resulting in some
bad data in the smbus case.
Signed-off-by: Corey Minyard <address@hidden>
Cc: address@hidden
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 698ae42b9124dce23e03d0fea2e635b70540ef13)
Signed-off-by: Michael Roth <address@hidden>
Commit: 95a0638043d377bccbac5c9f2c0e6322e407e96f
https://github.com/qemu/qemu/commit/95a0638043d377bccbac5c9f2c0e6322e407e96f
Author: Daniel P. Berrange <address@hidden>
Date: 2016-11-18 (Fri, 18 Nov 2016)
Changed paths:
M net/net.c
M net/socket.c
Log Message:
-----------
net: fix sending of data with -net socket, listen backend
The use of -net socket,listen was broken in the following
commit
commit 16a3df403b10c4ac347159e39005fd520b2648bb
Author: Zhang Chen <address@hidden>
Date: Fri May 13 15:35:19 2016 +0800
net/net: Add SocketReadState for reuse codes
This function is from net/socket.c, move it to net.c and net.h.
Add SocketReadState to make others reuse net_fill_rstate().
suggestion from jason.
This refactored the state out of NetSocketState into a
separate SocketReadState. This refactoring requires
that a callback is provided to be triggered upon
completion of a packet receive from the guest.
The patch only registered this callback in the codepaths
hit by -net socket,connect, not -net socket,listen. So
as a result packets sent by the guest in the latter case
get dropped on the floor.
This bug is hidden because net_fill_rstate() silently
does nothing if the callback is not set.
This patch adds in the middle callback registration
and also adds an assert so that QEMU aborts if there
are any other codepaths hit which are missing the
callback.
Signed-off-by: Daniel P. Berrange <address@hidden>
Reviewed-by: Zhang Chen <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit e79cd4068063ea2859199002a049010a11202939)
Signed-off-by: Michael Roth <address@hidden>
Commit: 9df69dcd143fe1e56083c456cc96eb92c367f336
https://github.com/qemu/qemu/commit/9df69dcd143fe1e56083c456cc96eb92c367f336
Author: David Gibson <address@hidden>
Date: 2016-12-02 (Fri, 02 Dec 2016)
Changed paths:
M target-ppc/cpu.h
M target-ppc/machine.c
Log Message:
-----------
target-ppc: Fix CPU migration from qemu-2.6 <-> later versions
When migration for target-ppc was converted to vmstate, several
VMSTATE_EQUAL() checks were foolishly included of things that really
should be internal state. Specifically we verified equality of the
insns_flags and insns_flags2 fields, which are used within TCG to
determine which groups of instructions are available on this cpu
model. Between qemu-2.6 and qemu-2.7 we made some changes to these
classes which broke migration.
This path fixes migration both forwards and backwards. On migration
from 2.6 to later versions we import the fields into teporary
variables, which we then ignore. In migration backwards, we populate
the temporary fields from the runtime fields, but mask out the bits
which were added after qemu-2.6, allowing the VMSTATE_EQUAL in
qemu-2.6 to accept the stream.
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Dr. David Alan Gilbert <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit 16a2497bd44cac1856e259654fd304079bd1dcdc)
Signed-off-by: Michael Roth <address@hidden>
Commit: 63087cd74bb16f867a5c6264ee4d86f5989c895b
https://github.com/qemu/qemu/commit/63087cd74bb16f867a5c6264ee4d86f5989c895b
Author: Michael S. Tsirkin <address@hidden>
Date: 2016-12-08 (Thu, 08 Dec 2016)
Changed paths:
M hw/s390x/virtio-ccw.c
M hw/virtio/virtio-pci.c
M hw/virtio/virtio.c
M include/hw/virtio/virtio.h
Log Message:
-----------
virtio: allow per-device-class legacy features
Legacy features are those that transitional devices only
expose on the legacy interface.
Allow different ones per device class.
Cc: address@hidden # dependency for the next patch
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
(cherry picked from commit 9b706dbbbb81f5cb7c67e491d38cd6077205e056)
Conflicts:
hw/virtio/virtio.c
* drop context dep on ff4c07df
* resolv func dep on ff4c07df creating vdc variable in
virtio_device_class_init()
Signed-off-by: Michael Roth <address@hidden>
Commit: f1372d6e1489d01f3accbd6a3e5c4d45fa27ed45
https://github.com/qemu/qemu/commit/f1372d6e1489d01f3accbd6a3e5c4d45fa27ed45
Author: Michael S. Tsirkin <address@hidden>
Date: 2016-12-08 (Thu, 08 Dec 2016)
Changed paths:
M hw/net/virtio-net.c
Log Message:
-----------
virtio-net: mark VIRTIO_NET_F_GSO as legacy
virtio 1.0 spec says this is a legacy feature bit,
hide it from guests in modern mode.
Note: for cross-version migration compatibility,
we keep the bit set in host_features.
The result will be that a guest migrating cross-version
will see host features change under it.
As guests only seem to read it once, this should
not be an issue. Meanwhile, will work to fix guests to
ignore this bit in virtio1 mode, too.
Cc: address@hidden
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
(cherry picked from commit 2a083ffd2e37ef08769749a5c7cfc6ca65c9f8ea)
Signed-off-by: Michael Roth <address@hidden>
Commit: 48b3aa20ae7246500920c6c2c896efb45217fa08
https://github.com/qemu/qemu/commit/48b3aa20ae7246500920c6c2c896efb45217fa08
Author: Kevin Wolf <address@hidden>
Date: 2016-12-08 (Thu, 08 Dec 2016)
Changed paths:
M block/io.c
M tests/qemu-iotests/026.out
M tests/qemu-iotests/026.out.nocache
M tests/qemu-iotests/071.out
Log Message:
-----------
block: Don't mark node clean after failed flush
Commit 3ff2f67a changed bdrv_co_flush() so that no flush is issues if
the image hasn't been dirtied since the last flush. This is not quite
correct: The condition should be that the image hasn't been dirtied
since the last _successful_ flush. This patch changes the logic
accordingly.
Without this fix, subsequent bdrv_co_flush() calls would return success
without actually doing anything even though the image is still dirty.
The difference is visible in some blkdebug test cases where error
messages incorrectly disappeared after commit 3ff2f67a.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Denis V. Lunev <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: John Snow <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit e6af1e085416378918cca357bf2abd8b90224667)
Conflicts:
block/io.c
* remove context dep on 9972354
Signed-off-by: Michael Roth <address@hidden>
Commit: 92230a5963d308f1ce0ba222bfb3a921f59e1446
https://github.com/qemu/qemu/commit/92230a5963d308f1ce0ba222bfb3a921f59e1446
Author: Greg Kurz <address@hidden>
Date: 2016-12-08 (Thu, 08 Dec 2016)
Changed paths:
M hw/virtio/vhost.c
M include/hw/virtio/vhost.h
Log Message:
-----------
vhost: adapt vhost_verify_ring_mappings() to virtio 1 ring layout
With virtio 1, the vring layout is split in 3 separate regions of
contiguous memory for the descriptor table, the available ring and the
used ring, as opposed with legacy virtio which uses a single region.
In case of memory re-mapping, the code ensures it doesn't affect the
vring mapping. This is done in vhost_verify_ring_mappings() which assumes
the device is legacy.
This patch changes vhost_verify_ring_mappings() to check the mappings of
each part of the vring separately.
This works for legacy mappings as well.
Cc: address@hidden
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit f1f9e6c5961ffb36fd4a81cd7edcded7bfad2ab2)
Signed-off-by: Michael Roth <address@hidden>
Commit: e9dbd28e2a312483cc15613342ab31b962980344
https://github.com/qemu/qemu/commit/e9dbd28e2a312483cc15613342ab31b962980344
Author: Samuel Thibault <address@hidden>
Date: 2016-12-08 (Thu, 08 Dec 2016)
Changed paths:
M slirp/socket.c
Log Message:
-----------
slirp: Fix access to freed memory
if_start() goes through the slirp->if_fastq and slirp->if_batchq
list of pending messages, and accesses ifm->ifq_so->so_nqueued of its
elements if ifm->ifq_so != NULL. When freeing a socket, we thus need
to make sure that any pending message for this socket does not refer
to the socket any more.
Signed-off-by: Samuel Thibault <address@hidden>
Tested-by: Brian Candler <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit ea64d5f08817b5e79e17135dce516c7583107f91)
Signed-off-by: Michael Roth <address@hidden>
Commit: c4bf37e0b0f09d9f51d8407c3e51093d44348008
https://github.com/qemu/qemu/commit/c4bf37e0b0f09d9f51d8407c3e51093d44348008
Author: Eric Blake <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Inform block layer about discard boundaries
At the qcow2 layer, discard is only possible on a per-cluster
basis; at the moment, qcow2 silently rounds any unaligned
requests to this granularity. However, an upcoming patch will
fix a regression in the block layer ignoring too much of an
unaligned discard request, by changing the block layer to
break up a discard request at alignment boundaries; for that
to work, the block layer must know about our limits.
However, we can't go one step further by changing
qcow2_discard_clusters() to assert that requests are always
aligned, since that helper function is reached on paths
outside of the block layer.
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit ecdbead659f037dc572bba9eb1cd31a5a1a9ad9a)
Signed-off-by: Michael Roth <address@hidden>
Commit: dd11d33deb8350fd2599220bf3bb79eef8547a24
https://github.com/qemu/qemu/commit/dd11d33deb8350fd2599220bf3bb79eef8547a24
Author: Eric Blake <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M block/io.c
Log Message:
-----------
block: Let write zeroes fallback work even with small max_transfer
Commit 443668ca rewrote the write_zeroes logic to guarantee that
an unaligned request never crosses a cluster boundary. But
in the rewrite, the new code assumed that at most one iteration
would be needed to get to an alignment boundary.
However, it is easy to trigger an assertion failure: the Linux
kernel limits loopback devices to advertise a max_transfer of
only 64k. Any operation that requires falling back to writes
rather than more efficient zeroing must obey max_transfer during
that fallback, which means an unaligned head may require multiple
iterations of the write fallbacks before reaching the aligned
boundaries, when layering a format with clusters larger than 64k
atop the protocol of file access to a loopback device.
Test case:
$ qemu-img create -f qcow2 -o cluster_size=1M file 10M
$ losetup /dev/loop2 /path/to/file
$ qemu-io -f qcow2 /dev/loop2
qemu-io> w 7m 1k
qemu-io> w -z 8003584 2093056
In fairness to Denis (as the original listed author of the culprit
commit), the faulty logic for at most one iteration is probably all
my fault in reworking his idea. But the solution is to restore what
was in place prior to that commit: when dealing with an unaligned
head or tail, iterate as many times as necessary while fragmenting
the operation at max_transfer boundaries.
Reported-by: Ed Swierk <address@hidden>
CC: address@hidden
CC: Denis V. Lunev <address@hidden>
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit b2f95feec5e4d546b932848dd421ec3361e8ef77)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5e4eb851ddc5c7c23c0c5705fbf917b7b3a20586
https://github.com/qemu/qemu/commit/5e4eb851ddc5c7c23c0c5705fbf917b7b3a20586
Author: Eric Blake <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M block/iscsi.c
M block/qcow2.c
M block/sheepdog.c
Log Message:
-----------
block: Return -ENOTSUP rather than assert on unaligned discards
Right now, the block layer rounds discard requests, so that
individual drivers are able to assert that discard requests
will never be unaligned. But there are some ISCSI devices
that track and coalesce multiple unaligned requests, turning it
into an actual discard if the requests eventually cover an
entire page, which implies that it is better to always pass
discard requests as low down the stack as possible.
In isolation, this patch has no semantic effect, since the
block layer currently never passes an unaligned request through.
But the block layer already has code that silently ignores
drivers that return -ENOTSUP for a discard request that cannot
be honored (as well as drivers that return 0 even when nothing
was done). But the next patch will update the block layer to
fragment discard requests, so that clients are guaranteed that
they are either dealing with an unaligned head or tail, or an
aligned core, making it similar to the block layer semantics of
write zero fragmentation.
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 49228d1e95e1be879c57f5dbccb44405670e343d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 31454ebde5ee8437b4214b8f4cce47755467439a
https://github.com/qemu/qemu/commit/31454ebde5ee8437b4214b8f4cce47755467439a
Author: Eric Blake <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M block/io.c
Log Message:
-----------
block: Pass unaligned discard requests to drivers
Discard is advisory, so rounding the requests to alignment
boundaries is never semantically wrong from the data that
the guest sees. But at least the Dell Equallogic iSCSI SANs
has an interesting property that its advertised discard
alignment is 15M, yet documents that discarding a sequence
of 1M slices will eventually result in the 15M page being
marked as discarded, and it is possible to observe which
pages have been discarded.
Between commits 9f1963b and b8d0a980, we converted the block
layer to a byte-based interface that ultimately ignores any
unaligned head or tail based on the driver's advertised
discard granularity, which means that qemu 2.7 refuses to
pass any discard request smaller than 15M down to the Dell
Equallogic hardware. This is a slight regression in behavior
compared to earlier qemu, where a guest executing discards
in power-of-2 chunks used to be able to get every page
discarded, but is now left with various pages still allocated
because the guest requests did not align with the hardware's
15M pages.
Since the SCSI specification says nothing about a minimum
discard granularity, and only documents the preferred
alignment, it is best if the block layer gives the driver
every bit of information about discard requests, rather than
rounding it to alignment boundaries early.
Rework the block layer discard algorithm to mirror the write
zero algorithm: always peel off any unaligned head or tail
and manage that in isolation, then do the bulk of the request
on an aligned boundary. The fallback when the driver returns
-ENOTSUP for an unaligned request is to silently ignore that
portion of the discard request; but for devices that can pass
the partial request all the way down to hardware, this can
result in the hardware coalescing requests and discarding
aligned pages after all.
Reported by: Peter Lieven <address@hidden>
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 3482b9bc411a9a12b2efde1018e1ddc906cd817e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 6a5ea68e9ef13c02eeb2064a3d093c53a6e31383
https://github.com/qemu/qemu/commit/6a5ea68e9ef13c02eeb2064a3d093c53a6e31383
Author: Max Reitz <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M block/curl.c
Log Message:
-----------
block/curl: Use BDRV_SECTOR_SIZE
Currently, curl defines its own constant SECTOR_SIZE. There is no
advantage over using the global BDRV_SECTOR_SIZE, so drop it.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit 9054d9f6b00a3f0576b1a7310a3886d1783ad382)
Conflicts:
block/curl.c
* drop context dep on fffb6e1 / aio_bh_schedule_oneshot
Signed-off-by: Michael Roth <address@hidden>
Commit: 7e278ef797c4ddc46315c5f1e867b76e6cbba879
https://github.com/qemu/qemu/commit/7e278ef797c4ddc46315c5f1e867b76e6cbba879
Author: Max Reitz <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M block/curl.c
Log Message:
-----------
block/curl: Fix return value from curl_read_cb
While commit 38bbc0a580f9f10570b1d1b5d3e92f0e6feb2970 is correct in that
the callback is supposed to return the number of bytes handled; what it
does not mention is that libcurl will throw an error if the callback did
not "handle" all of the data passed to it.
Therefore, if the callback receives some data that it cannot handle
(either because the receive buffer has not been set up yet or because it
would not fit into the receive buffer) and we have to ignore it, we
still have to report that the data has been handled.
Obviously, this should not happen normally. But it does happen at least
for FTP connections where some data (that we do not expect) may be
generated when the connection is established.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit 4e7676571bccb42dd49b5efbb91ac49077ea5197)
Signed-off-by: Michael Roth <address@hidden>
Commit: 6eb194ddd7a49145013df3880d78fc3bfedbee56
https://github.com/qemu/qemu/commit/6eb194ddd7a49145013df3880d78fc3bfedbee56
Author: Max Reitz <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M block/curl.c
Log Message:
-----------
block/curl: Remember all sockets
For some connection types (like FTP, generally), more than one socket
may be used (in FTP's case: control vs. data stream). As of commit
838ef602498b8d1985a231a06f5e328e2946a81d ("curl: Eliminate unnecessary
use of curl_multi_socket_all"), we have to remember all of the sockets
used by libcurl, but in fact we only did that for a single one. Since
one libcurl connection may use multiple sockets, however, we have to
remember them all.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit ff5ca1664af85b24a4180d595ea6873fd3deac57)
Signed-off-by: Michael Roth <address@hidden>
Commit: 48fdfebab6469d748b7e85ae96b15e052e5efe0d
https://github.com/qemu/qemu/commit/48fdfebab6469d748b7e85ae96b15e052e5efe0d
Author: Max Reitz <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M block/curl.c
Log Message:
-----------
block/curl: Do not wait for data beyond EOF
libcurl will only give us as much data as there is, not more. The block
layer will deny requests beyond the end of file for us; but since this
block driver is still using a sector-based interface, we can still get
in trouble if the file size is not a multiple of 512.
While we have already made sure not to attempt transfers beyond the end
of the file, we are currently still trying to receive data from there if
the original request exceeds the file size. This patch fixes this issue
and invokes qemu_iovec_memset() on the iovec's tail.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit 4e504535c16dfa66290281e704384abfaca08673)
Signed-off-by: Michael Roth <address@hidden>
Commit: c8a3159df41f1da9f8b25b9d6387cd1b78b0f4b2
https://github.com/qemu/qemu/commit/c8a3159df41f1da9f8b25b9d6387cd1b78b0f4b2
Author: Greg Kurz <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M hw/virtio/vhost.c
M include/hw/virtio/vhost.h
Log Message:
-----------
vhost: drop legacy vring layout bits
The legacy vring layout is not used anymore as we use the separate
mappings even for legacy devices.
This patch simply removes it.
This also fixes a bug with virtio 1 devices when the vring descriptor table
is mapped at a higher address than the used vring because the following
function may return an insanely great value:
hwaddr virtio_queue_get_ring_size(VirtIODevice *vdev, int n)
{
return vdev->vq[n].vring.used - vdev->vq[n].vring.desc +
virtio_queue_get_used_size(vdev, n);
}
and the mapping fails.
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 1cdce7c54d26e64f5eddb10a6f4f7dd938dfc2c4)
Signed-off-by: Michael Roth <address@hidden>
Commit: 353801cde4e1e98cc1e2790f92cf934adac9f7dd
https://github.com/qemu/qemu/commit/353801cde4e1e98cc1e2790f92cf934adac9f7dd
Author: Zhuang Yanying <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M hw/misc/ivshmem.c
Log Message:
-----------
ivshmem: Fix 64 bit memory bar configuration
Device ivshmem property use64=0 is designed to make the device
expose a 32 bit shared memory BAR instead of 64 bit one. The
default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit
BAR. A 32 bit BAR can support only up to 1 GiB of shared memory.
This worked as designed until commit 5400c02 accidentally flipped
its sense: since then, we misinterpret use64=0 as use64=1 and vice
versa. Worse, the default got flipped as well. Devices
ivshmem-plain and ivshmem-doorbell are not affected.
Fix by restoring the test of IVShmemState member not_legacy_32bit
that got messed up in commit 5400c02. Also update its
initialization for devices ivhsmem-plain and ivshmem-doorbell.
Without that, they'd regress to 32 bit BARs.
Cc: address@hidden
Signed-off-by: Zhuang Yanying <address@hidden>
Reviewed-by: Gonglei <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
Reviewed-by: Markus Armbruster <address@hidden>
(cherry picked from commit be4e0d737527d8670dc271712faae0de6a181b4e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 80f630be2105a6957c8125b789e04573064438d2
https://github.com/qemu/qemu/commit/80f630be2105a6957c8125b789e04573064438d2
Author: Peter Xu <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M hw/i386/kvm/pci-assign.c
Log Message:
-----------
pci-assign: sync MSI/MSI-X cap and table with PCIDevice
Since commit e1d4fb2d ("kvm-irqchip: x86: add msi route notify fn"),
kvm_irqchip_add_msi_route() starts to use pci_get_msi_message() to fetch
MSI info. This requires that we setup MSI related fields in PCIDevice.
For most devices, that won't be a problem, as long as we are using
general interfaces like msi_init()/msix_init().
However, for pci-assign devices, MSI/MSI-X is treated differently - PCI
assign devices are maintaining its own MSI table and cap information in
AssignedDevice struct. however that's not synced up with PCIDevice's
fields. That will leads to pci_get_msi_message() failed to find correct
MSI capability, even with an NULL msix_table.
A quick fix is to sync up the two places: both the capability bits and
table address for MSI/MSI-X.
Reported-by: Changlimin <address@hidden>
Tested-by: Changlimin <address@hidden>
Cc: address@hidden
Fixes: e1d4fb2d ("kvm-irqchip: x86: add msi route notify fn")
Signed-off-by: Peter Xu <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 64e184e2608d3c93dda1bba8ae6dc2185b5228fb)
Signed-off-by: Michael Roth <address@hidden>
Commit: 248a780fd31ca218d2652c8a4ca19ca8abefb472
https://github.com/qemu/qemu/commit/248a780fd31ca218d2652c8a4ca19ca8abefb472
Author: Adrian Bunk <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M rules.mak
Log Message:
-----------
rules.mak: Use -r instead of -Wl, -r to fix building when PIE is default
Building qemu fails in distributions where gcc enables PIE by default
(e.g. Debian unstable) with:
/usr/bin/ld: -r and -pie may not be used together
Use -r instead of -Wl,-r to avoid gcc passing -pie to the linker
when PIE is enabled and a relocatable object is passed.
Signed-off-by: Adrian Bunk <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit c96f0ee6a67ca6277366e78ce5d84d5c20dd596f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0ef167c907c13dc706ac08e96a095ff5c7d75445
https://github.com/qemu/qemu/commit/0ef167c907c13dc706ac08e96a095ff5c7d75445
Author: Peter Xu <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M hw/i386/intel_iommu.c
Log Message:
-----------
intel_iommu: fix incorrect device invalidate
"mask" needs to be inverted before use.
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 6cb99acc2808cc41e2d772a23e9cc564515535cc)
Signed-off-by: Michael Roth <address@hidden>
Commit: ee99e42be451516580bc54af8328d73e0904efbd
https://github.com/qemu/qemu/commit/ee99e42be451516580bc54af8328d73e0904efbd
Author: Eduardo Habkost <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M tests/Makefile.include
M tests/vhost-user-test.c
Log Message:
-----------
vhost-user-test: Use libqos instead of pxe-virtio.rom
vhost-user-test relies on iPXE just to initialize the virtio-net
device, and doesn't do any actual packet tx/rx testing.
In addition to that, the test relies on TCG, which is
imcompatible with vhost. The test only worked by accident: a bug
the memory backend initialization made memory regions not have
the DIRTY_MEMORY_CODE bit set in dirty_log_mask.
This changes vhost-user-test to initialize the virtio-net device
using libqos, and not use TCG nor pxe-virtio.rom.
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit cdafe929615ec5eca71bcd5a3d12bab5678e5886)
Signed-off-by: Michael Roth <address@hidden>
Commit: cc1fd252953405342491d93f3dc4406c8a6296fb
https://github.com/qemu/qemu/commit/cc1fd252953405342491d93f3dc4406c8a6296fb
Author: Eduardo Habkost <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M vl.c
Log Message:
-----------
vl: Delay initialization of memory backends
Initialization of memory backends may take a while when
prealloc=yes is used, depending on their size. Initializing
memory backends before chardevs may delay the creation of monitor
sockets, and trigger timeouts on management software that waits
until the monitor socket is created by QEMU. See, for example,
the bug report at:
https://bugzilla.redhat.com/show_bug.cgi?id=1371211
In addition to that, allocating memory before calling
configure_accelerator() breaks the tcg_enabled() checks at
memory_region_init_*().
This patch fixes those problems by adding "memory-backend-*"
classes to the delayed-initialization list.
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 6546d0dba6c211c1a3eac1252a4f50a0c151a08a)
Signed-off-by: Michael Roth <address@hidden>
Commit: db1604cd60f1736098eec4feba099b9bd885b8ed
https://github.com/qemu/qemu/commit/db1604cd60f1736098eec4feba099b9bd885b8ed
Author: Paolo Bonzini <address@hidden>
Date: 2016-12-12 (Mon, 12 Dec 2016)
Changed paths:
M hw/scsi/megasas.c
Log Message:
-----------
Revert "megasas: remove useless check for cmd->frame"
This reverts commit 8cc46787b5b58f01a11c919c7ff939ed009e27fc.
It turns out that cmd->frame can be NULL and thus the commit
can cause a SIGSEGV
Reported-by: Holger Schranz <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 421cc3e7e89cb807d3c5f6de486abb2167c8e792)
Signed-off-by: Michael Roth <address@hidden>
Commit: 7f7ac2141e3c71a6be354d3928cfa24a64268a70
https://github.com/qemu/qemu/commit/7f7ac2141e3c71a6be354d3928cfa24a64268a70
Author: Lin Ma <address@hidden>
Date: 2016-12-14 (Wed, 14 Dec 2016)
Changed paths:
M backends/msmouse.c
Log Message:
-----------
msmouse: Fix segfault caused by free the chr before chardev cleanup.
Segfault happens when leaving qemu with msmouse backend:
#0 0x00007fa8526ac975 in raise () at /lib64/libc.so.6
#1 0x00007fa8526add8a in abort () at /lib64/libc.so.6
#2 0x0000558be78846ab in error_exit (err=16, msg=0x558be799da10 ...
#3 0x0000558be7884717 in qemu_mutex_destroy (mutex=0x558be93be750) at ...
#4 0x0000558be7549951 in qemu_chr_free_common (chr=0x558be93be750) at ...
#5 0x0000558be754999c in qemu_chr_free (chr=0x558be93be750) at ...
#6 0x0000558be7549a20 in qemu_chr_delete (chr=0x558be93be750) at ...
#7 0x0000558be754a8ef in qemu_chr_cleanup () at qemu-char.c:4643
#8 0x0000558be755843e in main (argc=5, argv=0x7ffe925d7118, ...
The chr was freed by msmouse close callback before chardev cleanup,
Then qemu_mutex_destroy triggered raise().
Because freeing chr is handled by qemu_chr_free_common, Remove the free from
msmouse_chr_close to avoid double free.
Fixes: c1111a24a3358ecd2f17be7c8b117cfe8bc5e5f8
Cc: address@hidden
Signed-off-by: Lin Ma <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 9e14037f05e99ca3b8a33d8be9a2a636bbf09326)
Signed-off-by: Michael Roth <address@hidden>
Commit: 223d1a2da1713adba84115150bd59bd2f9d06866
https://github.com/qemu/qemu/commit/223d1a2da1713adba84115150bd59bd2f9d06866
Author: Thorsten Kohfeldt <address@hidden>
Date: 2016-12-14 (Wed, 14 Dec 2016)
Changed paths:
M hw/vfio/pci-quirks.c
Log Message:
-----------
vfio/pci: Fix vfio_rtl8168_quirk_data_read address offset
Introductory comment for rtl8168 VFIO MSI-X quirk states:
At BAR2 offset 0x70 there is a dword data register,
offset 0x74 is a dword address register.
vfio: vfio_bar_read(0000:05:00.0:BAR2+0x70, 4) = 0xfee00398 // read data
Thus, correct offset for data read is 0x70,
but function vfio_rtl8168_quirk_data_read() wrongfully uses offset 0x74.
Signed-off-by: Thorsten Kohfeldt <address@hidden>
Signed-off-by: Alex Williamson <address@hidden>
(cherry picked from commit 31e6a7b17b35711eb44f0e686b5ba68d15bfe4c1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 05838b4688393f3cf9949aa1f707a35618b725c6
https://github.com/qemu/qemu/commit/05838b4688393f3cf9949aa1f707a35618b725c6
Author: Stefan Hajnoczi <address@hidden>
Date: 2016-12-20 (Tue, 20 Dec 2016)
Changed paths:
M ui/gtk.c
Log Message:
-----------
ui/gtk: fix "Copy" menu item segfault
The "Copy" menu item copies VTE terminal text to the clipboard. This
only works with VTE terminals, not with graphics consoles.
Disable the menu item when the current notebook page isn't a VTE
terminal.
This patch fixes a segfault. Reproducer: Start QEMU and click the Copy
menu item when the guest display is visible.
Reported-by: Kevin Wolf <address@hidden>
Reviewed-by: Gerd Hoffmann <address@hidden>
Tested-by: Stefan Weil <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
Message-id: address@hidden
Cc: Michael S. Tsirkin <address@hidden>
Cc: Gerd Hoffmann <address@hidden>
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit a08156321ab9a7d2fed9ee77dbfeea2a61ffd153)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5f20161cf30a7f4e543578177887c9c02747ce27
https://github.com/qemu/qemu/commit/5f20161cf30a7f4e543578177887c9c02747ce27
Author: John Snow <address@hidden>
Date: 2016-12-20 (Tue, 20 Dec 2016)
Changed paths:
M hw/ide/atapi.c
Log Message:
-----------
atapi: classify read_cd as conditionally returning data
For the purposes of byte_count_limit verification, add a new flag that
identifies read_cd as sometimes returning data, then check the BCL in
its command handler after we know that it will indeed return data.
Reported-by: Hervé Poussineau <address@hidden>
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit e7bd708ec85e40fd51569bb90c52d6613ffd8f45)
Signed-off-by: Michael Roth <address@hidden>
Commit: 8d5f2a75702b1975f8f2f2b866bde0b60493e3c3
https://github.com/qemu/qemu/commit/8d5f2a75702b1975f8f2f2b866bde0b60493e3c3
Author: Mark Cave-Ayland <address@hidden>
Date: 2016-12-21 (Wed, 21 Dec 2016)
Changed paths:
M dma-helpers.c
M hw/block/nvme.c
M hw/ide/ahci.c
M hw/ide/core.c
M hw/scsi/scsi-disk.c
M include/sysemu/dma.h
Log Message:
-----------
dma-helpers: explicitly pass alignment into DMA helpers
The hard-coded default alignment is BDRV_SECTOR_SIZE, however this is not
necessarily the case for all platforms. Use this as the default alignment for
all current callers.
Signed-off-by: Mark Cave-Ayland <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Acked-by: John Snow <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 99868af3d0a75cf6a515a9aa81bf0d7bcb39eadb)
Signed-off-by: Michael Roth <address@hidden>
Commit: 345f1cd9f6e4f156c7af0098b3d220305037f227
https://github.com/qemu/qemu/commit/345f1cd9f6e4f156c7af0098b3d220305037f227
Author: John Snow <address@hidden>
Date: 2016-12-21 (Wed, 21 Dec 2016)
Changed paths:
M block/block-backend.c
Log Message:
-----------
block-backend: Always notify on blk_eject
blk_eject is only used by scsi-disk and atapi, and in both cases we
only attempt to invoke blk_eject if we have a bona-fide change in
tray state.
The "issue" here is that the tray state does not generate a QMP event
unless there is a medium/BDS attached to the device, so if libvirt et al
are waiting for a tray event to occur from an empty-but-closed drive,
software opening that drive will not emit an event and libvirt will
wait forever.
Change this by modifying blk_eject to always emit an event, instead of
conditionally on a "real" backend eject.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1373264
Reported-by: Peter Krempa <address@hidden>
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Kevin Wolf <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit c47ee043dc2cc85da710e87524144a720598c096)
* dropped functional depedenecy on 2d76e724
Signed-off-by: Michael Roth <address@hidden>
Commit: 7d17d68971903467c5d5edd035f6ee18a8b11742
https://github.com/qemu/qemu/commit/7d17d68971903467c5d5edd035f6ee18a8b11742
Author: Marc-André Lureau <address@hidden>
Date: 2016-12-21 (Wed, 21 Dec 2016)
Changed paths:
M hw/audio/gus.c
M hw/audio/sb16.c
M hw/block/fdc.c
M hw/char/parallel.c
M hw/display/vga-isa.c
M hw/dma/i8257.c
M hw/ide/core.c
M hw/isa/isa-bus.c
M include/hw/ide/internal.h
M include/hw/isa/i8257.h
M include/hw/isa/isa.h
Log Message:
-----------
portio: keep references on portio
The isa_register_portio_list() function allocates ioports
data/state. Let's keep the reference to this data on some owner. This
isn't enough to fix leaks, but at least, ASAN stops complaining of
direct leaks. Further cleanup would require calling
portio_list_del/destroy().
Signed-off-by: Marc-André Lureau <address@hidden>
Reviewed-by: Paolo Bonzini <address@hidden>
(cherry picked from commit e305a16510afa74eec20390479e349402e55ef4c)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4dde694191741a2a59a1a1eb91433a971c7baf80
https://github.com/qemu/qemu/commit/4dde694191741a2a59a1a1eb91433a971c7baf80
Author: Ashijeet Acharya <address@hidden>
Date: 2016-12-21 (Wed, 21 Dec 2016)
Changed paths:
M hw/ide/core.c
M hw/ide/qdev.c
M include/hw/ide/internal.h
Log Message:
-----------
ide: Fix memory leak in ide_register_restart_cb()
Fix a memory leak in ide_register_restart_cb() in hw/ide/core.c and add
idebus_unrealize() in hw/ide/qdev.c to have calls to
qemu_del_vm_change_state_handler() to deal with the dangling change
state handler during hot-unplugging ide devices which might lead to a
crash.
Signed-off-by: Ashijeet Acharya <address@hidden>
Reviewed-by: John Snow <address@hidden>
Message-id: address@hidden
[Minor whitespace fix --js]
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit ca44141d5fb801dd5903102acefd0f2d8e8bb6a1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0d83fccb4fb3140d21feeb37ba069ba71029aaa7
https://github.com/qemu/qemu/commit/0d83fccb4fb3140d21feeb37ba069ba71029aaa7
Author: Michael Roth <address@hidden>
Date: 2016-12-23 (Fri, 23 Dec 2016)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 2.7.1 release
Signed-off-by: Michael Roth <address@hidden>
Compare: https://github.com/qemu/qemu/compare/c1a77fd6fa3c^...0d83fccb4fb3
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] c1a77f: Merge tag 'ppc-for-2.7-20161013' into stable-2.7-s...,
GitHub <=