Eric Blake [Wed, 23 Nov 2016 17:36:54 +0000 (11:36 -0600)]
qmp-event: Avoid qobject_from_jsonf("%"PRId64)
The qobject_from_jsonf() function implements a pseudo-printf
language for creating a QObject; however, it is hard-coded to
only parse a subset of formats understood by -Wformat, and is
not a straight synonym to bare printf(). In particular, any
use of an int64_t integer works only if the system's
definition of PRId64 matches what the parser expects; which
works on glibc (%lld or %ld depending on 32- vs. 64-bit) and
mingw (%I64d), but not on Mac OS (%qd). Rather than enhance
the parser, it is just as easy to use 'long long', which we
know always works. There are few enough callers of
qobject_from_json[fv]() that it is easy to audit that this is
the only non-testsuite caller that was actually relying on
this particular conversion.
Reported by: G 3 <programmingkidx@gmail.com> Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1479922617-4400-2-git-send-email-eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
[Cast tv.tv_sec, tv.tv_usec to long long for type correctness] Signed-off-by: Markus Armbruster <armbru@redhat.com>
Michael Roth [Wed, 30 Nov 2016 23:05:34 +0000 (17:05 -0600)]
spapr: fix default DRC state for coldplugged LMBs
Currently we set the initial isolation/allocation state for DRCs
associated with coldplugged LMBs to ISOLATED/UNUSABLE,
respectively, under the assumption that the guest will move this
state to UNISOLATED/USABLE.
In fact, this is only the case for LMBs added via hotplug. For
coldplugged LMBs, the guest actually assumes the initial state to
be UNISOLATED/USABLE.
In practice, this only becomes an issue when we attempt to unplug
one of these LMBs, where the guest kernel will issue an
rtas-get-sensor-state call to check that the corresponding DRC is
in an USABLE state before it will release the LMB back to
QEMU. If the returned state is otherwise, the guest will assume no
further action is needed, which bypasses the QEMU-side cleanup that
occurs during the USABLE->UNUSABLE transition. This results in
LMBs and their corresponding pc-dimm devices to stick around
indefinitely.
This patch fixes the issue by manually setting DRCs associated with
cold-plugged LMBs to UNISOLATED/ALLOCATED, but leaving the hotplug
state untouched. As it turns out, this is analogous to the handling
for cold-plugged CPUs in spapr_core_plug().
Cc: qemu-ppc@nongnu.org Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Cc: Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Gonglei [Sat, 26 Nov 2016 03:07:55 +0000 (11:07 +0800)]
virtio-crypto: fix uninitialized variables
Though crypto_cfg.reserve is an unused field, let me
initialize the structure in order to make coverity happy.
*** CID 1365923: Uninitialized variables (UNINIT)
/hw/virtio/virtio-crypto.c: 851 in virtio_crypto_get_config()
845 stl_le_p(&crypto_cfg.mac_algo_h, c->conf.mac_algo_h);
846 stl_le_p(&crypto_cfg.aead_algo, c->conf.aead_algo);
847 stl_le_p(&crypto_cfg.max_cipher_key_len, c->conf.max_cipher_key_len);
848 stl_le_p(&crypto_cfg.max_auth_key_len, c->conf.max_auth_key_len);
849 stq_le_p(&crypto_cfg.max_size, c->conf.max_size);
850
>>> CID 1365923: Uninitialized variables (UNINIT)
>>> Using uninitialized value "crypto_cfg". Field "crypto_cfg.reserve"
is uninitialized when calling "memcpy".
[Note: The source code implementation of the function
has been overridden by a builtin model.]
851 memcpy(config, &crypto_cfg, c->config_size);
852 }
853
Rported-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Laszlo Ersek [Tue, 29 Nov 2016 19:55:33 +0000 (20:55 +0100)]
loader: fix undefined behavior in rom_order_compare()
According to ISO C99 / N1256 (referenced in HACKING):
> 6.5.8 Relational operators
>
> 4 For the purposes of these operators, a pointer to an object that is
> not an element of an array behaves the same as a pointer to the first
> element of an array of length one with the type of the object as its
> element type.
>
> 5 When two pointers are compared, the result depends on the relative
> locations in the address space of the objects pointed to. If two
> pointers to object or incomplete types both point to the same object,
> or both point one past the last element of the same array object, they
> compare equal. If the objects pointed to are members of the same
> aggregate object, pointers to structure members declared later compare
> greater than pointers to members declared earlier in the structure,
> and pointers to array elements with larger subscript values compare
> greater than pointers to elements of the same array with lower
> subscript values. All pointers to members of the same union object
> compare equal. If the expression /P/ points to an element of an array
> object and the expression /Q/ points to the last element of the same
> array object, the pointer expression /Q+1/ compares greater than /P/.
> In all other cases, the behavior is undefined.
Our AddressSpace objects are allocated generally individually, and kept in
the "address_spaces" linked list, so we mustn't compare their addresses
with relops.
Convert the pointers subjected to the relop in rom_order_compare() to
"uintptr_t":
> 7.18.1.4 Integer types capable of holding object pointers
>
> 1 [...]
>
> The following type designates an unsigned integer type with the
> property that any valid pointer to void can be converted to this type,
> then converted back to pointer to void, and the result will compare
> equal to the original pointer:
>
> /uintptr_t/
>
> These types are optional.
Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-devel@nongnu.org Fixes: 3e76099aacb4dae0d37ebf95305369e03d1491e6 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Laszlo Ersek [Tue, 29 Nov 2016 19:55:32 +0000 (20:55 +0100)]
loader: fix handling of custom address spaces when adding ROM blobs
* Commit 3e76099aacb4 ("loader: Allow a custom AddressSpace when loading
ROMs") introduced the "Rom.as" field:
(1) It modified the utility callers of rom_insert() to take "as" as a
new parameter from *their* callers, and set "rom->as" from that
parameter. The functions covered were rom_add_file() and
rom_add_elf_program().
(2) It also modified rom_insert() itself, to auto-assign
"&address_space_memory", in case the external caller passed -- and
the utility caller forwarded -- as=NULL.
Except, commit 3e76099aacb4 forgot to update the third utility caller of
rom_insert(), under point (1), namely rom_add_blob().
* Later, commit 5e774eb3bd264 ("loader: Add AddressSpace loading support
to uImages") added the load_uimage_as() function, and the
rom_add_blob_fixed_as() function-like macro, with the necessary changes
elsewhere to propagate the new "as" parameter to rom_add_blob():
At this point, the signature (and workings) of rom_add_blob() had been
broken already, and the rom_add_blob_fixed_as() macro passed its "_as"
parameter to rom_add_blob() as "callback_opaque". Given that the
"fw_callback" parameter itself was set to NULL (correctly), this did no
additional damage (the opaque arg would never be used), but ultimately
it broke the new functionality of load_uimage_as().
* The load_uimage_as() function would be put to use in one of the later
patches, commit e481a1f63c93 ("generic-loader: Add a generic loader").
* We can fix this only in a unified patch now. Append "AddressSpace *as"
to the signature of rom_add_blob(), and handle the new parameter. Pass
NULL from all current callers, except from rom_add_blob_fixed_as(),
where "_as" has to be bumped to the proper position.
* Note that rom_add_file() rejects the case when both "mr" and "as" are
passed in as non-NULL. The action that this is apparently supposed to
prevent is the
rom->mr = mr;
assignment (that's the only place where the "mr" parameter is used in
rom_add_file()). In rom_add_blob() though, we have no "mr" parameter,
and the actions done on the fw_cfg branch:
if (fw_file_name && fw_cfg) {
if (mc->rom_file_has_mr) {
data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
mr = rom->mr;
} else {
data = rom->data;
}
reflect those that are performed by rom_add_file() too (with mr==NULL):
if (rom->fw_file && fw_cfg) {
if ((!option_rom || mc->option_rom_has_mr) &&
mc->rom_file_has_mr) {
data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
} else {
data = rom->data;
}
Hence we need no additional restrictions in rom_add_blob().
* Stable is not affected as both problematic commits appeared first in
v2.8.0-rc0.
Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Alistair Francis <alistair.francis@xilinx.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Michael Walle <michael@walle.cc> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: qemu-arm@nongnu.org Cc: qemu-devel@nongnu.org Fixes: 3e76099aacb4dae0d37ebf95305369e03d1491e6 Fixes: 5e774eb3bd264c76484906f4bd0fb38e00b8090e Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Wei Wang [Thu, 24 Nov 2016 03:20:56 +0000 (22:20 -0500)]
spec/vhost-user: fix the VHOST_USER prefix
Signed-off-by: Wei Wang <wei.w.wang@intel.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Stefan Hajnoczi [Tue, 29 Nov 2016 17:06:38 +0000 (17:06 +0000)]
Merge remote-tracking branch 'kwolf/tags/for-upstream' into staging
Block layer patches for 2.8.0-rc2
# gpg: Signature made Tue 29 Nov 2016 03:16:10 PM GMT
# gpg: using RSA key 0x7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>"
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* kwolf/tags/for-upstream:
docs: Specify that cache-clean-interval is only supported in Linux
qcow2: Remove stale comment
qcow2: Allow 'cache-clean-interval' in Linux only
qcow2: Make qcow2_cache_table_release() work only in Linux
Message-id: 1480436227-2211-1-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Paolo Bonzini [Tue, 29 Nov 2016 15:37:20 +0000 (16:37 +0100)]
rules.mak: Also try -r to build modules
Building qemu fails in distributions where gcc enables PIE by default
(e.g. Debian unstable) with:
/usr/bin/ld: -r and -pie may not be used together
You have to use -r instead of -Wl,-r to avoid gcc passing -pie to the linker
when PIE is enabled and a relocatable object is passed. However, clang
does not know about -r, so try -Wl,-r first.
[This is a fix for commit c96f0ee6a67ca6277366e78ce5d84d5c20dd596f
("rules.mak: Use -r instead of -Wl, -r to fix building when PIE is
default") which mostly worked but broke the ./configure --enable-modules
build with clang.
--Stefan]
Reported-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20161129153720.29747-1-pbonzini@redhat.com Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* bonzini/tags/for-upstream:
rules.mak: Use -r instead of -Wl, -r to fix building when PIE is default
migration/pcspk: Turn migration of pcspk off for 2.7 and older
migration/pcspk: Add a property to state if pcspk is migrated
pci-assign: sync MSI/MSI-X cap and table with PCIDevice
megasas: clean up and fix request completion/cancellation
megasas: do not call pci_dma_unmap after having freed the frame once
Message-id: 1480372837-109736-1-git-send-email-pbonzini@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Max Reitz [Tue, 15 Nov 2016 22:47:32 +0000 (23:47 +0100)]
hbitmap: Fix shifts of constants by granularity
An hbitmap's granularity may be anything from 0 to 63, so when shifting
constants by its value, they should not be plain ints.
Even having changed the types, hbitmap_serialization_granularity() still
tries to shift 64 to the right by the granularity. This operation is
undefined if the granularity is greater than 57. Adding an assertion is
fine for now, because serializing is done only in tests so far, but this
means that only bitmaps with a granularity below 58 can be serialized
and we should thus add a hbitmap_is_serializable() function later.
One of the two places touched in this patch uses
QEMU_ALIGN_UP(x, 1 << y). We can use ROUND_UP() there, since the second
parameter is obviously a power of two.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20161115224732.1334-1-mreitz@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com>
The detection program needs to be linked with -ldl to build succesfully
with recent versions of LTTng-UST.
We also need to add -ldl to the libs required to build the LTTng-UST
backend (lttng_ust_libs).
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Message-id: 1480348337-24271-1-git-send-email-francis.deslauriers@efficios.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* pm215/tags/pull-target-arm-20161128:
arm: Create /chosen and /memory devicetree nodes if necessary
generic-loader: file: Only set a PC if a CPU is specified
Message-id: 1480341071-5367-1-git-send-email-peter.maydell@linaro.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Jan Beulich [Fri, 25 Nov 2016 10:06:58 +0000 (03:06 -0700)]
xen: ignore direction in bufioreq handling
There's no way to communicate back read data, so only writes can ever
be usefully specified. Ignore the field, paving the road for eventually
re-using the bit for something else in a few (many?) years time.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Jan Beulich [Fri, 25 Nov 2016 10:06:33 +0000 (03:06 -0700)]
xen: slightly simplify bufioreq handling
There's no point setting fields always receiving the same value on each
iteration, as handle_ioreq() doesn't alter them anyway. Set state and
count once ahead of the loop, drop the redundant clearing of
data_is_ptr, and avoid the meaningless (because count is 1) setting of
df altogether.
Also avoid doing an unsigned long calculation of size when the field to
be initialized is only 32 bits wide (and the shift value in the range
0...3).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Jan Beulich [Fri, 25 Nov 2016 10:05:57 +0000 (03:05 -0700)]
xen: fix quad word bufioreq handling
We should not consume the second slot if it didn't get written yet.
Normal writers - i.e. Xen - would not update write_pointer between the
two writes, but the page may get fiddled with by the guest itself, and
we're better off avoiding to enter an infinite loop in that case.
Reported-by: yanghongke <yanghongke@huawei.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
migration/pcspk: Turn migration of pcspk off for 2.7 and older
To keep backwards migration compatibility allow us to turn pcspk
migration off.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20161128133201.16104-3-dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
migration/pcspk: Add a property to state if pcspk is migrated
Allow us to turn migration of pcspk off for compatibility.
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20161128133201.16104-2-dgilbert@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Peter Xu [Fri, 25 Nov 2016 02:55:22 +0000 (10:55 +0800)]
pci-assign: sync MSI/MSI-X cap and table with PCIDevice
Since commit e1d4fb2d ("kvm-irqchip: x86: add msi route notify fn"),
kvm_irqchip_add_msi_route() starts to use pci_get_msi_message() to fetch
MSI info. This requires that we setup MSI related fields in PCIDevice.
For most devices, that won't be a problem, as long as we are using
general interfaces like msi_init()/msix_init().
However, for pci-assign devices, MSI/MSI-X is treated differently - PCI
assign devices are maintaining its own MSI table and cap information in
AssignedDevice struct. however that's not synced up with PCIDevice's
fields. That will leads to pci_get_msi_message() failed to find correct
MSI capability, even with an NULL msix_table.
A quick fix is to sync up the two places: both the capability bits and
table address for MSI/MSI-X.
Reported-by: Changlimin <changlimin@h3c.com> Tested-by: Changlimin <changlimin@h3c.com> Cc: qemu-stable@nongnu.org Fixes: e1d4fb2d ("kvm-irqchip: x86: add msi route notify fn") Signed-off-by: Peter Xu <peterx@redhat.com>
Message-Id: <1480042522-16551-1-git-send-email-peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Thu, 10 Nov 2016 15:27:51 +0000 (16:27 +0100)]
megasas: clean up and fix request completion/cancellation
megasas_command_cancel is a callback; it should report the abort in
the frame, not try another abort! Compare for instance with
mptsas_request_cancelled.
So extract the common bits for request completion in a new function
megasas_complete_command, call it from both the .complete and .cancel
callbacks, and remove duplicate pieces from the DCMD path.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20161110152751.4267-2-pbonzini@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Thu, 15 Sep 2016 22:36:58 +0000 (00:36 +0200)]
megasas: do not call pci_dma_unmap after having freed the frame once
Commit 8cc4678 ("megasas: remove useless check for cmd->frame", 2016-07-17) was
wrong because I trusted Coverity too much. It turns out that there _is_ a
path through which cmd->frame can become NULL. After megasas_handle_frame's
switch (md->frame->header.frame_cmd), megasas_init_firmware can be called.
From there, megasas_reset_frames will call megasas_unmap_frame which resets
cmd->frame = NULL.
However, there is another bug to fix in there, because megasas_unmap_frame
is called again after setting the command status. In this case QEMU should
not do anything, instead it calls pci_dma_unmap again. Harmless, but
better fix it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Guenter Roeck [Thu, 17 Nov 2016 01:30:21 +0000 (17:30 -0800)]
arm: Create /chosen and /memory devicetree nodes if necessary
While customary, the /chosen and /memory devicetree nodes do not have to
exist. Create if necessary. Also create the /memory/device_type property
if needed.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Message-id: 1479346221-18474-1-git-send-email-linux@roeck-us.net Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Alistair Francis [Sat, 12 Nov 2016 02:51:20 +0000 (18:51 -0800)]
generic-loader: file: Only set a PC if a CPU is specified
This patch fixes the generic-loader file loading to only set the program
counter if a CPU is specified. This follows what is written in the
documentation and was always part of the original intention.
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Message-id: 537bf4d08be7acf7a89b590cff69e19db7f0a6cd.1478908712.git.alistair.francis@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Alberto Garcia [Fri, 25 Nov 2016 11:27:44 +0000 (13:27 +0200)]
qcow2: Allow 'cache-clean-interval' in Linux only
The cache-clean-interval option of qcow2 only works on Linux. However
we allow setting it in other systems regardless of whether it works or
not.
In those systems this option is not simply a no-op: it actually
invalidates perfectly valid cache tables for no good reason without
freeing their memory.
This patch forbids using that option in non-Linux systems.
Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Alberto Garcia [Fri, 25 Nov 2016 11:27:43 +0000 (13:27 +0200)]
qcow2: Make qcow2_cache_table_release() work only in Linux
We are using QEMU_MADV_DONTNEED to discard the memory of individual L2
cache tables. The problem with this is that those semantics are
specific to the Linux madvise() system call. Other implementations of
madvise() (including the very Linux implementation of posix_madvise())
don't do that, so we cannot use them for the same purpose.
This patch makes the code Linux-specific and uses madvise() directly
since there's no point in going through qemu_madvise() for this.
Signed-off-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Stefan Hajnoczi [Thu, 24 Nov 2016 10:16:23 +0000 (10:16 +0000)]
Merge remote-tracking branch 'gkurz/tags/for-upstream' into staging
This pull request fixes some leaks (memory, fd) in the handle and proxy
backends.
# gpg: Signature made Wed 23 Nov 2016 12:53:41 PM GMT
# gpg: using DSA key 0x02FC3AEB0101DBC2
# gpg: Good signature from "Greg Kurz <groug@kaod.org>"
# gpg: aka "Greg Kurz <groug@free.fr>"
# gpg: aka "Greg Kurz <gkurz@fr.ibm.com>"
# gpg: aka "Greg Kurz <gkurz@linux.vnet.ibm.com>"
# gpg: aka "Gregory Kurz (Groug) <groug@free.fr>"
# gpg: aka "Gregory Kurz (Cimai Technology) <gkurz@cimai.com>"
# gpg: aka "Gregory Kurz (Meiosys Technology) <gkurz@meiosys.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 2BD4 3B44 535E C0A7 9894 DBA2 02FC 3AEB 0101 DBC2
* gkurz/tags/for-upstream:
9pfs: add cleanup operation for proxy backend driver
9pfs: add cleanup operation for handle backend driver
9pfs: add cleanup operation in FileOperations
9pfs: adjust the order of resource cleanup in device unrealize
Message-id: 1479920298-24983-1-git-send-email-groug@kaod.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Olaf Hering [Wed, 23 Nov 2016 10:39:12 +0000 (10:39 +0000)]
xen_disk: split discard input to match internal representation
The guest sends discard requests as u64 sector/count pairs, but the
block layer operates internally with s64/s32 pairs. The conversion
leads to IO errors in the guest, the discard request is not processed.
Li Qiang [Wed, 23 Nov 2016 12:53:34 +0000 (13:53 +0100)]
9pfs: add cleanup operation for proxy backend driver
In the init operation of proxy backend dirver, it allocates a
V9fsProxy struct and some other resources. We should free these
resources when the 9pfs device is unrealized. This is what this
patch does.
Signed-off-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
Li Qiang [Wed, 23 Nov 2016 12:53:34 +0000 (13:53 +0100)]
9pfs: add cleanup operation for handle backend driver
In the init operation of handle backend dirver, it allocates a
handle_data struct and opens a mount file. We should free these
resources when the 9pfs device is unrealized. This is what this
patch does.
Signed-off-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
Li Qiang [Wed, 23 Nov 2016 12:53:34 +0000 (13:53 +0100)]
9pfs: add cleanup operation in FileOperations
Currently, the backend of VirtFS doesn't have a cleanup
function. This will lead resource leak issues if the backed
driver allocates resources. This patch addresses this issue.
Signed-off-by: Li Qiang <liq3ea@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org>
Stefan Hajnoczi [Wed, 23 Nov 2016 11:46:15 +0000 (11:46 +0000)]
Merge remote-tracking branch 'dgibson/tags/ppc-for-2.8-20161123' into staging
ppc patch queue 2016-11-23
Here's the first set of 2.8 hard freeze bugfixes for ppc.
The biggest thing here is a batch of fixes for migration breakages in
both 2.7 and current 2.8. Alas, there is at least one more migration
problem, which prevents memory unplug after a migration. I hoped to
include a fix for that here, but it turned out to have some problems
bigger than those it was solving. So, I expect at least one more hard
freeze pull request.
* dgibson/tags/ppc-for-2.8-20161123:
spapr: Fix 2.7<->2.8 migration of PCI host bridge
Revert "spapr: Fix migration of PCI host bridges from qemu-2.7"
target-ppc: Allow eventual removal of old migration mistakes
migration: Add VMSTATE_UINTTL_TEST()
target-ppc: Fix CPU migration from qemu-2.6 <-> later versions
ppc: Make uninorth interrupt swizzling identical to Grackle
target-ppc: fix index array of national digits
hw/char/spapr_vty: Return amount of free buffer entries in vty_can_receive()
ppc: BOOK3E: nothing should be done when MSR:PR is set
spapr: migration support for CAS-negotiated option vectors
tests/postcopy: Use KVM on ppc64 only if it is KVM-HV
Message-id: 1479869383-16162-1-git-send-email-david@gibson.dropbear.id.au Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
* bonzini/tags/for-upstream:
scsi/esp: do not raise an interrupt when reading the FIFO register
nbd: Allow unmap and fua during write zeroes
cpu_ldst.h: use correct guest address parameter
Message-id: 1479853676-35995-1-git-send-email-pbonzini@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
David Gibson [Tue, 22 Nov 2016 23:26:38 +0000 (10:26 +1100)]
spapr: Fix 2.7<->2.8 migration of PCI host bridge
daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration
from qemu-2.7 to the current version. It split the device's MMIO
window into two pieces for 32-bit and 64-bit MMIO.
The patch included backwards compatibility code to convert the old
property into the new format. However, the property value was also
transferred in the migration stream and compared with a (probably
unwise) VMSTATE_EQUAL. So, the "raw" value from 2.7 is compared to
the new style converted value from (pre-)2.8 giving a mismatch and
migration failure.
Along with the actual field that caused the breakage, there are
several other ill-advised VMSTATE_EQUAL()s. To fix forwards
migration, we read the values in the stream into scratch variables and
ignore them, instead of comparing for equality. To fix backwards
migration, we populate those scratch variables in pre_save() with
adjusted values to match the old behaviour.
To permit the eventual possibility of removing this cruft from the
stream, we only include these compatibility fields if a new
'pre-2.8-migration' property is set. We clear it on the pseries-2.8
machine type, which obviously can't be migrated backwards, but set it
on earlier machine type versions.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
The commit above corrected a migration breakage between qemu-2.7 and
qemu-2.8. However it did so by advancing the migration version for
the PCI host bridge, which obviously breaks migration backwards to
earlier qemu versions.
Although it's not totally essential, we'd like to maintain the
possibility for backwards migration, so revert the change in
preparation for a better fix.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
David Gibson [Mon, 21 Nov 2016 05:29:30 +0000 (16:29 +1100)]
target-ppc: Allow eventual removal of old migration mistakes
Until very recently, the vmstate for ppc cpus included some poorly
thought out VMSTATE_EQUAL() components, that can easily break
migration compatibility, and did so between qemu-2.6 and later
versions. A hack was recently added which fixes this migration
breakage, but it leaves the unhelpful cruft of these fields in the
migration stream.
This patch adds a new cpu property allowing these fields to be removed
from the stream entirely. For the pseries-2.8 machine type - which
comes after the fix - and for all non-pseries machine types - which
aren't mature enough to care about cross-version migration - we remove
the fields from the stream.
For pseries-2.7 and earlier, The migration hack remains in place,
allowing backwards and forwards migration with the older machine
types.
This restricts the migration compatibility cruft to older machine
types, and at least opens the possibility of eventually deprecating
and removing it entirely.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
David Gibson [Sun, 20 Nov 2016 23:50:02 +0000 (10:50 +1100)]
migration: Add VMSTATE_UINTTL_TEST()
include/migration/cpu.h defines VMSTATE_UINTTL() and several variants
for migrating target_ulong fields. It's defined in terms of
VMSTATE_UINT32() or VMSTATE_UINT64() as appropriate.
It doesn't, however, include a VMSTATE_UINTTL_TEST() variant, which
I'm going to need shortly. So, add it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
David Gibson [Mon, 21 Nov 2016 05:28:12 +0000 (16:28 +1100)]
target-ppc: Fix CPU migration from qemu-2.6 <-> later versions
When migration for target-ppc was converted to vmstate, several
VMSTATE_EQUAL() checks were foolishly included of things that really
should be internal state. Specifically we verified equality of the
insns_flags and insns_flags2 fields, which are used within TCG to
determine which groups of instructions are available on this cpu
model. Between qemu-2.6 and qemu-2.7 we made some changes to these
classes which broke migration.
This path fixes migration both forwards and backwards. On migration
from 2.6 to later versions we import the fields into teporary
variables, which we then ignore. In migration backwards, we populate
the temporary fields from the runtime fields, but mask out the bits
which were added after qemu-2.6, allowing the VMSTATE_EQUAL in
qemu-2.6 to accept the stream.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org>
ppc: Make uninorth interrupt swizzling identical to Grackle
It's currently broken as it uses an incorrect shift, it tries
to use the slot number but uses the top bits of the bus number
instead.
Note: Neither implementation matches what OpenBIOS ends up putting
in the device-tree either, which will have to be fixed separately.
This is not quite correct for modelling a real Mac since Apple
tend to tie all 4 interrupt lines of a slot together and have
separate interrupts for every slot and every motherboard devices
going straight to the PIC but we'll sort that out later.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Fixes the big endian array access of national digits, from commits b815587 and e2106d7.
Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Thomas Huth [Fri, 18 Nov 2016 09:09:37 +0000 (10:09 +0100)]
hw/char/spapr_vty: Return amount of free buffer entries in vty_can_receive()
The can_receive() callbacks of the character devices should return
the amount of characters that can be accepted at once, not just a
boolean value (which rather means only one character at a time).
Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Vladimir Svoboda [Thu, 17 Nov 2016 13:49:48 +0000 (14:49 +0100)]
ppc: BOOK3E: nothing should be done when MSR:PR is set
The server architecture (BOOK3S) specifies that any instruction that
sets MSR:PR will also set MSR:EE, IR and DR.
However there is no such behavior specification for the embedded
architecture (BOOK3E).
Signed-off-by: Vladimir Svoboda <ze.vlad@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Thomas Huth <thuth@redhat.com>
Michael Roth [Fri, 18 Nov 2016 01:40:27 +0000 (19:40 -0600)]
spapr: migration support for CAS-negotiated option vectors
With the additional of the OV5_HP_EVT option vector, we now have
certain functionality (namely, memory unplug) that checks at run-time
for whether or not the guest negotiated the option via CAS. Because
we don't currently migrate these negotiated values, we are unable
to unplug memory from a guest after it's been migrated until after
the guest is rebooted and CAS-negotiation is repeated.
This patch fixes this by adding CAS-negotiated options to the
migration stream. We do this using a subsection, since the
negotiated value of OV5_HP_EVT is the only option currently needed
to maintain proper functionality for a running guest.
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Thomas Huth [Wed, 16 Nov 2016 08:39:31 +0000 (09:39 +0100)]
tests/postcopy: Use KVM on ppc64 only if it is KVM-HV
The ppc64 postcopy test does not work with KVM-PR, and it is also
causing annoying warning messages when run on a x86 host. So let's
use KVM here only if we know that we're running with KVM-HV (which
automatically also means that we're running on a ppc64 host), and
fall back to TCG otherwise.
Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Eric Blake [Thu, 17 Nov 2016 20:13:54 +0000 (14:13 -0600)]
nbd: Allow unmap and fua during write zeroes
Commit fa778fff wired up support to send the NBD_CMD_WRITE_ZEROES,
but forgot to inform the block layer that FUA unmapping of zeroes is
supported. Without BDRV_REQ_MAY_UNMAP listed as a supported flag,
the block layer will always insist on the NBD layer passing
NBD_CMD_FLAG_NO_HOLE, resulting in the server always allocating
things even when it was desired to let the server punch holes.
Similarly, failing to set BDRV_REQ_FUA means that the client may
send unnecessary NBD_CMD_FLUSH when it could have instead used the
NBD_CMD_FLAG_FUA bit.
CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1479413642-22463-2-git-send-email-eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Bobby Bingham [Sun, 13 Nov 2016 05:05:23 +0000 (23:05 -0600)]
cpu_ldst.h: use correct guest address parameter
In the user emulation code path, tlb_vaddr_to_host erronesously passed
vaddr as the guest address to be translated, instead of addr, the parameter
which actually contained the guest address.
This resulted in incorrect addresses being used when emulating block copy
(mvc/mvpg) and block clear (xc) instructions for the s390x target.
Signed-off-by: Bobby Bingham <koorogi@koorogi.info>
Message-Id: <20161113050523.23909-1-koorogi@koorogi.info> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Stefan Hajnoczi [Tue, 22 Nov 2016 19:30:39 +0000 (19:30 +0000)]
Merge remote-tracking branch 'sstabellini/tags/xen-20161122-tag' into staging
Xen 2016/11/22
# gpg: Signature made Tue 22 Nov 2016 06:41:23 PM GMT
# gpg: using RSA key 0x894F8F4870E1AE90
# gpg: Good signature from "Stefano Stabellini <sstabellini@kernel.org>"
# gpg: aka "Stefano Stabellini <stefano.stabellini@eu.citrix.com>"
# Primary key fingerprint: D04E 33AB A51F 67BA 07D3 0AEA 894F 8F48 70E1 AE90
* sstabellini/tags/xen-20161122-tag:
xen: attach pvusb usb bus to backend qdev
xen: create qdev for each backend device
qdev: add function qdev_set_id()
xen: add an own bus for xen backend devices
xen: fix ioreq handling
Message-id: alpine.DEB.2.10.1611221037010.21858@sstabellini-ThinkPad-X260 Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Stefan Hajnoczi [Tue, 22 Nov 2016 19:30:03 +0000 (19:30 +0000)]
Merge remote-tracking branch 'kwolf/tags/for-upstream' into staging
Block layer patches for 2.8.0-rc1
# gpg: Signature made Tue 22 Nov 2016 03:55:38 PM GMT
# gpg: using RSA key 0x7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>"
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6
* kwolf/tags/for-upstream:
block: Pass unaligned discard requests to drivers
block: Return -ENOTSUP rather than assert on unaligned discards
block: Let write zeroes fallback work even with small max_transfer
qcow2: Inform block layer about discard boundaries
Message-id: 1479830693-26676-1-git-send-email-kwolf@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Juergen Gross [Tue, 22 Nov 2016 06:10:59 +0000 (07:10 +0100)]
xen: attach pvusb usb bus to backend qdev
Attach the usb bus of a new pvusb controller to the qdev associated
with the Xen backend. Any device connected to that controller can now
specify the bus and port directly via its properties.
Juergen Gross [Tue, 22 Nov 2016 06:10:58 +0000 (07:10 +0100)]
xen: create qdev for each backend device
Create a qdev plugged to the xen-sysbus for each new backend device.
This device can be used as a parent for all needed devices of that
backend. The id of the new device will be "xen-<type>-<dev>" with
<type> being the xen backend type (e.g. "qdisk") and <dev> the xen
backend number of the type under which it is to be found in xenstore.
Juergen Gross [Tue, 22 Nov 2016 06:10:57 +0000 (07:10 +0100)]
qdev: add function qdev_set_id()
In order to have an easy way to add a new qdev with a specific id
carve out the needed functionality from qdev_device_add() into a new
function qdev_set_id().
Eric Blake [Thu, 17 Nov 2016 20:13:58 +0000 (14:13 -0600)]
block: Pass unaligned discard requests to drivers
Discard is advisory, so rounding the requests to alignment
boundaries is never semantically wrong from the data that
the guest sees. But at least the Dell Equallogic iSCSI SANs
has an interesting property that its advertised discard
alignment is 15M, yet documents that discarding a sequence
of 1M slices will eventually result in the 15M page being
marked as discarded, and it is possible to observe which
pages have been discarded.
Between commits 9f1963b and b8d0a980, we converted the block
layer to a byte-based interface that ultimately ignores any
unaligned head or tail based on the driver's advertised
discard granularity, which means that qemu 2.7 refuses to
pass any discard request smaller than 15M down to the Dell
Equallogic hardware. This is a slight regression in behavior
compared to earlier qemu, where a guest executing discards
in power-of-2 chunks used to be able to get every page
discarded, but is now left with various pages still allocated
because the guest requests did not align with the hardware's
15M pages.
Since the SCSI specification says nothing about a minimum
discard granularity, and only documents the preferred
alignment, it is best if the block layer gives the driver
every bit of information about discard requests, rather than
rounding it to alignment boundaries early.
Rework the block layer discard algorithm to mirror the write
zero algorithm: always peel off any unaligned head or tail
and manage that in isolation, then do the bulk of the request
on an aligned boundary. The fallback when the driver returns
-ENOTSUP for an unaligned request is to silently ignore that
portion of the discard request; but for devices that can pass
the partial request all the way down to hardware, this can
result in the hardware coalescing requests and discarding
aligned pages after all.
Reported by: Peter Lieven <pl@kamp.de> CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Eric Blake [Thu, 17 Nov 2016 20:13:57 +0000 (14:13 -0600)]
block: Return -ENOTSUP rather than assert on unaligned discards
Right now, the block layer rounds discard requests, so that
individual drivers are able to assert that discard requests
will never be unaligned. But there are some ISCSI devices
that track and coalesce multiple unaligned requests, turning it
into an actual discard if the requests eventually cover an
entire page, which implies that it is better to always pass
discard requests as low down the stack as possible.
In isolation, this patch has no semantic effect, since the
block layer currently never passes an unaligned request through.
But the block layer already has code that silently ignores
drivers that return -ENOTSUP for a discard request that cannot
be honored (as well as drivers that return 0 even when nothing
was done). But the next patch will update the block layer to
fragment discard requests, so that clients are guaranteed that
they are either dealing with an unaligned head or tail, or an
aligned core, making it similar to the block layer semantics of
write zero fragmentation.
CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Eric Blake [Thu, 17 Nov 2016 20:13:56 +0000 (14:13 -0600)]
block: Let write zeroes fallback work even with small max_transfer
Commit 443668ca rewrote the write_zeroes logic to guarantee that
an unaligned request never crosses a cluster boundary. But
in the rewrite, the new code assumed that at most one iteration
would be needed to get to an alignment boundary.
However, it is easy to trigger an assertion failure: the Linux
kernel limits loopback devices to advertise a max_transfer of
only 64k. Any operation that requires falling back to writes
rather than more efficient zeroing must obey max_transfer during
that fallback, which means an unaligned head may require multiple
iterations of the write fallbacks before reaching the aligned
boundaries, when layering a format with clusters larger than 64k
atop the protocol of file access to a loopback device.
In fairness to Denis (as the original listed author of the culprit
commit), the faulty logic for at most one iteration is probably all
my fault in reworking his idea. But the solution is to restore what
was in place prior to that commit: when dealing with an unaligned
head or tail, iterate as many times as necessary while fragmenting
the operation at max_transfer boundaries.
Reported-by: Ed Swierk <eswierk@skyportsystems.com> CC: qemu-stable@nongnu.org CC: Denis V. Lunev <den@openvz.org> Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Eric Blake [Thu, 17 Nov 2016 20:13:55 +0000 (14:13 -0600)]
qcow2: Inform block layer about discard boundaries
At the qcow2 layer, discard is only possible on a per-cluster
basis; at the moment, qcow2 silently rounds any unaligned
requests to this granularity. However, an upcoming patch will
fix a regression in the block layer ignoring too much of an
unaligned discard request, by changing the block layer to
break up a discard request at alignment boundaries; for that
to work, the block layer must know about our limits.
However, we can't go one step further by changing
qcow2_discard_clusters() to assert that requests are always
aligned, since that helper function is reached on paths
outside of the block layer.
CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Include sys/user.h for declaration of 'struct kinfo_proc'.
Add -lutil to qemu-ga link for kinfo_getproc.
Signed-off-by: Ed Maste <emaste@freebsd.org>
Message-id: 1479778365-11315-1-git-send-email-emaste@freebsd.org Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Kevin Wolf [Thu, 17 Nov 2016 10:30:08 +0000 (11:30 +0100)]
gluster: Fix use after free in glfs_clear_preopened()
This fixes a use-after-free bug introduced in commit 6349c154. We need
to use QLIST_FOREACH_SAFE() when freeing elements in the loop. Spotted
by Coverity.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Message-id: 1479378608-11962-1-git-send-email-kwolf@redhat.com Signed-off-by: Jeff Cody <jcody@redhat.com>
Eduardo Habkost [Fri, 11 Nov 2016 16:45:42 +0000 (14:45 -0200)]
acpi: Use apic_id_limit when calculating legacy ACPI table size
The code that calculates the legacy ACPI table size for migration
compatibility uses max_cpus when calculating legacy_aml_len (the size of
the DSDT and SSDT tables). However, the SSDT grows according to APIC ID
limit, not max_cpus.
The bug is not triggered very often because of the 4k alignment on the
table size. But it can be triggered if you are unlucky enough to cross a
4k boundary.
Change the legacy_aml_len calculation to use apic_id_limit, to calculate
the right size.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffec4268700 (LWP 7657)]
__memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2757
(gdb) bt
#0 __memcpy_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:2757
#1 0x00005555559ef775 in memcpy (__len=3, __src=0xc1421c, __dest=<optimized out>)
at /usr/include/bits/string3.h:51
#2 qemu_put_buffer (f=0x555557a97690, buf=0xc1421c <Address 0xc1421c out of bounds>, size=3)
at migration/qemu-file.c:346
#3 0x00005555559eef66 in vmstate_save_state (f=f@entry=0x555557a97690,
vmsd=0x555555f8a5a0 <vmstate_ISAIPMIKCSDevice>, opaque=0x555557231160,
vmdesc=vmdesc@entry=0x55555798cc40) at migration/vmstate.c:333
#4 0x00005555557cfe45 in vmstate_save (f=f@entry=0x555557a97690, se=se@entry=0x555557231de0,
vmdesc=vmdesc@entry=0x55555798cc40) at /mnt/sdb/zyy/qemu/migration/savevm.c:720
#5 0x00005555557d2be7 in qemu_savevm_state_complete_precopy (f=0x555557a97690,
iterable_only=iterable_only@entry=false) at /mnt/sdb/zyy/qemu/migration/savevm.c:1128
#6 0x00005555559ea102 in migration_completion (start_time=<synthetic pointer>,
old_vm_running=<synthetic pointer>, current_active_state=<optimized out>,
s=0x5555560eaa80 <current_migration.44078>) at migration/migration.c:1707
#7 migration_thread (opaque=0x5555560eaa80 <current_migration.44078>) at migration/migration.c:1855
#8 0x00007ffff3900dc5 in start_thread (arg=0x7ffec4268700) at pthread_create.c:308
#9 0x00007fffefc6c71d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Signed-off-by: Zhuang Yanying <ann.zhuangyanying@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Zhuang Yanying [Thu, 17 Nov 2016 12:31:03 +0000 (20:31 +0800)]
ivshmem: Fix 64 bit memory bar configuration
Device ivshmem property use64=0 is designed to make the device
expose a 32 bit shared memory BAR instead of 64 bit one. The
default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit
BAR. A 32 bit BAR can support only up to 1 GiB of shared memory.
This worked as designed until commit 5400c02 accidentally flipped
its sense: since then, we misinterpret use64=0 as use64=1 and vice
versa. Worse, the default got flipped as well. Devices
ivshmem-plain and ivshmem-doorbell are not affected.
Fix by restoring the test of IVShmemState member not_legacy_32bit
that got messed up in commit 5400c02. Also update its
initialization for devices ivhsmem-plain and ivshmem-doorbell.
Without that, they'd regress to 32 bit BARs.
Cc: qemu-stable@nongnu.org Signed-off-by: Zhuang Yanying <ann.zhuangyanying@huawei.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
Paolo Bonzini [Fri, 18 Nov 2016 15:07:02 +0000 (16:07 +0100)]
virtio: set ISR on dataplane notifications
Dataplane has been omitting forever the step of setting ISR when
an interrupt is raised. This caused little breakage, because the
specification actually says that ISR may not be updated in MSI mode.
Some versions of the Windows drivers however didn't clear MSI mode
correctly, and proceeded using polling mode (using ISR, not the used
ring index!) for crashdump and hibernation. If it were just crashdump
and hibernation it would not be a big deal, but recent releases of
Windows do not really shut down, but rather log out and hibernate to
make the next startup faster. Hence, this manifested as a more serious
hang during shutdown with e.g. Windows 8.1 and virtio-win 1.8.0 RPMs.
Newer versions fixed this, while older versions do not use MSI at all.
The failure has always been there for virtio dataplane, but it became
visible after commits 9ffe337 ("virtio-blk: always use dataplane path
if ioeventfd is active", 2016-10-30) and ad07cd6 ("virtio-scsi: always
use dataplane path if ioeventfd is active", 2016-10-30) made virtio-blk
and virtio-scsi always use the dataplane code under KVM. The good news
therefore is that it was not a bug in the patches---they were doing
exactly what they were meant for, i.e. shake out remaining dataplane bugs.
The fix is not hard, so it's worth arranging for the broken drivers.
The virtio_should_notify+event_notifier_set pair that is common to
virtio-blk and virtio-scsi dataplane is replaced with a new public
function virtio_notify_irqfd that also sets ISR. The irqfd emulation
code now need not set ISR anymore, so virtio_irq is removed.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Farhan Ali <alifm@linux.vnet.ibm.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Paolo Bonzini [Fri, 18 Nov 2016 15:07:01 +0000 (16:07 +0100)]
virtio: access ISR atomically
This will be needed once dataplane will be able to set it outside
the big QEMU lock.
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Farhan Ali <alifm@linux.vnet.ibm.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Paolo Bonzini [Fri, 18 Nov 2016 15:07:00 +0000 (16:07 +0100)]
virtio: introduce grab/release_ioeventfd to fix vhost
Following the recent refactoring of virtio notifiers [1], more specifically
the patch ed08a2a0b ("virtio: use virtio_bus_set_host_notifier to
start/stop ioeventfd") that uses virtio_bus_set_host_notifier [2]
by default, core virtio code requires 'ioeventfd_started' to be set
to true/false when the host notifiers are configured.
When vhost is stopped and started, however, there is a stop followed by
another start. Since ioeventfd_started was never set to true, the 'stop'
operation triggered by virtio_bus_set_host_notifier() will not result
in a call to virtio_pci_ioeventfd_assign(assign=false). This leaves
the memory regions with stale notifiers and results on the next start
triggering the following assertion:
This patch reintroduces (hopefully in a cleaner way) the concept
that was present with ioeventfd_disabled before the refactoring.
When ioeventfd_grabbed>0, ioeventfd_started tracks whether ioeventfd
should be enabled or not, but ioeventfd is actually not started at
all until vhost releases the host notifiers.
Reported-by: Felipe Franciosi <felipe@nutanix.com> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Reported-by: Alex Williamson <alex.williamson@redhat.com> Fixes: ed08a2a0b ("virtio: use virtio_bus_set_host_notifier to start/stop ioeventfd") Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru> Tested-by: Farhan Ali <alifm@linux.vnet.ibm.com> Tested-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
We must check for new virtqueue buffers after re-enabling notifications.
This prevents the race condition where the guest added buffers just
after we stopped popping the virtqueue but before we re-enabled
notifications.
I think the virtio-crypto code was based on virtio-net but this crucial
detail was missed. virtio-net does not have the race condition because
it processes the virtqueue one more time after re-enabling
notifications.
Cc: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Zhuang Yanying [Thu, 17 Nov 2016 14:37:17 +0000 (18:37 +0400)]
ivshmem: Fix 64 bit memory bar configuration
Device ivshmem property use64=0 is designed to make the device
expose a 32 bit shared memory BAR instead of 64 bit one. The
default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit
BAR. A 32 bit BAR can support only up to 1 GiB of shared memory.
This worked as designed until commit 5400c02 accidentally flipped
its sense: since then, we misinterpret use64=0 as use64=1 and vice
versa. Worse, the default got flipped as well. Devices
ivshmem-plain and ivshmem-doorbell are not affected.
Fix by restoring the test of IVShmemState member not_legacy_32bit
that got messed up in commit 5400c02. Also update its
initialization for devices ivhsmem-plain and ivshmem-doorbell.
Without that, they'd regress to 32 bit BARs.
projects / mirror_qemu.git / log