Here we have an open-coded byte-based bitmap implementation.
Get rid of it since there's a ulong-based implementation to be
used by all code.
Signed-off-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Due to old Seabios bug, QEMU reenable LINT0 after reset. This bug is long gone
and therefore this hack is no longer needed. Since it violates the
specifications, it is removed.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Message-Id: <1428881529-29459-2-git-send-email-namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
I discovered a problem when trying to build QEMU statically with gcc.
libm is an element of LIBS while libpixman-1 is an element in
libs_softmmu. Libpixman references functions in libm, so the original
ordering makes linking fail.
This fix is to reorder $libs_softmmu and $LIBS to make -lm appear after
-lpixman-1. However I'm not quite sure if this is the right fix, hence
the RFC tag.
Normally QEMU is built with c++ compiler which happens to link in libm
(at least this is the case with g++), so building QEMU statically
normally just works and nobody notices this issue.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Message-Id: <1425912873-21215-1-git-send-email-wei.liu2@citrix.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This is better and prepares for the next patch. When we copy
libs_softmmu's value into LIBS with a := assignment, we cannot
anymore modify libs_softmmu in the Makefiles.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This adds "--enable-tcmalloc" and "--disable-tcmalloc" to allow linking
to libtcmalloc from gperftools.
tcmalloc is a malloc implementation that works well with threads and is
fast, so it is good for performance.
It is disabled by default, because the MALLOC_PERTURB_ flag we use in
tests doesn't work with tcmalloc. However we can enable tcmalloc
specific heap checker and profilers later.
An IOPS gain can be observed with virtio-blk-dataplane, other parts of
QEMU will directly benefit from it as well:
==========================================================
glibc malloc
----------------------------------------------------------
rw bs iodepth bw iops latency
read 4k 1 150 38511 24
----------------------------------------------------------
==========================================================
tcmalloc
----------------------------------------------------------
rw bs iodepth bw iops latency
read 4k 1 156 39969 23
----------------------------------------------------------
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <1427338992-27057-1-git-send-email-famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
address_space_translate_internal will clamp the *plen length argument
based on the size of the memory region being queried. The iommu walker
logic in addresss_space_translate was ignoring this by discarding the
post fn call value of *plen. Fix by just always using *plen as the
length argument throughout the fn, removing the len local variable.
This fixes a bootloader bug when a single elf section spans multiple
QEMU memory regions.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Message-Id: <1426570554-15940-1-git-send-email-peter.crosthwaite@xilinx.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
When an I/O port is more than 1 byte long, ioport.c is currently
creating "short" regions, for example 0x1ce-0x1ce for the 16-bit
Bochs index port. When I/O ports are memory mapped, and thus
accessed via a subpage_ops memory region, subpage_accepts gets
confused because it finds a hole at 0x1cf and rejects the access.
In order to fix this, modify registration of the region to cover
the whole size of the I/O port. Attempts to access an invalid
port will be blocked by find_portio returning NULL.
This only affects the VBE DISPI regions. For all other cases,
the MemoryRegionPortio entries for 2- or 4-byte accesses overlap
an entry for 1-byte accesses, thus the size of the memory region
is not affected.
Reported-by: Zoltan Balaton <balaton@eik.bme.hu>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Right now, ioport.c assumes that the entire range specified with
MemoryRegionPortio includes a region with size == 1. This however
is not true for the VBE DISPI ports, which are 16-bit only. The
next patch will make these regions' length equal to two, which can
cause the assertions to trigger. Replace them with simple conditionals.
Also, ioport.c will emulate a 16-bit ioport with two distinct reads
or writes, even if one of the two accesses is out of the bounds given
by the MemoryRegionPortio array. Do not do this anymore, instead
discard writes to the incorrect register and read it as all-ones.
This ensures that the mrp->read and mrp->write callbacks get an
in-range ioport number.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
ioport.c has not been using an alias since commit b40acf9 (ioport:
Switch dispatching to memory core layer, 2013-06-24). Remove the
obsolete comment.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
IDE PIO data must be written, for example, at 0x1f0. You cannot
do word or dword writes to 0x1f1..0x1f3 to access the data register.
Adjust the ide_portio_list accordingly.
Cc: John Snow <jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Remove 16-bit reads/writes, since ioport.c is able to synthesize them.
Remove the two MIDI registers (0x300 and 0x301) from gus_portio_list1,
and add the second MIDI register (0x301) to gus_portio_list2.
Tested with Second Reality.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
ioport.c is already able to split a 16-bit access into two 8-bit
accesses to consecutive ports. Tested with Epic Pinball.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
These were being incorrectly declared as MISC_SIZE (1 byte) rather than
4 bytes and 2 bytes respectively. As a result accesses clamped to the
real register size would unexpectedly fail.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
CC: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1427987370-15897-1-git-send-email-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
ram_addr_t is an internal interface, everyone should go through
MemoryRegion. Clean it up by making rom_add_blob return a
MemoryRegion* and using the new qemu_ram_resize infrastructure.
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If DMA's owning thread cancels the IO while the bounce buffer's owning thread
is notifying the "cpu client list", a use-after-free happens:
continue_after_map_failure dma_aio_cancel
------------------------------------------------------------------
aio_bh_new
qemu_bh_delete
qemu_bh_schedule (use after free)
Also, the old code doesn't run the bh in the right AioContext.
Fix both problems by passing a QEMUBH to cpu_register_map_client.
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1426496617-10702-6-git-send-email-famz@redhat.com>
[Remove unnecessary forward declaration. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The caller's workflow is like
if (!address_space_map()) {
...
cpu_register_map_client();
}
If bounce buffer became available after address_space_map() but before
cpu_register_map_client(), the caller could miss it and has to wait for the
next bounce buffer notify, which may never happen in the worse case.
Just notify the list in cpu_register_map_client().
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <1426496617-10702-5-git-send-email-famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
So that accesses from multiple threads are safe.
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <1426496617-10702-4-git-send-email-famz@redhat.com>
[Remove #if from cpu_exec_init_all. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The function is a nop for user mode, so just remove them.
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <1426496617-10702-3-git-send-email-famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
There could be a race condition when two processes call
address_space_map concurrently and both want to use the bounce buffer.
Add an in_use flag in BounceBuffer to sync it.
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <1426496617-10702-2-git-send-email-famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Since commit
b7b5233a "bsd-user/mmap.c: Don't try to override g_malloc/g_free"
the exception we make here for usermode has been unnecessary.
Get rid of it.
Signed-off-by: Emilio G. Cota <cota@braap.org>
Message-Id: <1428610053-26148-1-git-send-email-cota@braap.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.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>
