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 73a652a1b0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 afcf905cff)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 ab53c44718)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 9eeb6dd1b2)
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>
This reverts commit fc3959e466.
From upstream commit d01c07f:
This reverts commit fc3959e466.
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>
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 e907746266)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 3960c336ad)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 27a46dcf50)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 278412d0e7)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 ecbda7a225)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 13c4941cdd)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 5e82a31eb9)
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 d064d9f381)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 274c3b52e1)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 20474e9aa0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
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 588ef9d411)
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>
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>
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>
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>
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>
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 896848f0d3)
* "seccomp: update libseccomp version and remove arch restriction"
(commit 8e27fc2004)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 1428670681-23032-1-git-send-email-peter.maydell@linaro.org
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
Commit 89b516d8b9 ("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>
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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAABCAAGBQJVHUtcAAoJEL/70l94x66Dr1IIAIq+2i+79CoOW1VgoqdN9hBM
co7s8MzVwPzSPxMzicv94nAMBcPWfmoGzi8JJebxUmQDmZ7L33bOa64cbVgmQ5wU
gfJ+yea8TRkyDH/psv8jcvesdEgwRUnpOTCrEv4GD+haTHWZB4t6HW4KpolxbclJ
igs5MUxcH/cM//L+nyadr/ZuJvPy4sakquvnMqr5Zzr/xjwLwzbJIksoZthMdxW5
oZAY1g0T2f5sSpt0kl8lYid1njbTBX9z8ZkoftQSjRJFZ253vl+CxXFuJevke1hE
ayRhRKg5VfAyPY4txEK0+27E/Jo4X51y+6Et0N5yzrQsSZ1FeBtxzngm14gEQZA=
=CfCj
-----END PGP SIGNATURE-----
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>
Justin Ossevoort