Select Git revision
Search by author
- Any Author
- authors
-
Adrien Ricciardi
RICCIARDI-Adrien-BayLibre
-
Alexandre Bailon abailon
-
Andrew Stubbs
ams
-
Anne Françoise Gros afgros
-
BayLibreCI baylibreCI
-
Bernhard Rosenkränzer
bero
-
Carlo Caione carlo.caione
-
Christophe Baylibre
BLChristopheCBO
-
Drew Fustini dfustini
-
Guillaume LA ROQUE glaroque
-
Guillaume Pain gpain
-
Guillaume Ranquet granquet
-
Jeremy Robinson jrobinson
-
Jerome Brunet
jbrunet
-
Julien Masson
JulienMasson
-
Julien Morin
jmorin2
-
Julien Stephan jstephan
-
Jérémie Garcia jgarcia
-
Kevin Hilman khilman
-
Markus Schneider-Pargmann msp8
- Jul 22, 2014
-
-
Michael Roth authored
Signed-off-by:Michael Roth <mdroth@linux.vnet.ibm.com>
-
- Jul 16, 2014
-
-
Dr. David Alan Gilbert authored
Commit 'virtio: validate config_len on load' restricted config_len loaded from the wire to match the config_len that the device had. Unfortunately, there are cases where this isn't true, the one we found it on was the wce addition in virtio-blk. Allow mismatched config-lengths: *) If the version on the wire is shorter then fine *) If the version on the wire is longer, load what we have space for and skip the rest. (This is mst@redhat.com's rework of what I originally posted) Signed-off-by:Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Le Tan authored
In function do_pci_register_device() in file hw/pci/pci.c, move the assignment of pci_dev->devfn to the position before the call to pci_device_iommu_address_space(pci_dev) which will use the value of pci_dev->devfn. Fixes: 9eda7d37 pci: Introduce helper to retrieve a PCI device's DMA address space Cc: qemu-stable@nongnu.org Signed-off-by:
Le Tan <tamlokveer@gmail.com> Reviewed-by:
-
Andreas Färber authored
Replace qemu_allocate_irqs(foo, bar, 1)[0] with qemu_allocate_irq(foo, bar, 0). This avoids leaking the dereferenced qemu_irq *. Cc: Markus Armbruster <armbru@redhat.com> Reviewed-by:
Peter Crosthwaite <peter.crosthwaite@xilinx.com> Reviewed-by:
Peter Maydell <peter.maydell@linaro.org> Signed-off-by:
Andreas Färber <afaerber@suse.de> [PC Changes: * Applied change to instance in sh4/sh7750.c ] Signed-off-by:
Kirill Batuzov <batuzovk@ispras.ru> [AF: Fix IRQ index in sh4/sh7750.c] Cc: qemu-stable@nongnu.org Signed-off-by:
-
Andreas Färber authored
It does a g_free() on the pointer, so don't pass a local &foo reference. Reviewed-by:
-
Markus Armbruster authored
VncTight member uint8_t quality is either (uint8_t)-1 for lossless or less than 10 for lossy. tight_detect_smooth_image() first promotes it to int, then compares with -1. Always unequal, so we always execute the lossy code. Reads beyond tight_conf[] and returns crap when quality is actually lossless. Compare to (uint8_t)-1 instead, like we do elsewhere. Spotted by Coverity. Signed-off-by:
Markus Armbruster <armbru@redhat.com> Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 2e7bcdb9) Signed-off-by:
-
Michael Roth authored
In general QMP command parameter values are specified by consumers of the QMP/HMP interface, but in the case of optional parameters these values may be left uninitialized. It is considered a bug for code to make use of optional parameters that have not been flagged as being present by the marshalling code (via corresponding has_<parameter> parameter), however our marshalling code will still pass these uninitialized values on to the corresponding QMP function (to then be ignored). Some compilers (clang in particular) consider this unsafe however, and generate warnings as a result. As reported by Peter Maydell: This is something clang's -fsanitize=undefined spotted. The code generated by qapi-commands.py in qmp-marshal.c for qmp_marshal_* functions where there are some optional arguments looks like this: bool has_force = false; bool force; mi = qmp_input_visitor_new_strict(QOBJECT(args)); v = qmp_input_get_visitor(mi); visit_type_str(v, &device, "device", errp); visit_start_optional(v, &has_force, "force", errp); if (has_force) { visit_type_bool(v, &force, "force", errp); } visit_end_optional(v, errp); qmp_input_visitor_cleanup(mi); if (error_is_set(errp)) { goto out; } qmp_eject(device, has_force, force, errp); In the case where has_force is false, we never initialize force, but then we use it by passing it to qmp_eject. I imagine we don't then actually use the value, but clang complains in particular for 'bool' variables because the value that ends up being loaded from memory for 'force' is not either 0 or 1 (being uninitialized stack contents). Fix this by initializing all QMP command parameters to {0} in the marshalling code prior to passing them on to the QMP functions. Signed-off-by:Eric Blake <eblake@redhat.com> Reviewed-by:
Luiz Capitulino <lcapitulino@redhat.com> (cherry picked from commit fc13d937) Signed-off-by:
-
Hani Benhabiles authored
This forces finishing data sending to client before closing the socket like in exports listing or replying with NBD_REP_ERR_UNSUP cases. Signed-off-by:
Hani Benhabiles <kroosec@gmail.com> Cc: qemu-stable@nongnu.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 27e5eae4) Signed-off-by:
-
Hani Benhabiles authored
Otherwise, the nbd client may hang waiting for the server response. Signed-off-by:
Hani Benhabiles <hani@linux.com> Acked-by:
Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 36af5994) Signed-off-by:
-
Hani Benhabiles authored
These values aren't used in this case. Currently, the from field in the request sent by the nbd kernel module leading to a false error message when ending the connection with the client. $ qemu-nbd some.img -v // After nbd-client -d /dev/nbd0 nbd.c:nbd_trip():L1031: From: 18446744073709551104, Len: 0, Size: 20971520, Offset: 0 nbd.c:nbd_trip():L1032: requested operation past EOF--bad client? nbd.c:nbd_receive_request():L638: read failed Signed-off-by:
-
Hani Benhabiles authored
The device is exported with erroneous values and can't be read. Before the patch: $ sudo nbd-client localhost -p 10809 /dev/nbd0 -name floppy0 Negotiation: ..size = 17592186044415MB bs=1024, sz=18446744073709547520 bytes $ sudo mount /dev/nbd0 /mnt/tmp/ mount: block device /dev/nbd0 is write-protected, mounting read-only mount: /dev/nbd0: can't read superblock After the patch: (qemu) nbd_server_add ide0-hd0 (qemu) nbd_server_add floppy0 Device 'floppy0' has no medium Signed-off-by:
-
Alexander Graf authored
The device configuration is set at realize time and never changes. It should not be migrated as it is done today. For the sake of compatibility, let's just skip them at load time. Signed-off-by:
Alexander Graf <agraf@suse.de> [ added missing casts to uint16_t *, added From, SoB and commit message, Greg Kurz <gkurz@linux.vnet.ibm.com> ] Reviewed-by:
Greg Kurz <gkurz@linux.vnet.ibm.com> Reviewed-by:
-
Cédric Le Goater authored
TCP connectivity fails when the guest has a different endianness. The packets are silently dropped on the host by the tap backend when they are read from user space because the endianness of the virtio-net header is in the wrong order. These lines may appear in the guest console: [ 454.709327] skbuff: bad partial csum: csum=8704/4096 len=74 [ 455.702554] skbuff: bad partial csum: csum=8704/4096 len=74 The issue that got first spotted with a ppc64le PowerKVM guest, but it also exists for the less common case of a x86_64 guest run by a big-endian ppc64 TCG hypervisor. Signed-off-by:
Cédric Le Goater <clg@fr.ibm.com> [ Ported from PowerKVM, Greg Kurz <gkurz@linux.vnet.ibm.com> ] Signed-off-by:
-
Eduardo Habkost authored
The TCG_7_0_EBX_FEATURES macro was defined but never used (it even had a typo that was never noticed). Make the existing TCG feature filtering code use it. Reviewed-by:
Richard Henderson <rth@twiddle.net> Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by:
-
Peter Maydell authored
A gcc codegen bug in x86_64-w64-mingw32-gcc (GCC) 4.6.3 means that non-debug builds of QEMU for Windows tend to assert when using coroutines. Work around this by marking qemu_coroutine_switch as noinline. If we allow gcc to inline qemu_coroutine_switch into coroutine_trampoline, then it hoists the code to get the address of the TLS variable "current" out of the while() loop. This is an invalid transformation because the SwitchToFiber() call may be called when running thread A but return in thread B, and so we might be in a different thread context each time round the loop. This can happen quite often. Typically. a coroutine is started when a VCPU thread does bdrv_aio_readv: VCPU thread main VCPU thread coroutine I/O coroutine bdrv_aio_readv -----> start I/O operation thread_pool_submit_co <------------ yields back to emulation Then I/O finishes and the thread-pool.c event notifier triggers in the I/O thread. event_notifier_ready calls thread_pool_co_cb, and the I/O coroutine now restarts *in another thread*: iothread main iothread coroutine I/O coroutine (formerly in VCPU thread) event_notifier_ready thread_pool_co_cb -----> current = I/O coroutine; call AIO callback But on Win32, because of the bug, the "current" being set here the current coroutine of the VCPU thread, not the iothread. noinline is a good-enough workaround, and quite unlikely to break in the future. (Thanks to Paolo Bonzini for assistance in diagnosing the problem and providing the detailed example/ascii art quoted above.) Signed-off-by: -
Alexander Graf authored
KVM tells us the number of GSIs it can handle inside the kernel. That value is basically KVM_MAX_IRQ_ROUTES. However when we try to set the GSI mapping table, it checks for r = -EINVAL; if (routing.nr >= KVM_MAX_IRQ_ROUTES) goto out; erroring out even when we're only using all of the GSIs. To make sure we never hit that limit, let's reduce the number of GSIs we get from KVM by one. Cc: qemu-stable@nongnu.org Signed-off-by: -
Hani Benhabiles authored
Due to an incomplete initialization, adding a usb-bt-dongle device through HMP or QMP will cause a segmentation fault. Signed-off-by:
-
Michael S. Tsirkin authored
vhost_verify_ring_mappings leaks mappings on error. Fix this up. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Ulrich Obergfell authored
This patch fixes a bug in scsi_block_new_request() that was introduced by commit 137745c5. If the host cache is used - i.e. if BDRV_O_NOCACHE is _not_ set - the 'break' statement needs to be executed to 'fall back' to SG_IO. Cc: qemu-stable@nongnu.org Signed-off-by:
Ulrich Obergfell <uobergfe@redhat.com> Signed-off-by:
-
Michael R. Hines authored
1. Fix small memory leak in parsing inet address from command line in data_init() 2. Fix ibv_post_send() return value check and pass error code back up correctly. 3. Fix rdma_destroy_qp() segfault after failure to connect to destination. Reported-by:
<frank.yangjie@gmail.com> Reported-by:
Michael R. Hines <mrhines@us.ibm.com> Signed-off-by:
Juan Quintela <quintela@redhat.com> (cherry picked from commit e325b49a) Signed-off-by:
-
Gonglei (Arei) authored
token should be closed in all conditions. So move CloseHandle(token) to "out" branch. Signed-off-by:
Wang Rui <moon.wangrui@huawei.com> Signed-off-by:
Gonglei <arei.gonglei@huawei.com> Signed-off-by:
-
- Jul 03, 2014
-
-
Stefan Hajnoczi authored
qemu_bh_schedule() is supposed to be thread-safe at least the first time it is called. Unfortunately this is not quite true: bh->scheduled = 1; aio_notify(bh->ctx); Since another thread may run the BH callback once it has been scheduled, there is a race condition if the callback frees the BH before aio_notify(bh->ctx) has a chance to run. Reported-by:
Stefan Priebe <s.priebe@profihost.ag> Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by:
-
Cornelia Huck authored
We should not try to store the emw portion of the irb if extended measurements are not applicable. In particular, we should not surprise the guest by storing a larger irb if it did not enable extended measurements. Cc: qemu-stable@nongnu.org Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Tested-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com> (cherry picked from commit f068d320) Signed-off-by:
-
Peter Maydell authored
The code for handling writes to the generic timer control registers had several bugs: * ISTATUS (bit 2) is read-only but we forced it to zero on any write * the check for "was IMASK (bit 1) toggled?" incorrectly used '&' where it should be '^' * the handling of IMASK was inverted: we should set the IRQ if ISTATUS is set and IMASK is clear, not if both are set The combination of these bugs meant that when running a Linux guest that uses the generic timers we would fairly quickly end up either forgetting that the timer output should be asserted, or failing to set the IRQ when the timer was unmasked. The result is that the guest never gets any more timer interrupts. Signed-off-by:
-
Richard Henderson authored
The first non-register argument isn't placed at offset 0. Cc: qemu-stable@nongnu.org Reviewed-by:
Stefan Weil <sw@weilnetz.de> Signed-off-by:
-
Peter Maydell authored
If the guest's "long" type is smaller than the host's, then our sched_getaffinity wrapper needs to round the buffer size up to a multiple of the host sizeof(long). This means that when we copy the data back from the host buffer to the guest's buffer there might be more than we can fit. Rather than overflowing the guest's buffer, handle this case by returning EINVAL or ignoring the unused extra space, as appropriate. Note that only guests using the syscall interface directly might run into this bug -- the glibc wrappers around it will always use a buffer whose size is a multiple of 8 regardless of guest architecture. Signed-off-by:
Riku Voipio <riku.voipio@linaro.org> (cherry picked from commit be3bd286) Signed-off-by:
-
Markus Armbruster authored
Introduced in commit 661a0f71. Spotted by Coverity. Signed-off-by:
Benoit Canet <benoit@irqsave.net> Signed-off-by:
Kevin Wolf <kwolf@redhat.com> (cherry picked from commit bb9cd2ee) Signed-off-by:
-
Markus Armbruster authored
Has always been leaky. Spotted by Coverity. Signed-off-by:
-
Markus Armbruster authored
Has always been leaky. Spotted by Coverity. Signed-off-by:
-
Markus Armbruster authored
On error path. Introduced in commit a046433a. Spotted by Coverity. Signed-off-by:
-
Markus Armbruster authored
Introduced in commit a8d8ecb7. Spotted by Coverity. Signed-off-by:
-
Markus Armbruster authored
bs_opts is leaked on all paths from its qdev_new() that don't got through blockdev_init(). Add the missing QDECREF(), and zap bs_opts after blockdev_init(), so the new QDECREF() does nothing when we go through blockdev_init(). Leak introduced in commit f298d071. Spotted by Coverity. Signed-off-by:
-
Markus Armbruster authored
blockdev_init() leaks bs_opts when qemu_opts_create() fails, i.e. when the ID is bad. Missed in commit ec9c10d2. Signed-off-by:
-
Stefan Weil authored
Commit 0f842f8a replaced GETPC_EXT() which was derived from GETPC() by GETRA_EXT() without fixing cputlb.c. A later patch replaced GETRA_EXT() by GETRA() in exec/softmmu_template.h which is included in cputlb.c. The TCG interpreter failed because the values returned by GETRA() were no longer explicitly set to 0. The redefinition of GETRA() introduced here fixes this. In addition, GETPC_ADJ which is also used in exec/softmmu_template.h is set to 0. Both changes reduce the compiled code size for cputlb.c by more than 100 bytes, so the normal TCG without interpreter also profits from the reduced code size and slightly faster code. Cc: qemu-stable@nongnu.org Reported-by:
Giovanni Mascellani <gio@debian.org> Signed-off-by:
-
Max Filippov authored
Use tb->pc instead of dc->pc to check for cross-page jumps. When TB translation stops at the page boundary dc->pc points to the next page allowing chaining to TBs in it, which is wrong. Cc: qemu-stable@nongnu.org Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> (cherry picked from commit 433d33c5) Signed-off-by:
-
Markus Armbruster authored
Spotted by Coverity. Signed-off-by:
-
Kevin Wolf authored
Like qcow2 since commit 6d33e8e7, error out on invalid lengths instead of silently truncating them to 1023. Also don't rely on bdrv_pread() catching integer overflows that make len negative, but use unsigned variables in the first place. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Kevin Wolf authored
A huge image size could cause s->l1_size to overflow. Make sure that images never require a L1 table larger than what fits in s->l1_size. This cannot only cause unbounded allocations, but also the allocation of a too small L1 table, resulting in out-of-bounds array accesses (both reads and writes). Cc: qemu-stable@nongnu.org Signed-off-by:
-
Kevin Wolf authored
Too large L2 table sizes cause unbounded allocations. Images actually created by qemu-img only have 512 byte or 4k L2 tables. To keep things consistent with cluster sizes, allow ranges between 512 bytes and 64k (in fact, down to 1 entry = 8 bytes is technically working, but L2 table sizes smaller than a cluster don't make a lot of sense). This also means that the number of bytes on the virtual disk that are described by the same L2 table is limited to at most 8k * 64k or 2^29, preventively avoiding any integer overflows. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Kevin Wolf authored
Huge values for header.cluster_bits cause unbounded allocations (e.g. for s->cluster_cache) and crash qemu this way. Less huge values may survive those allocations, but can cause integer overflows later on. The only cluster sizes that qemu can create are 4k (for standalone images) and 512 (for images with backing files), so we can limit it to 64k. Cc: qemu-stable@nongnu.org Signed-off-by:
-
