Max Reitz [Mon, 1 Jun 2015 16:09:18 +0000 (18:09 +0200)]
iotests: qcow2 COW with minimal L2 cache size
This adds a test case to test 103 for performing a COW operation in a
qcow2 image using an L2 cache with minimal size (which should be at
least two clusters so the COW can access both source and destination
simultaneously).
Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit a4291eafc597c0944057930acf3e51d899f79c2e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Max Reitz [Mon, 1 Jun 2015 16:09:17 +0000 (18:09 +0200)]
qcow2: Set MIN_L2_CACHE_SIZE to 2
The L2 cache must cover at least two L2 tables, because during COW two
L2 tables are accessed simultaneously.
Reported-by: Alexander Graf <agraf@suse.de> Cc: qemu-stable <qemu-stable@nongnu.org> Signed-off-by: Max Reitz <mreitz@redhat.com> Tested-by: Alexander Graf <agraf@suse.de> Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 57e216695948a79d9ced82fc217a37cce70fd986) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Gerd Hoffmann [Tue, 26 May 2015 11:12:54 +0000 (13:12 +0200)]
kbd: add brazil kbd keys to x11 evdev map
This patch adds the two extra brazilian keys to the evdev keymap for
X11. This patch gets the two keys going with the vnc, gtk and sdl1
UIs.
The SDL2 library complains it doesn't know these keys, so the SDL2
library must be fixed before we can update ui/sdl2-keymap.h
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit 33aa30cafcce053b833f9fe09fbb88e2f54b93aa) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Gerd Hoffmann [Tue, 26 May 2015 08:39:10 +0000 (10:39 +0200)]
kbd: add brazil kbd keys to qemu
The brazilian computer keyboard layout has two extra keys (compared to
the usual 105-key intl ps/2 keyboard). This patch makes these two keys
known to qemu.
For historic reasons qemu has two ways to specify a key: A QKeyCode
(name-based) or a number (ps/2 scancode based). Therefore we have to
update multiple places to make new keys known to qemu:
(1) The QKeyCode definition in qapi-schema.json
(2) The QKeyCode <-> number mapping table in ui/input-keymap.c
This patch does just that. With this patch applied you can send those
two keys to the guest using the send-key monitor command.
Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit b771f470f3e2f99f585eaae68147f0c849fd1f8d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Justin Ossevoort [Mon, 11 May 2015 06:58:44 +0000 (08:58 +0200)]
qga/commands-posix: Fix bug in guest-fstrim
The FITRIM ioctl updates the fstrim_range structure it receives. This
way the caller can determine how many bytes were trimmed. The
guest-fstrim logic reuses the same fstrim_range for each filesystem,
effectively limiting each filesystem to trim at most as much as the
previous was able to trim.
If a previous filesystem would have trimmed 0 bytes, than the next
filesystem would report an error 'Invalid argument' because a FITRIM
request with length 0 is not valid.
This change resets the fstrim_range structure for each filesystem.
Signed-off-by: Justin Ossevoort <justin@quarantainenet.nl> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit 73a652a1b08445e8d91e50cdbb2da50e571c61b3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Shannon Zhao [Mon, 25 May 2015 07:14:37 +0000 (15:14 +0800)]
hw/acpi/aml-build: Fix memory leak
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>
Fam Zheng [Wed, 13 May 2015 13:12:01 +0000 (13:12 +0000)]
qemu-iotests: Test unaligned sub-block zero write
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>
Fam Zheng [Wed, 13 May 2015 13:12:00 +0000 (13:12 +0000)]
block: Fix NULL deference for unaligned write if qiov is NULL
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>
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>
Petr Matousek [Wed, 6 May 2015 07:48:59 +0000 (09:48 +0200)]
fdc: force the fifo access to be in bounds of the allocated buffer
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>
Peter Maydell [Fri, 29 May 2015 10:29:00 +0000 (11:29 +0100)]
target-arm: Avoid buffer overrun on UNPREDICTABLE ldrd/strd
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>
Jason Wang [Thu, 23 Apr 2015 06:21:34 +0000 (14:21 +0800)]
virtio-net: fix the upper bound when trying to delete queues
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>
Michal Kazior [Wed, 29 Apr 2015 11:34:59 +0000 (11:34 +0000)]
usb: fix usb-net segfault
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
Kevin Wolf [Wed, 6 May 2015 11:21:51 +0000 (13:21 +0200)]
qcow2: Flush pending discards before allocating cluster
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>
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>
Fam Zheng [Wed, 6 May 2015 12:23:46 +0000 (20:23 +0800)]
vmdk: Fix next_cluster_sector for compressed write
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>
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>
Ján Tomko [Mon, 27 Apr 2015 15:03:14 +0000 (17:03 +0200)]
Strip brackets from vnc host
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>
Peter Lieven [Thu, 16 Apr 2015 14:08:25 +0000 (16:08 +0200)]
block/iscsi: do not forget to logout from target
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>
Stefan Hajnoczi [Mon, 23 Mar 2015 15:29:23 +0000 (15:29 +0000)]
bt-sdp: fix broken uuids power-of-2 calculation
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>
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>
Alberto Garcia [Fri, 17 Apr 2015 12:44:48 +0000 (15:44 +0300)]
hmp: fix crash in 'info block -n -v'
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>
Paolo Bonzini [Thu, 16 Apr 2015 20:11:23 +0000 (21:11 +0100)]
mips: fix broken fulong2e machine
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>
Mark Cave-Ayland [Fri, 17 Apr 2015 07:16:49 +0000 (08:16 +0100)]
target-ppc: don't invalidate msr MSR_HVB bit in cpu_post_load
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>
Peter Maydell [Fri, 10 Apr 2015 12:58:01 +0000 (13:58 +0100)]
Revert seccomp tests that allow it to be used on non-x86 architectures
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.
Thomas Huth [Thu, 9 Apr 2015 13:32:45 +0000 (15:32 +0200)]
pci: Fix crash with illegal "-net nic, model=xxx" option
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>
Andreas Färber [Fri, 10 Apr 2015 14:37:56 +0000 (16:37 +0200)]
stm32f205: Fix SoC type name
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>
cris: memory: Replace memory_region_init_ram with 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>
alpha: memory: Replace memory_region_init_ram with 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>
lm32: memory: Replace memory_region_init_ram with 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>
Jan Beulich [Tue, 31 Mar 2015 14:18:03 +0000 (15:18 +0100)]
xen: limit guest control of PCI command register
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>
Stefan Hajnoczi [Thu, 9 Apr 2015 13:52:18 +0000 (14:52 +0100)]
configure: disable Archipelago by default and warn about libxseg GPLv3 license
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>
Peter Maydell [Wed, 8 Apr 2015 19:57:09 +0000 (20:57 +0100)]
tcg/tcg-op.c: Fix ld/st of 64 bit values on 32-bit bigendian hosts
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
Peter Lieven [Tue, 7 Apr 2015 20:08:15 +0000 (22:08 +0200)]
block/iscsi: handle zero events from iscsi_which_events
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>
Paolo Bonzini [Tue, 7 Apr 2015 15:16:19 +0000 (17:16 +0200)]
aio: strengthen memory barriers for bottom half scheduling
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>
arm: memory: Replace memory_region_init_ram with 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>
Paolo Bonzini [Thu, 2 Apr 2015 17:50:44 +0000 (19:50 +0200)]
virtio-blk: correctly dirty guest memory
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>
Kevin Wolf [Tue, 7 Apr 2015 13:03:16 +0000 (15:03 +0200)]
qcow2: Fix header update with overridden backing file
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>
Peter Maydell [Tue, 7 Apr 2015 13:33:46 +0000 (14:33 +0100)]
Merge remote-tracking branch '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>
Eric Blake [Fri, 20 Mar 2015 16:30:44 +0000 (10:30 -0600)]
gitignore: Ignore more .pod files.
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>
glib-compat: fix problems with not-quite glib 2.22
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>
Peter Maydell [Thu, 2 Apr 2015 14:53:16 +0000 (15:53 +0100)]
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
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>
Ed Maste [Wed, 1 Apr 2015 17:58:38 +0000 (13:58 -0400)]
Use $(MAKE) for recursive make
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>
kvm-all: Sync dirty-bitmap from kvm before kvm destroy the corresponding dirty_bitmap
Sometimes, we destroy the dirty_bitmap in kvm_memory_slot before any sync action
occur, this bit in dirty_bitmap will be missed, and which will lead the corresponding
dirty pages to be missed in migration.
This usually happens when do migration during VM's Start-up or Reboot.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
[Use s->migration_log instead of exec.c's in_migration. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
util/qemu-config: fix regression of qmp_query_command_line_options
Commit 49d2e64 (machine: remove qemu_machine_opts global list)
made machine options specific to machine sub-type, leaving
the qemu_machine_opts desc array empty. Sadly this is the place
qmp_query_command_line_options is looking for supported options.
As a fix for for 2.3 the machine_qemu_opts (the generic ones)
are restored only for qemu-config scope.
We need to find a better fix for 2.4.
Reported-by: Tony Krowiak <akrowiak@linux.vnet.ibm.com> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
Message-Id: <1427906841-1576-1-git-send-email-marcel@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Nadav Amit [Wed, 1 Apr 2015 23:58:36 +0000 (02:58 +0300)]
target-i386: clear bsp bit when designating bsp
Since the BSP bit is writable on real hardware, during reset all the CPUs which
were not chosen to be the BSP should have their BSP bit cleared. This fix is
required for KVM to work correctly when it changes the BSP bit.
An additional fix is required for QEMU tcg to allow software to change the BSP
bit.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Message-Id: <1427932716-11800-1-git-send-email-namit@cs.technion.ac.il> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Joseph Hindin [Wed, 1 Apr 2015 16:38:57 +0000 (19:38 +0300)]
qga: fitering out -fstack-protector-strong
configure script may add -fstack-protector-strong option instead
of -fstack-protector-all, depending on availability ( see
commit 63678e17c ). Both options have to by filtered out for
qga-vss.dll, otherwise MinGW cross-compilation fails at linking
stage.
Signed-off-by: Joseph Hindin <jhindin@daynix.com>
Message-Id: <1427906337-20805-2-git-send-email-jhindin@daynix.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Peter Maydell [Thu, 2 Apr 2015 13:36:57 +0000 (14:36 +0100)]
Merge remote-tracking branch 'remotes/armbru/tags/pull-hw-2015-04-02' into staging
hw: Contain drive, serial, parallel, net misuse
# gpg: Signature made Thu Apr 2 14:32:00 2015 BST using RSA key ID EB918653
# gpg: Good signature from "Markus Armbruster <armbru@redhat.com>"
# gpg: aka "Markus Armbruster <armbru@pond.sub.org>"
* remotes/armbru/tags/pull-hw-2015-04-02:
sysbus: Make devices picking up backends unavailable with -device
sdhci: Make device "sdhci-pci" unavailable with -device
hw: Mark device misusing nd_table[] FIXME
hw: Mark devices picking up char backends actively FIXME
hw: Mark devices picking up block backends actively FIXME
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
sysbus: Make devices picking up backends unavailable with -device
Device models aren't supposed to go on fishing expeditions for
backends. They should expose suitable properties for the user to set.
For onboard devices, board code sets them.
A number of sysbus devices pick up block backends in their init() /
instance_init() methods with drive_get_next() instead: sl-nand,
milkymist-memcard, pl181, generic-sdhci.
Likewise, a number of sysbus devices pick up character backends in
their init() / realize() methods with qemu_char_get_next_serial():
cadence_uart, digic-uart, etraxfs,serial, lm32-juart, lm32-uart,
milkymist-uart, pl011, stm32f2xx-usart, xlnx.xps-uartlite.
All these mistakes are already marked FIXME. See the commit that
added these FIXMEs for a more detailed explanation of what's wrong.
Fortunately, only machines ppce500 and pseries-* support -device with
sysbus devices, and none of the devices above is supported with these
machines.
Set cannot_instantiate_with_device_add_yet to preserve our luck.
Cc: Andrzej Zaborowski <balrogg@gmail.com> Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Cc: Antony Pavlov <antonynpavlov@gmail.com> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Michael Walle <michael@walle.cc> Signed-off-by: Markus Armbruster <armbru@redhat.com>
sdhci: Make device "sdhci-pci" unavailable with -device
Device models aren't supposed to go on fishing expeditions for
backends. They should expose suitable properties for the user to set.
For onboard devices, board code sets them.
"sdhci-pci" picks up its block backend in its realize() method with
drive_get_next() instead. Already marked FIXME. See the commit that
added the FIXME for a more detailed explanation of what's wrong.
We can't fix this in time for the release, but since the device is new
in 2.3, we can set cannot_instantiate_with_device_add_yet to disable
it before this mistake becomes ABI, and we have to support command
lines like
NICs defined with -net nic are for board initialization to wire up.
Board code examines nd_table[] to find them, and creates devices with
their qdev NIC properties set accordingly.
Except "allwinner-a10" goes on a fishing expedition for NIC
configuration instead of exposing the usual NIC properties for board
code to set: it uses nd_table[0] in its instance_init() method.
Picking up the first -net nic option's configuration that way works
when the device is created by board code. But it's inappropriate for
-device and device_add. Not only is it inconsistent with how the
other block device models work (they get their configuration from
properties "mac", "vlan", "netdev"), it breaks when nd_table[0] has
been picked up by the board or a previous -device / device_add
already.
Example:
$ qemu-system-arm -S -M cubieboard -device allwinner-a10
qemu-system-arm: -device allwinner-a10: Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use
Aborted (core dumped)
hw: Mark devices picking up char backends actively FIXME
Character devices defined with -serial and -parallel are for board
initialization to wire up. Board code examines serial_hds[] and
parallel_hds[] to find them, and creates devices with their qdev
chardev properties set accordingly.
Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a chardev property for board code to set: they use
serial_hds[] (often via qemu_char_get_next_serial()) or parallel_hds[]
in their realize() or init() method to connect to a backend.
Picking up backends that way works when the devices are created by
board code. But it's inappropriate for -device or device_add. Not
only is it inconsistent with how the other characrer device models
work (they connect to a backend explicitly identified by a "chardev"
property), it breaks when the backend has been picked up by the board
or a previous -device / device_add already.
Example:
$ qemu-system-ppc64 -M bamboo -S -device i82378 -device pc87312 -device pc87312
qemu-system-ppc64: -device pc87312: Property 'isa-parallel.chardev' can't take value 'parallel0', it's in use
Mark them with suitable FIXME comments.
Cc: Li Guang <lig.fnst@cn.fujitsu.com> Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Cc: Antony Pavlov <antonynpavlov@gmail.com> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Michael Walle <michael@walle.cc> Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Cc: "Andreas Färber" <andreas.faerber@web.de> Signed-off-by: Markus Armbruster <armbru@redhat.com>
hw: Mark devices picking up block backends actively FIXME
Drives defined with if!=none are for board initialization to wire up.
Board code calls drive_get() or similar to find them, and creates
devices with their qdev drive properties set accordingly.
Except a few devices go on a fishing expedition for a suitable backend
instead of exposing a drive property for board code to set: they call
driver_get() or drive_get_next() in their realize() or init() method
to implicitly connect to the "next" backend with a certain interface
type.
Picking up backends that way works when the devices are created by
board code. But it's inappropriate for -device or device_add. Not
only is this inconsistent with how the other block device models work
(they connect to a backend explicitly identified by a "drive"
property), it breaks when the "next" backend has been picked up by the
board already.
Cc: Andrzej Zaborowski <balrogg@gmail.com> Cc: Peter Crosthwaite <peter.crosthwaite@xilinx.com> Cc: "Andreas Färber" <andreas.faerber@web.de> Cc: Michael Walle <michael@walle.cc> Signed-off-by: Markus Armbruster <armbru@redhat.com>
Peter Maydell [Thu, 2 Apr 2015 09:52:14 +0000 (10:52 +0100)]
hw/arm/vexpress: Don't double-free flash filename
Commits 6e05a12f8f7f and db25a1581 both attempt to fix the
same "failed to free memory containing flash filename" bug,
with the effect that when they were both applied we ended
up freeing the memory twice. Delete the spurious extra free.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1427968334-14527-1-git-send-email-peter.maydell@linaro.org
As 4de9a88(hw/arm/virt: Fix memory leak reported by Coverity)
and 6e05a12(arm: fix memory leak) both handle the memory leak
reported by Coverity, this cause qemu corruption due to
double free.
Signed-off-by: Shannon Zhao <zhaoshenglong@huawei.com> Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org> Reviewed-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1427944026-8968-1-git-send-email-zhaoshenglong@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Alex Bennée [Wed, 1 Apr 2015 16:57:30 +0000 (17:57 +0100)]
target-arm: kvm64 fix save/restore of SPSR regs
The current code was negatively indexing the cpu state array and not
synchronizing banked spsr register state with the current mode's spsr
state, causing occasional failures with migration.
Some munging is done to take care of the aarch64 mapping and also to
ensure the most current value of the spsr is updated to the banked
registers (relevant for KVM<->TCG migration).
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Alex Bennée [Wed, 1 Apr 2015 16:57:30 +0000 (17:57 +0100)]
target-arm: kvm64 sync FP register state
For migration to work we need to sync all of the register state. This is
especially noticeable when GCC starts using FP registers as spill
registers even with integer programs.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Alex Bennée [Wed, 1 Apr 2015 16:57:30 +0000 (17:57 +0100)]
hw/intc: arm_gic_kvm.c restore config first
As there is logic to deal with the difference between edge and level
triggered interrupts in the kernel we must ensure it knows the
configuration of the IRQs before we restore the pending state.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Acked-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Alex Bennée [Wed, 1 Apr 2015 16:57:30 +0000 (17:57 +0100)]
target-arm: kvm: save/restore mp state
This adds the saving and restore of the current Multi-Processing state
of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of
potential states for x86 we only use two for ARM. Either the process is
running or not. We then save this state into the cpu_powered TCG state
to avoid changing the serialisation format.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Wed, 1 Apr 2015 16:57:29 +0000 (17:57 +0100)]
target-arm: Store SPSR_EL1 state in banked_spsr[1] (SPSR_svc)
The AArch64 SPSR_EL1 register is architecturally mandated to
be mapped to the AArch32 SPSR_svc register. This means its
state should live in QEMU's env->banked_spsr[1] field.
Correct the various places in the code that incorrectly
put it in banked_spsr[0].
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Stefan Weil [Wed, 1 Apr 2015 16:57:29 +0000 (17:57 +0100)]
hw/arm/virt: Fix memory leak reported by Coverity
As the conditional statement had to be split anyway, we can also
add a better error report message.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1426877982-3603-1-git-send-email-sw@weilnetz.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Stefan Weil [Wed, 1 Apr 2015 16:57:29 +0000 (17:57 +0100)]
hw/arm/vexpress: Fix memory leak reported by Coverity
As the conditional statement had to be split anyway, we can also
add a better error report message.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1426877963-3556-1-git-send-email-sw@weilnetz.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Stefan Weil [Wed, 1 Apr 2015 16:57:29 +0000 (17:57 +0100)]
hw/arm/highbank: Fix resource leak and wrong image loading
Coverity reports a resource leak for sysboot_filename which is allocated
by qemu_find_file.
In addition, that name is used to get the size of the image, but a
different image name was used to load it.
In addition, instead of passing the maximum allowed image size the actual
image size was passed to load_image_targphys.
Fix all three issues.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1426326781-2488-1-git-send-email-sw@weilnetz.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
CVE-2015-1779: limit size of HTTP headers from websockets clients
The VNC server websockets decoder will read and buffer data from
websockets clients until it sees the end of the HTTP headers,
as indicated by \r\n\r\n. In theory this allows a malicious to
trick QEMU into consuming an arbitrary amount of RAM. In practice,
because QEMU runs g_strstr_len() across the buffered header data,
it will spend increasingly long burning CPU time searching for
the substring match and less & less time reading data. So while
this does cause arbitrary memory growth, the bigger problem is
that QEMU will be burning 100% of available CPU time.
A novnc websockets client typically sends headers of around
512 bytes in length. As such it is reasonable to place a 4096
byte limit on the amount of data buffered while searching for
the end of HTTP headers.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The logic for decoding websocket frames wants to fully
decode the frame header and payload, before allowing the
VNC server to see any of the payload data. There is no
size limit on websocket payloads, so this allows a
malicious network client to consume 2^64 bytes in memory
in QEMU. It can trigger this denial of service before
the VNC server even performs any authentication.
The fix is to decode the header, and then incrementally
decode the payload data as it is needed. With this fix
the websocket decoder will allow at most 4k of data to
be buffered before decoding and processing payload.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
[ kraxel: fix frequent spurious disconnects, suggested by Peter Maydell ]
Peter Maydell [Wed, 1 Apr 2015 10:31:31 +0000 (11:31 +0100)]
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
Fix for object_del of in-use memory, pvpanic
regression, PPC regression and bogus error message with
Oxygen theme.
# gpg: Signature made Wed Apr 1 09:08:20 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:
Revert "exec: Respect as_tranlsate_internal length clamp"
rcu: do not create thread in pthread_atfork callback
pc: acpi: fix pvpanic regression
hostmem: Prevent removing an in-use memory backend
qom: Add can_be_deleted callback to UserCreatableClass
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This reverts commit c3c1bb99d1c11978d9ce94d1bdcf0705378c1459.
It causes problems with boards that declare memory regions shorter
than the registers they contain.
Reported-by: Zoltan Balaton <balaton@eik.bme.hu> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 31 Mar 2015 11:01:05 +0000 (13:01 +0200)]
rcu: do not create thread in pthread_atfork callback
If QEMU forks after the CPU threads have been created, qemu_mutex_lock_iothread
will not be able to do qemu_cpu_kick_thread. There is no solution other than
assuming that forks after the CPU threads have been created will end up in an
exec. Forks before the CPU threads have been created (such as -daemonize)
have to call rcu_after_fork manually.
Notably, the oxygen theme for GTK+ forks and shows a "No such process" error
without this patch.
This patch can be reverted once the iothread loses the "kick the TCG thread"
magic.
User-mode emulation does not use the iothread, so it can also call
rcu_after_fork.
Reported by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Tested by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
introduced regression changing pvpanic device HID from
QEMU0001 to QEMU0002.
Fix AML generated code so that pvpanic device
would keep its original HID. i.e. QEMU0001
Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reported-by: Gal Hammer <ghammer@redhat.com>
Message-Id: <1427717907-25027-1-git-send-email-imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The patch prevents removing an in-use mem backend and error out.
Signed-off-by: Lin Ma <lma@suse.com>
Message-Id: <1427704589-7688-3-git-send-email-lma@suse.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Lin Ma [Mon, 30 Mar 2015 08:36:28 +0000 (16:36 +0800)]
qom: Add can_be_deleted callback to UserCreatableClass
If backends implement the can_be_deleted and it returns false,
Then the qmp_object_del won't delete the given backends.
Signed-off-by: Lin Ma <lma@suse.com>
Message-Id: <1427704589-7688-2-git-send-email-lma@suse.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Peter Maydell [Tue, 31 Mar 2015 11:12:22 +0000 (12:12 +0100)]
Merge remote-tracking branch 'remotes/afaerber/tags/qom-devices-for-peter' into staging
QOM infrastructure fixes and device conversions
* Fix for adding alias properties with [*]
# gpg: Signature made Tue Mar 31 11:59:00 2015 BST using RSA key ID 3E7E013F
# gpg: Good signature from "Andreas Färber <afaerber@suse.de>"
# gpg: aka "Andreas Färber <afaerber@suse.com>"
* remotes/afaerber/tags/qom-devices-for-peter:
qom: Fix object_property_add_alias() with [*]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Andreas Färber [Fri, 27 Mar 2015 16:34:10 +0000 (17:34 +0100)]
qom: Fix object_property_add_alias() with [*]
Commit 8074264 (qom: Add description field in ObjectProperty struct)
introduced property descriptions and copied them for alias properties.
Instead of using the caller-supplied property name, use the returned
property name for setting the description. This avoids an Error when
setting a property description for a property with literal "[*]" that
doesn't exist due to automatic property naming in object_property_add().
Reviewed-by: Gonglei <arei.gonglei@huawei.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-stable@nongnu.org (v2.2+) Signed-off-by: Andreas Färber <afaerber@suse.de>
Peter Maydell [Tue, 31 Mar 2015 09:55:33 +0000 (10:55 +0100)]
Merge remote-tracking branch 'remotes/afaerber/tags/qtest-for-2.3' into staging
QTest cleanups
* Change fw_cfg-test and i440fx-test GTester paths
* Extend libqtest API as necessary
# gpg: Signature made Mon Mar 30 18:29:39 2015 BST using RSA key ID 3E7E013F
# gpg: Good signature from "Andreas Färber <afaerber@suse.de>"
# gpg: aka "Andreas Färber <afaerber@suse.com>"
* remotes/afaerber/tags/qtest-for-2.3:
i440fx-test: Fix test paths to include architecture
qtest: Add qtest_add() wrapper macro
qtest: Add qtest_add_data_func() wrapper function
fw_cfg-test: Fix test path to include architecture
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Tue, 31 Mar 2015 08:56:48 +0000 (09:56 +0100)]
Merge remote-tracking branch 'remotes/bkoppelmann/tags/pull-tricore-20150330' into staging
TriCore bugfixes
# gpg: Signature made Mon Mar 30 12:40:50 2015 BST using RSA key ID 6B69CA14
# gpg: Good signature from "Bastian Koppelmann <kbastian@mail.uni-paderborn.de>"
* remotes/bkoppelmann/tags/pull-tricore-20150330:
target-tricore: fix CACHEA/I_POSTINC/PREINC using data register..
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Peter Maydell [Mon, 30 Mar 2015 21:55:51 +0000 (22:55 +0100)]
Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20150330' into staging
s390x fixes:
- virtqueue index issues in virtio-ccw
- cleanup and sign extension fix for the ipl device
# gpg: Signature made Mon Mar 30 08:52:54 2015 BST using RSA key ID C6F02FAF
# gpg: Good signature from "Cornelia Huck <huckc@linux.vnet.ibm.com>"
# gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>"
* remotes/cohuck/tags/s390x-20150330:
s390x/ipl: avoid sign extension
s390x: do not include ram_addr.h
virtio-ccw: range check in READ_VQ_CONF
virtio-ccw: fix range check for SET_VQ
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Cornelia Huck [Thu, 26 Mar 2015 09:41:45 +0000 (10:41 +0100)]
s390x/ipl: avoid sign extension
Make s390_update_iplstate() return uint32_t to avoid sign extensions
for cssids > 127. While this doesn't matter in practice yet (as
nobody supports MCSS-E and thus won't see the real cssid), play safe.
Reported-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jason J. Herne <jjherne@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Cornelia Huck [Fri, 20 Mar 2015 12:16:20 +0000 (13:16 +0100)]
virtio-ccw: range check in READ_VQ_CONF
Processing for READ_VQ_CONF needs to check whether the requested queue
value is actually in the supported range and post a channel program
check if not.
Cc: qemu-stable@nongnu.org Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
projects / thirdparty / qemu.git / log
