summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-07-29hw/acpi/aml-build: Fix memory leakShannon Zhao1-0/+1
Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> (cherry picked from commit afcf905cff7971324c2706600ead35a1f41f417a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-29qemu-iotests: Test unaligned sub-block zero writeFam Zheng2-0/+43
Test zero write in byte range 512~1024 for 4k alignment. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-id: 1431522721-3266-4-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit ab53c44718305d3fde3d9d2251889f1cab694be2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-29block: Fix NULL deference for unaligned write if qiov is NULLFam Zheng1-2/+95
For zero write, callers pass in NULL qiov (qemu-io "write -z" or scsi-disk "write same"). Commit fc3959e466 fixed bdrv_co_write_zeroes which is the common case for this bug, but it still exists in bdrv_aio_write_zeroes. A simpler fix would be in bdrv_co_do_pwritev which is the NULL dereference point and covers both cases. So don't access it in bdrv_co_do_pwritev in this case, use three aligned writes. [Initialize ret to 0 in bdrv_co_do_zero_pwritev() to avoid uninitialized variable warning with gcc 4.9.2. --Stefan] Signed-off-by: Fam Zheng <famz@redhat.com> Message-id: 1431522721-3266-3-git-send-email-famz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 9eeb6dd1b27bd57eb4e3869290e87feac8e8b226) Conflicts: block/io.c * moved hunks into corresponding location in block.c due to lack of 61007b316 in v2.3.0 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-29Revert "block: Fix unaligned zero write"Michael Roth1-39/+6
This reverts commit fc3959e4669a1c2149b91ccb05101cfc7ae1fc05. From upstream commit d01c07f: This reverts commit fc3959e4669a1c2149b91ccb05101cfc7ae1fc05. The core write code already handles the case, so remove this duplication. Because commit 61007b316 moved the touched code from block.c to block/io.c, the change is manually reverted. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> v2.3.0 does not contain 61007b316 so we can revert the change directly. Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28fdc: force the fifo access to be in bounds of the allocated bufferPetr Matousek1-6/+11
During processing of certain commands such as FD_CMD_READ_ID and FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could get out of bounds leading to memory corruption with values coming from the guest. Fix this by making sure that the index is always bounded by the allocated memory. This is CVE-2015-3456. Signed-off-by: Petr Matousek <pmatouse@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: John Snow <jsnow@redhat.com> (cherry picked from commit e907746266721f305d67bc0718795fedee2e824c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28target-arm: Avoid buffer overrun on UNPREDICTABLE ldrd/strdPeter Maydell1-24/+32
A LDRD or STRD where rd is not an even number is UNPREDICTABLE. We were letting this fall through, which is OK unless rd is 15, in which case we would attempt to do a load_reg or store_reg to a nonexistent r16 for the second half of the double-word. Catch the odd-numbered-rd cases and UNDEF them instead. To do this we rearrange the structure of the code a little so we can put the UNDEF catches at the top before we've allocated TCG temporaries. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1431348973-21315-1-git-send-email-peter.maydell@linaro.org (cherry picked from commit 3960c336ad96c2183549c8bf32bbff93ecda7ea4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28virtio-net: fix the upper bound when trying to delete queuesJason Wang1-1/+1
Virtqueue were indexed from zero, so don't delete virtqueue whose index is n->max_queues * 2 + 1. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 27a46dcf5038e20451101ed2d5414aebf3846e27) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28usb: fix usb-net segfaultMichal Kazior1-0/+4
The dev->config pointer isn't set until guest system initializes usb devices (via usb_desc_set_config). However qemu networking can go through some motions prior to that, e.g.: #0 is_rndis (s=0x555557261970) at hw/usb/dev-network.c:653 #1 0x000055555585f723 in usbnet_can_receive (nc=0x55555641e820) at hw/usb/dev-network.c:1315 #2 0x000055555587635e in qemu_can_send_packet (sender=0x5555572660a0) at net/net.c:470 #3 0x0000555555878e34 in net_hub_port_can_receive (nc=0x5555562d7800) at net/hub.c:101 #4 0x000055555587635e in qemu_can_send_packet (sender=0x5555562d7980) at net/net.c:470 #5 0x000055555587dbca in tap_can_send (opaque=0x5555562d7980) at net/tap.c:172 The command to reproduce most reliably was: qemu-system-i386 -usb -device usb-net,vlan=0 -net tap,vlan=0 This wasn't strictly a problem with tap. Other networking endpoints (vde, user) could trigger this problem as well. Fixes: https://bugs.launchpad.net/qemu/+bug/1050823 Cc: qemu-stable@nongnu.org Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 278412d0e710e2e848c6e510f8308e5b1ed4d03e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28qcow2: Flush pending discards before allocating clusterKevin Wolf1-0/+5
Before a freed cluster can be reused, pending discards for this cluster must be processed. The original assumption was that this was not a problem because discards are only cached during discard/write zeroes operations, which are synchronous so that no concurrent write requests can cause cluster allocations. However, the discard/write zeroes operation itself can allocate a new L2 table (and it has to in order to put zero flags there), so make sure we can cope with the situation. This fixes https://bugs.launchpad.net/bugs/1349972. Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit ecbda7a22576591a84f44de1be0150faf6001f1c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28vmdk: Fix overflow if l1_size is 0x20000000Fam Zheng1-1/+2
Richard Jones caught this bug with afl fuzzer. In fact, that's the only possible value to overflow (extent->l1_size = 0x20000000) l1_size: l1_size = extent->l1_size * sizeof(long) => 0x80000000; g_try_malloc returns NULL because l1_size is interpreted as negative during type casting from 'int' to 'gsize', which yields a enormous value. Hence, by coincidence, we get a "not too bad" behavior: qemu-img: Could not open '/tmp/afl6.img': Could not open '/tmp/afl6.img': Cannot allocate memory Values larger than 0x20000000 will be refused by the validation in vmdk_add_extent. Values smaller than 0x20000000 will not overflow l1_size. Cc: qemu-stable@nongnu.org Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 13c4941cdd8685d28c7e3a09e393a5579b58db46) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28vmdk: Fix next_cluster_sector for compressed writeFam Zheng1-4/+10
This fixes the bug introduced by commit c6ac36e (vmdk: Optimize cluster allocation). Sometimes, write_len could be larger than cluster size, because it contains both data and marker. We must advance next_cluster_sector in this case, otherwise the image gets corrupted. Cc: qemu-stable@nongnu.org Reported-by: Antoni Villalonga <qemu-list@friki.cat> Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 5e82a31eb967db135fc4e688b134fb0972d62de3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28nbd/trivial: fix type cast for ioctlBogdan Purcareata1-1/+1
This fixes ioctl behavior on powerpc e6500 platforms with 64bit kernel and 32bit userspace. The current type cast has no effect there and the value passed to the kernel is still 0. Probably an issue related to the compiler, since I'm assuming the same configuration works on a similar setup on x86. Also ensure consistency with previous type cast in TRACE message. Signed-off-by: Bogdan Purcareata <bogdan.purcareata@freescale.com> Message-Id: <1428058914-32050-1-git-send-email-bogdan.purcareata@freescale.com> Cc: qemu-stable@nongnu.org [Fix parens as noticed by Michael. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit d064d9f381b00538e41f14104b88a1ae85d78865) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28Strip brackets from vnc hostJán Tomko1-1/+8
Commit v2.2.0-1530-ge556032 vnc: switch to inet_listen_opts bypassed the use of inet_parse in inet_listen, making literal IPv6 addresses enclosed in brackets fail: qemu-kvm: -vnc [::1]:0: Failed to start VNC server on `(null)': address resolution failed for [::1]:5900: Name or service not known Strip the brackets to make it work again. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 274c3b52e10466a4771d591f6298ef61e8354ce0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28block/iscsi: do not forget to logout from targetPeter Lieven1-0/+6
We actually were always impolitely dropping the connection and not cleanly logging out. CC: qemu-stable@nongnu.org Signed-off-by: Peter Lieven <pl@kamp.de> Message-id: 1429193313-4263-2-git-send-email-pl@kamp.de Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 20474e9aa040b9a255c63127f1eb873c29c54f68) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-07-28bt-sdp: fix broken uuids power-of-2 calculationStefan Hajnoczi1-1/+1
The binary search in sdp_uuid_match() only works when the number of elements to search is a power of two. lo = record->uuid; hi = record->uuids; while (hi >>= 1) if (lo[hi] <= val) lo += hi; return *lo == val; I noticed that the record->uuids calculation in sdp_service_record_build() was suspect: record->uuids = 1 << ffs(record->uuids - 1); Unlike most ffs(val) - 1 users, the expression is ffs(val - 1)! Actually ffs() is the wrong function to use for power-of-2. Use pow2ceil() to achieve the correct effect. Now the record->uuid[] array is sized correctly and the binary search in sdp_uuid_match() should work. I'm not sure how to run/test this code. Cc: Andrzej Zaborowski <balrog@zabor.org> Cc: qemu-stable@nongnu.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 1427124571-28598-2-git-send-email-stefanha@redhat.com Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 588ef9d411339012fc3c94bfad8911e9d0a517a2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2015-04-24Update version for v2.3.0 releasev2.3.0Peter Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-20Update version for v2.3.0-rc4 releasev2.3.0-rc4Peter Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-20vhost: fix log base addressMichael S. Tsirkin1-2/+5
VHOST_SET_LOG_BASE got an incorrect address, causing migration errors and potentially even memory corruption. Reported-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Amos Kong <akong@redhat.com> Message-id: 1429283565-32265-1-git-send-email-mst@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-17hmp: fix crash in 'info block -n -v'Alberto Garcia1-1/+2
The image field in BlockDeviceInfo should never be null, however bdrv_block_device_info() is not filling it in. This makes the 'info block -n -v' command crash QEMU. The proper solution is probably to move the relevant code from bdrv_query_info() to bdrv_block_device_info(), but since we're too close to the release for that this simpler workaround solves the crash. Signed-off-by: Alberto Garcia <berto@igalia.com> Message-id: 1429274688-8115-1-git-send-email-berto@igalia.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-17Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150417-2' into stagingPeter Maydell1-2/+2
MIPS patches 2015-04-17 Changes: * fix broken fulong2e # gpg: Signature made Fri Apr 17 12:14:37 2015 BST using RSA key ID 0B29DA6B # gpg: Can't check signature: public key not found * remotes/lalrae/tags/mips-20150417-2: mips: fix broken fulong2e machine Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-17Merge remote-tracking branch 'remotes/kraxel/tags/pull-fwcfg-20150414-1' ↵Peter Maydell1-0/+205
into staging fw_cfg: add documentation file (docs/specs/fw_cfg.txt) # gpg: Signature made Tue Apr 14 12:22:20 2015 BST using RSA key ID D3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" * remotes/kraxel/tags/pull-fwcfg-20150414-1: fw_cfg: add documentation file (docs/specs/fw_cfg.txt) Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-17mips: fix broken fulong2e machinePaolo Bonzini1-2/+2
After commit 5312bd8 the bonito_readl() and bonito_writel() have been accessing incorrect addresses. Consequently QEMU is crashing when trying to boot Linux kernel on fulong2e machine. Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
2015-04-17target-ppc: don't invalidate msr MSR_HVB bit in cpu_post_loadMark Cave-Ayland1-2/+2
The invalidation code introduced in commit 2360b works by inverting most bits of env->msr to ensure that hreg_store_msr() will forcibly update the CPU env state to reflect the new msr value post-migration. Unfortunately hreg_store_msr() is called with alter_hv set to 0 which preserves the MSR_HVB state from the CPU env which is now the opposite value to what it should be. Ensure that we don't invalidate the msr MSR_HVB bit during cpu_post_load so that the correct value is restored. This fixes suspend/resume for PPC64. Reported-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Alexander Graf <agraf@suse.de> Message-id: 1429255009-12751-1-git-send-email-mark.cave-ayland@ilande.co.uk Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-14fw_cfg: add documentation file (docs/specs/fw_cfg.txt)Gabriel L. Somlo1-0/+205
This document covers the guest-side hardware interface, as well as the host-side programming API of QEMU's firmware configuration (fw_cfg) device. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-04-13Update version for v2.3.0-rc3 releasev2.3.0-rc3Peter Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-13Revert seccomp tests that allow it to be used on non-x86 architecturesPeter Maydell1-7/+2
Unfortunately it turns out that libseccomp 2.2 still does not work correctly on non-x86 architectures; return to the previous configure setup of insisting on libseccomp 2.1 or better and i386/x86_64 and disabling seccomp support in all other situations. This reverts the two commits: * "seccomp: libseccomp version varying according to arch" (commit 896848f0d3e2393905845ef2b244bb2601f9df0c) * "seccomp: update libseccomp version and remove arch restriction" (commit 8e27fc200457e3f2473d0069263774d4ba17bd85) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1428670681-23032-1-git-send-email-peter.maydell@linaro.org
2015-04-13pci: Fix crash with illegal "-net nic, model=xxx" optionThomas Huth1-1/+3
Current QEMU crashes when specifying an illegal model with the "-net nic,model=xxx" option, e.g.: $ qemu-system-x86_64 -net nic,model=n/a qemu-system-x86_64: Unsupported NIC model: n/a Program received signal SIGSEGV, Segmentation fault. The gdb backtrace looks like this: 0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152 152 return err->msg; (gdb) bt 0 0x0000555555965fe0 in error_get_pretty (err=0x0) at util/error.c:152 1 0x0000555555965ffd in error_report_err (err=0x0) at util/error.c:157 2 0x0000555555809c90 in pci_nic_init_nofail (nd=0x555555e49860 <nd_table>, rootbus=0x5555564409b0, default_model=0x55555598c37b "e1000", default_devaddr=0x0) at hw/pci/pci.c:1663 3 0x0000555555691e42 in pc_nic_init (isa_bus=0x555556f71900, pci_bus=0x5555564409b0) at hw/i386/pc.c:1506 4 0x000055555569396b in pc_init1 (machine=0x5555562abbf0, pci_enabled=1, kvmclock_enabled=1) at hw/i386/pc_piix.c:248 5 0x0000555555693d27 in pc_init_pci (machine=0x5555562abbf0) at hw/i386/pc_piix.c:310 6 0x000055555572ddf5 in main (argc=3, argv=0x7fffffffe018, envp=0x7fffffffe038) at vl.c:4226 The problem is that pci_nic_init_nofail() does not check whether the err parameter from pci_nic_init has been set up and thus passes a NULL pointer to error_report_err(). Fix it by correctly checking the err parameter. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-13stm32f205: Fix SoC type nameAndreas Färber1-1/+1
The type name for the SoC device, unlike those of its sub-devices, did not follow the QOM naming conventions. While the usage is internal only, this is exposed through QMP and HMP, so fix it before release. Cc: Alistair Francis <alistair.francis@xilinx.com> Signed-off-by: Andreas Färber <afaerber@suse.de> Reviewed-by: Alistair Francis <alistair@alistair23.me> Message-id: 1428676676-23056-1-git-send-email-afaerber@suse.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-11cris: memory: Replace memory_region_init_ram with ↵Dirk Müller1-3/+2
memory_region_allocate_system_memory Commit 0b183fc871:"memory: move mem_path handling to memory_region_allocate_system_memory" split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Cc: Edgar E. Iglesias <edgar.iglesias@gmail.com> Signed-off-by: Dirk Mueller <dmueller@suse.com> Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
2015-04-10alpha: memory: Replace memory_region_init_ram with ↵Dirk Müller1-3/+2
memory_region_allocate_system_memory Commit 0b183fc871:"memory: move mem_path handling to memory_region_allocate_system_memory" split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Cc: Richard Henderson <rth@twiddle.net> Signed-off-by: Dirk Mueller <dmueller@suse.com> Acked-by: Richard Henderson <rth@twiddle.net> Message-id: CAL5wTH64_ykF17cw2T1Axq8P3vCWm=6WbUJ3qJrLF-u+-MmzUw@mail.gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-10lm32: memory: Replace memory_region_init_ram with ↵Dirk Müller2-9/+6
memory_region_allocate_system_memory Commit 0b183fc871:"memory: move mem_path handling to memory_region_allocate_system_memory" split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Cc: Michael Walle <michael@walle.cc> Signed-off-by: Dirk Mueller <dmueller@suse.com> Acked-by: Michael Walle <michael@walle.cc> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-09xen: limit guest control of PCI command registerJan Beulich2-27/+13
Otherwise the guest can abuse that control to cause e.g. PCIe Unsupported Request responses (by disabling memory and/or I/O decoding and subsequently causing [CPU side] accesses to the respective address ranges), which (depending on system configuration) may be fatal to the host. This is CVE-2015-2756 / XSA-126. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Message-id: alpine.DEB.2.02.1503311510300.7690@kaball.uk.xensource.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-09configure: disable Archipelago by default and warn about libxseg GPLv3 licenseStefan Hajnoczi1-1/+7
libxseg has changed license to GPLv3. QEMU includes GPL "v2 only" code which is not compatible with GPLv3. This means the resulting binaries may not be redistributable! Disable Archipelago (libxseg) by default to prevent accidental license violations. Also warn if linking against libxseg is enabled to remind the user. Note that this commit does not constitute any advice about software licensing. If you have doubts you should consult a lawyer. Cc: Chrysostomos Nanakos <cnanakos@grnet.gr> Suggested-by: Kevin Wolf <kwolf@redhat.com> Reported-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Andreas Färber <afaerber@suse.de> Message-id: 1428587538-8765-1-git-send-email-stefanha@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-09Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into ↵Peter Maydell10-32/+220
staging # gpg: Signature made Thu Apr 9 10:55:11 2015 BST using RSA key ID 81AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" * remotes/stefanha/tags/block-pull-request: block/iscsi: handle zero events from iscsi_which_events aio: strengthen memory barriers for bottom half scheduling virtio-blk: correctly dirty guest memory qcow2: Fix header update with overridden backing file Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-09tcg/tcg-op.c: Fix ld/st of 64 bit values on 32-bit bigendian hostsPeter Maydell1-2/+2
Commit 951c6300f7 out-of-lined the 32-bit-host versions of tcg_gen_{ld,st}_i64, but in the process it inadvertently changed an #ifdef HOST_WORDS_BIGENDIAN to #ifdef TCG_TARGET_WORDS_BIGENDIAN. Since the latter doesn't get defined anywhere this meant we always took the "LE host" codepath, and stored the two halves of the value in the wrong order on BE hosts. This typically breaks any 64-bit guest on a 32-bit BE host completely, and will have possibly more subtle effects even for 32-bit guests. Switch the ifdef back to HOST_WORDS_BIGENDIAN. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <rth@twiddle.net> Tested-by: Andreas Färber <afaerber@suse.de> Message-id: 1428523029-13620-1-git-send-email-peter.maydell@linaro.org
2015-04-09block/iscsi: handle zero events from iscsi_which_eventsPeter Lieven1-6/+27
newer libiscsi versions may return zero events from iscsi_which_events. In this case iscsi_service will return immediately without any progress. To avoid busy waiting for iscsi_which_events to change we deregister all read and write handlers in this case and schedule a timer to periodically check iscsi_which_events for changed events. Next libiscsi version will introduce async reconnects and zero events are returned while libiscsi is waiting for a reconnect retry. Signed-off-by: Peter Lieven <pl@kamp.de> Message-id: 1428437295-29577-1-git-send-email-pl@kamp.de Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-09aio: strengthen memory barriers for bottom half schedulingPaolo Bonzini1-16/+12
There are two problems with memory barriers in async.c. The fix is to use atomic_xchg in order to achieve sequential consistency between the scheduling of a bottom half and the corresponding execution. First, if bh->scheduled is already 1 in qemu_bh_schedule, QEMU does not execute a memory barrier to order any writes needed by the callback before the read of bh->scheduled. If the other side sees req->state as THREAD_ACTIVE, the callback is not invoked and you get deadlock. Second, the memory barrier in aio_bh_poll is too weak. Without this patch, it is possible that bh->scheduled = 0 is not "published" until after the callback has returned. Another thread wants to schedule the bottom half, but it sees bh->scheduled = 1 and does nothing. This causes a lost wakeup. The memory barrier should have been changed to smp_mb() in commit 924fe12 (aio: fix qemu_bh_schedule() bh->ctx race condition, 2014-06-03) together with qemu_bh_schedule()'s. Guess who reviewed that patch? Both of these involve a store and a load, so they are reproducible on x86_64 as well. It is however much easier on aarch64, where the libguestfs test suite triggers the bug fairly easily. Even there the failure can go away or appear depending on compiler optimization level, tracing options, or even kernel debugging options. Paul Leveille however reported how to trigger the problem within 15 minutes on x86_64 as well. His (untested) recipe, reproduced here for reference, is the following: 1) Qcow2 (or 3) is critical – raw files alone seem to avoid the problem. 2) Use “cache=directsync” rather than the default of “cache=none” to make it happen easier. 3) Use a server with a write-back RAID controller to allow for rapid IO rates. 4) Run a random-access load that (mostly) writes chunks to various files on the virtual block device. a. I use ‘diskload.exe c:25’, a Microsoft HCT load generator, on Windows VMs. b. Iometer can probably be configured to generate a similar load. 5) Run multiple VMs in parallel, against the same storage device, to shake the failure out sooner. 6) IvyBridge and Haswell processors for certain; not sure about others. A similar patch survived over 12 hours of testing, where an unpatched QEMU would fail within 15 minutes. This bug is, most likely, also the cause of failures in the libguestfs testsuite on AArch64. Thanks to Laszlo Ersek for initially reporting this bug, to Stefan Hajnoczi for suggesting closer examination of qemu_bh_schedule, and to Paul for providing test input and a prototype patch. Reported-by: Laszlo Ersek <lersek@redhat.com> Reported-by: Paul Leveille <Paul.Leveille@stratus.com> Reported-by: John Snow <jsnow@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 1428419779-26062-1-git-send-email-pbonzini@redhat.com Suggested-by: Paul Leveille <Paul.Leveille@stratus.com> Suggested-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-08arm: memory: Replace memory_region_init_ram with ↵Dirk Müller13-37/+30
memory_region_allocate_system_memory Commit 0b183fc871:"memory: move mem_path handling to memory_region_allocate_system_memory" split memory_region_init_ram and memory_region_init_ram_from_file. Also it moved mem-path handling a step up from memory_region_init_ram to memory_region_allocate_system_memory. Therefore for any board that uses memory_region_init_ram directly, -mem-path is not supported. Fix this by replacing memory_region_init_ram with memory_region_allocate_system_memory. Signed-off-by: Dirk Mueller <dmueller@suse.com> Message-id: CAL5wTH4UHYKpJF=dLJfFzxpufjY189chnCow47-ySuLf8GLbug@mail.gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-08virtio-blk: correctly dirty guest memoryPaolo Bonzini3-3/+14
After qemu_iovec_destroy, the QEMUIOVector's size is zeroed and the zero size ultimately is used to compute virtqueue_push's len argument. Therefore, reads from virtio-blk devices did not migrate their results correctly. (Writes were okay). Save the size in virtio_blk_handle_request, and use it when the request is completed. Based on a patch by Wen Congyang. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Li Zhijian <lizhijian@cn.fujitsu.com> Message-id: 1427997044-392-1-git-send-email-pbonzini@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-08qcow2: Fix header update with overridden backing fileKevin Wolf5-7/+167
In recent qemu versions, it is possible to override the backing file name and format that is stored in the image file with values given at runtime. In such cases, the temporary override could end up in the image header if the qcow2 header was updated, while obviously correct behaviour would be to leave the on-disk backing file path/format unchanged. Fix this and add a test case for it. Reported-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1428411796-2852-1-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-04-07Merge remote-tracking branch ↵Peter Maydell6-17/+5
'remotes/mjt/tags/pull-trivial-patches-2015-04-04' into staging trivial patches for 2015-04-04 # gpg: Signature made Sat Apr 4 08:07:49 2015 BST using RSA key ID A4C3D7DB # gpg: Good signature from "Michael Tokarev <mjt@tls.msk.ru>" # gpg: aka "Michael Tokarev <mjt@corpit.ru>" # gpg: aka "Michael Tokarev <mjt@debian.org>" * remotes/mjt/tags/pull-trivial-patches-2015-04-04: vhost: fix typo in vq_index description gitignore: Ignore more .pod files. target-tricore: Fix check which was always false target-i386: remove superfluous TARGET_HAS_SMC macro pcspk: Fix I/O port name Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-04vhost: fix typo in vq_index descriptionGreg Kurz1-1/+1
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2015-04-04gitignore: Ignore more .pod files.Eric Blake1-8/+2
kvm_stat.{1,pod} started showing up as untracked files in my directory, and I nearly accidentally merged them into a commit with my usual habit of 'git add .'. Rather than spelling out each such file, just ignore the entire pattern. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2015-04-04target-tricore: Fix check which was always falseStefan Weil1-1/+1
With a mask value of 0x00400000, the result will never be 1. This fixes a Coverity warning. Signed-off-by: Stefan Weil <sw@weilnetz.de> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2015-04-04target-i386: remove superfluous TARGET_HAS_SMC macroEmilio G. Cota2-6/+0
Signed-off-by: Emilio G. Cota <cota@braap.org> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2015-04-04pcspk: Fix I/O port nameJan Kiszka1-1/+1
Probably a copy&paste bug. Fixing it helps identifying the device model behind port 0x61. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2015-04-02Update version for v2.3.0-rc2 releasev2.3.0-rc2Peter Maydell1-1/+1
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-02glib-compat: fix problems with not-quite glib 2.22Cornelia Huck1-1/+3
Commit 89b516d8b9444ece8ccabb322a9389587c7a7b83 ("glib: add compatibility interface for g_get_monotonic_time()") aimed at making qemu build with old glib versions. At least SLES11SP3, however, contains a backport of g_get_monotonic_time() while keeping the reported glib version at 2.22. Let's work around this by a strategically placed #define. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Message-id: 1427987865-433-2-git-send-email-cornelia.huck@de.ibm.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-02Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell8-13/+96
Another round of small fixes. I am not including the virtio-blk fix, because Wen only posted a prototype and the changes I made were pretty large. It definitely needs another pair of eyes (but it is a 2.3 regression and a blocker). # gpg: Signature made Thu Apr 2 14:59:56 2015 BST using RSA key ID 78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: Use $(MAKE) for recursive make kvm-all: Sync dirty-bitmap from kvm before kvm destroy the corresponding dirty_bitmap util/qemu-config: fix regression of qmp_query_command_line_options target-i386: clear bsp bit when designating bsp qga: fitering out -fstack-protector-strong target-i386: save 64-bit CR3 in 64-bit SMM state save area Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2015-04-02Use $(MAKE) for recursive makeEd Maste1-3/+3
On BSDs "make" is typically BSD make, while "gmake" is GNU make. Signed-off-by: Ed Maste <emaste@freebsd.org> Message-Id: <1427911118-21905-1-git-send-email-emaste@freebsd.org> [Fix $(INSTALLER) too as reported by Fam Zheng. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>