- Aug 19, 2014
-
-
Michael Roth authored
Signed-off-by:Michael Roth <mdroth@linux.vnet.ibm.com>
-
- Aug 18, 2014
-
-
Luiz Capitulino authored
This commit expands all uses of the INLINE macro and drop it. The reason for this is to avoid clashes with external libraries with bad name conventions and also because renaming keywords is not a good practice. Signed-off-by:
Luiz Capitulino <lcapitulino@redhat.com> (cherry picked from commit 37f6be97 ) Signed-off-by:
-
Luiz Capitulino authored
This commit expands all uses of the INLINE macro and drop it. The reason for this is to avoid clashes with external libraries with bad name conventions and also because renaming keywords is not a good practice. PS: I'm fine with this change to be licensed under softfloat-2a or softfloat-2b. Signed-off-by:
-
- Aug 16, 2014
-
-
Michael Roth authored
Signed-off-by:
-
- Aug 08, 2014
-
-
Kevin Wolf authored
When mirroring an image of a size that is not a multiple of the mirror job granularity, the last request would have the right nb_sectors argument, but a qiov that is rounded up to the next multiple of the granularity. Don't do this. This fixes a segfault that is caused by raw-posix being confused by this and allocating a buffer with request length, but operating on it with qiov length. [s/Driver/Drive/ in qemu-iotests 041 as suggested by Eric --Stefan] Reported-by:
Eric Blake <eblake@redhat.com> Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Tested-by:
Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 5a0f6fd5 ) Conflicts: tests/qemu-iotests/041.out *updated 041.out to reflect tests missing from 2.0 Signed-off-by:
-
Fam Zheng authored
All behavior and invariant should hold for images with 0 length, so add a class to repeat all the tests in TestSingleDrive. Hide two unapplicable test methods that would fail with 0 image length because it's also used as cluster size. Signed-off-by:
Fam Zheng <famz@redhat.com> Signed-off-by:
-
- Aug 07, 2014
-
-
Jeff Cody authored
Now that active layer block-commit is supported, the 'top' argument no longer needs to be mandatory. Change it to optional, with the default being the active layer in the device chain. [kwolf: Rebased and resolved conflict in tests/qemu-iotests/040] Reviewed-by:
Benoit Canet <benoit@irqsave.net> Signed-off-by:
Jeff Cody <jcody@redhat.com> Signed-off-by:
-
Fam Zheng authored
There should be a BLOCK_JOB_READY event with active commit, regardless of image length. Let's test the 0 length image case, and make sure it goes through the ready->complete process. Signed-off-by:
-
Fam Zheng authored
When mirroring or active committing a zero length image, BLOCK_JOB_READY is not reported now, instead the job completes because we short circuit the mirror job loop. This is inconsistent with non-zero length images, and only confuses management software. Let's do the same thing when seeing a 0-length image: report ready immediately; wait for block-job-cancel or block-job-complete; clear the cancel flag as existing non-zero image synced case (cancelled after ready); then jump to the exit. Reported-by:
-
Fam Zheng authored
This will unset busy flag and put coroutine to sleep, can be used to wait for QMP complete/cancel. Signed-off-by:
-
Fam Zheng authored
The direct return will skip releasing of all the resouces at immediate_exit, don't miss that. Signed-off-by:
-
Peter Maydell authored
The code in do_cpu_reset() correctly handled AArch64 CPUs when running Linux kernels, but was missing code in the branch of the if() that deals with loading ELF files. Correctly jump to the ELF entry point on reset rather than leaving the reset PC at zero. Reported-by:
Christopher Covington <cov@codeaurora.org> Signed-off-by:
Peter Maydell <peter.maydell@linaro.org> Tested-by:
-
Peter Maydell authored
The VMStateDescription for the imx_ccm device was missing its terminator. Found by static search of the codebase using a regex based on one suggested by Ian Jackson: pcregrep -rMi '(?s)VMStateField(?:(?!END_OF_LIST).)*?;' $(git grep -l 'VMStateField\[\]') Signed-off-by:
-
Laszlo Ersek authored
"vmstate_xhci_event" was introduced in commit 37352df3 ("xhci: add live migration support"), and first released in v1.6.0. The field list in this VMSD is not terminated with the VMSTATE_END_OF_LIST() macro. During normal use (ie. migration), the issue is practically invisible, because the "vmstate_xhci_event" object (with the unterminated field list) is only ever referenced -- via "vmstate_xhci_intr" -- if xhci_er_full() returns true, for the "ev_buffer" test. Since that field_exists() check (apparently) almost always returns false, we almost never traverse "vmstate_xhci_event" during migration, which hides the bug. However, Amit's vmstate checker forces recursion into this VMSD as well, and the lack of VMSTATE_END_OF_LIST() breaks the field list terminator check (field->name != NULL) in dump_vmstate_vmsd(). The result is undefined behavior, which in my case translates to infinite recursion (because the loop happens to overflow into "vmstate_xhci_intr", which then links back to "vmstate_xhci_event"). Add the missing terminator. Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Reviewed-by:
Amit Shah <amit.shah@redhat.com> Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by:
-
Chen Gang authored
If kvm_arch_remove_sw_breakpoint() in CPU_FOREACH() always be fail, it will let 'cpu' NULL. And the next kvm_arch_remove_sw_breakpoint() in QTAILQ_FOREACH_SAFE() will get NULL parameter for 'cpu'. And kvm_arch_remove_sw_breakpoint() can assumes 'cpu' must never be NULL, so need define additional temporary variable for 'cpu' to avoid the case. Cc: qemu-stable@nongnu.org Signed-off-by:
Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by:
-
KONRAD Frederic authored
This checks that s->chr is not NULL before using it. Signed-off-by:
KONRAD Frederic <fred.konrad@greensocs.com> Reviewed-by:
Peter Crosthwaite <peter.crosthwaite@xilinx.com> Signed-off-by:
-
Jason J. Herne authored
Add code to kvm_arch_get_registers and kvm_arch_put_registers to save/restore floating point registers. This missing sync was unnoticed until migration of userspace that uses fprs. Signed-off-by:
Jason J. Herne <jjherne@us.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> [Update patch to latest upstream] Cc: qemu-stable@nongnu.org Reviewed-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
Cornelia Huck <cornelia.huck@de.ibm.com> (cherry picked from commit 85ad6230 ) Signed-off-by:
-
Stefano Stabellini authored
Currently the Makefile of disas/libvixl appends -I$(SRC_PATH)/disas/libvixl to QEMU_CFLAGS. As a consequence C++ files that #include "utils.h", such as disas/libvixl/a64/instructions-a64.cc, are going to look for utils.h on all the other include paths first. When building QEMU as part of the Xen make system, another unrelated utils.h file is going to be chosen for inclusion, causing a build failure: In file included from disas/libvixl/a64/instructions-a64.cc:27:0: /qemu/disas/libvixl/a64/instructions-a64.h:88:64: error: 'rawbits_to_float' was not declared in this scope const float kFP32PositiveInfinity = rawbits_to_float(0x7f800000); Fix the problem by prepending (rather than appending) the libvixl include path to QEMU_CFLAGS. Signed-off-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by:
-
Paolo Bonzini authored
Commit 884f17c2 (aio / timers: Convert rtc_clock to be a QEMUClockType, 2013-08-21) erroneously changed an occurrence of rtc_clock to QEMU_CLOCK_REALTIME, which broke the RTC reset notifier in mc146818rtc. Fix this. I redid the patch myself since the original reporter did not sign off on his. Cc: qemu-stable@nongnu.org Reported-by:
Lb peace <peaceustc@gmail.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:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
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 authored
Malformed input can have config_len in migration stream exceed the array size allocated on destination, the result will be heap overflow. To fix, that config_len matches on both sides. CVE-2014-0182 Reported-by:
Juan Quintela <quintela@redhat.com> -- v2: use %ix and %zx to print config_len values Signed-off-by:
-
Michael S. Tsirkin authored
CVE-2013-4151 QEMU 1.0 out-of-bounds buffer write in virtio_load@hw/virtio/virtio.c So we have this code since way back when: num = qemu_get_be32(f); for (i = 0; i < num; i++) { vdev->vq[i].vring.num = qemu_get_be32(f); array of vqs has size VIRTIO_PCI_QUEUE_MAX, so on invalid input this will write beyond end of buffer. Signed-off-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:
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:
-
Don Slutz authored
QEMU 2.0 changed memory layout for isapc and pc-0.10 to pc-0.13. This prevents migration from QEMU 1.7.0 for these machine types when -m 3.5G is specified. Paolo Bonzini asked that: smbios_legacy_mode = true; has_reserved_memory = false; option_rom_has_mr = true; rom_file_has_mr = false; also be done. Cc: qemu-stable@nongnu.org Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:Don Slutz <dslutz@verizon.com> Reviewed-by:
-
- Aug 06, 2014
-
-
Gabriel L. Somlo authored
Rename the following symbols: - smbios_set_type1_defaults() to the more general smbios_set_defaults(); - bool smbios_type1_defaults to the more general smbios_defaults; - smbios_get_table() to smbios_get_table_legacy(); This patch contains no functional changes. Signed-off-by:
Gabriel Somlo <somlo@cmu.edu> Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit e6667f71) Conflicts: hw/i386/pc_piix.c hw/i386/pc_q35.c *removed dependency on 3458b2b0 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:
-
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:
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:
-
Eduardo Habkost authored
Instead of an #ifdef in the middle of the code, just set TCG_EXT2_FEATURES to a different value depending on TARGET_X86_64. Reviewed-by:
-
Max Filippov authored
On KC705 bootloader area is located at FLASH offset 0x06000000, not 0 as on older xtfpga boards. Cc: qemu-stable@nongnu.org Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> (cherry picked from commit 37ed7c4b ) 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: -
Eduardo Habkost authored
pc-q35-1.4 was incorrectly using PC_COMPAT_1_4 instead of PC_Q35_COMPAT_1_4. The only side-effect was that the hpet compat property (inherited from PC_Q35_COMPAT_1_7) was missing. Without this patch, pc-q35-1.4 inicorrectly initializes hpet-intcap to 0xff0104 (behavior introduced in QEMU 2.0, by commit 7a10ef51 ). Signed-off-by:
Markus Armbruster <armbru@redhat.com> (cherry picked from commit 48cb7f3c ) 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:
-
