Fix various small problems in hexdump code, such as:
- Reference to non-existing field etsec->nic->nc.name is replaced
with nc->name
- Type mismatch warnings
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
In Cirrus CLGD 54xx VGA Emulator, if cirrus graphics mode is VGA,
'cirrus_get_bpp' returns zero(0), which could lead to a divide
by zero error in while copying pixel data. The same could occur
via blit pitch values. Add check to avoid it.
Reported-by: Huawei PSIRT <psirt@huawei.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Message-id: 1476776717-24807-1-git-send-email-ppandit@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Depending on QEMU network setup it is possible for us to receive a
complete Ethernet packet that is less 64 bytes long. One such example is
when QEMU is configured to use a standalone TAP device (not set to be a
part of any bridge) receives and ARP packet. In cases like that we need
to add more than just 4-bytes of CRC padding and ensure that our payload
is at least 60 bytes long, such that, when combined with CRC padding
bytes the resulting size is at least 802.3 minimum MTU bytes
long (64). Failing to do that results in code in etsec_walk_rx_ring()
setting BD_RX_SH which, in turn, makes corresponding Linux driver of
emulated host to reject buffer as a runt packet
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
ColdFire Fast Ethernet Controller uses a receive buffer size
register(EMRBR) to hold maximum size of all receive buffers.
It is set by a user before any operation. If it was set to be
zero, ColdFire emulator would go into an infinite loop while
receiving data in mcf_fec_receive. Add check to avoid it.
Reported-by: Wjjzhang <wjjzhang@tencent.com>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
Signed-off-by: Jason Wang <jasowang@redhat.com>
In update_cursor_data_virgl function, if the 'width'/ 'height'
is not equal to current cursor's width/height it will return
without free the 'data' allocated previously. This will lead
a memory leak issue. This patch fix this issue.
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Message-id: 58187760.41d71c0a.cca75.4cb9@mx.google.com
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In virgl_cmd_get_capset_info dispatch function, the 'resp' hasn't
been full initialized before writing to the guest. This will leak
the 'resp.padding' and 'resp.hdr.padding' fieds to the guest. This
patch fix this issue.
Signed-off-by: Li Qiang <liqiang6-s@360.cn>
Message-id: 5818661e.0860240a.77264.7a56@mx.google.com
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently if the client keeps sending the same monitor config to
QEMU/spice-server, QEMU will always raise
a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG regardless of whether there was a
change or not.
Guest-side (with fedora 25), the kernel QXL KMS driver will also forward the
event to user-space without checking if there were actual changes.
Next in line are gnome-shell/mutter (on a default f25 install), which
will try to reconfigure everything without checking if there is anything
to do.
Where this gets ugly is that when applying the resolution changes,
gnome-shell/mutter will call drmModeRmFB, drmModeAddFB, and
drmModeSetCrtc, which will cause the primary surface to be destroyed and
recreated by the QXL KMS driver. This in turn will cause the client to
resend a client monitors config message, which will cause QEMU to reemit
an interrupt with an unchanged monitors configuration, ...
This causes https://bugzilla.redhat.com/show_bug.cgi?id=1266484
This commit makes sure that we only emit
QXL_INTERRUPT_CLIENT_MONITORS_CONFIG when there are actual configuration
changes the guest should act on.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Message-id: 20161028144840.18326-1-cfergeau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Just a single migration / hotplug fix in this set. I believe it's
important enough to go in this late in the 2.8 release process.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJYP6qFAAoJEGw4ysog2bOSNKMQANcyLWs27Iim3jW397wDombJ
X0rC0luweUXkFzT4eyf2o+7c2HgXYzokUOElrlhU5AN93M64WaJb2chw+nn8WuZH
H7Ef1WR9yIVc3mVB+B8fWo4QIxehTFjKVTgGwAv+F1WAcGeIR9TPVdquxl3giYUb
Mqx+Kh4jIWzVlmOeaYql3DIQX80zMhDQdUoKEbL93pXx6PfJKez7yypygDdf6BPb
PbrA4wFBKay83bwrIVWw+OK4i1v1zqF+A1+UyJSCCkbPui2UGzp1j0xqaI70SUwP
7JxOMhhhbQHKyC2pIdtlmxBBUuCjG4n3LskouKyVZu/ys8gybszoHdjLdavTFLO5
Slri4iwjyPieW+nUrNVdhXJRDE8/knQtPf6Xqby8uOD0g8qJ7RSV7hN5LROZ30HU
HONMvu3b4z0Rruls1l8z+gHvzNU1Raoh6XzfPUF7NtxwuTMcZ0JkeanSHiax5GdH
UgCOwKmXp0ZCuQ8Zzep3nyuZsCNxQKk5BR/nRG9LTu6skwED9BQZzEKxcKj6DpTu
ipPNrHyfM+s4MX1nURZreX1+HHLxAacxfdGZxuN6s+69acILui4igRiyscl8KJyn
vSXq6ipjfi0bbsDJJ5FxlVcflkf06n6xhC2ncNydnSoxCjIVEh3sUdEVlhPvKDaV
UwZSmf8kse3UQn+HgSCn
=Kar4
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'dgibson/tags/ppc-for-2.8-20161201' into staging
ppc patch queue 2016-12-01
Just a single migration / hotplug fix in this set. I believe it's
important enough to go in this late in the 2.8 release process.
# gpg: Signature made Thu 01 Dec 2016 04:43:49 AM GMT
# gpg: using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>"
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* dgibson/tags/ppc-for-2.8-20161201:
spapr: fix default DRC state for coldplugged LMBs
Message-id: 20161201044441.14365-1-david@gibson.dropbear.id.au
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
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>
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>
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: 3e76099aac
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>
* Commit 3e76099aac ("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 3e76099aac forgot to update the third utility caller of
rom_insert(), under point (1), namely rom_add_blob().
* Later, commit 5e774eb3bd ("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():
load_uimage_as()
load_uboot_image()
rom_add_blob_fixed_as()
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 e481a1f63c ("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: 3e76099aac
Fixes: 5e774eb3bd
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>
"mask" needs to be inverted before use.
Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQExBAABCAAbBQJYPFEQFBxwYm9uemluaUByZWRoYXQuY29tAAoJEL/70l94x66D
yF4H/3oBEgzDF9HbnSklknGhkPnOvYnNVKtJbHgk4SnZ1FlPSJLohuz15mXxbr+R
0MzWyQliHiBsAX8sMdvVVHm6YVy9JSABnsefhPUgM++1gT3+EhFsToZ9cWsAYOp7
Q4/hMc66ne0N5SWKjTlCzHfBxw3sPDvOoNYSVYjJYeASTSDQuyyVxRRWMYBFSUnD
p4m7dJCz+my8YXz6diTY8csxFRGmt49EtxtQBU1wBrFc+m8qn4UKaTXoqfcDEBe6
RceS9OAWrddv1Ds4OM/ZgD0BikYehYYnq9THvjWuqhTjHdKKYNeZAodqFJicEZmF
aAIZmhTASQo4fHuImtUja5ggYtU=
=Ht4d
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'bonzini/tags/for-upstream' into staging
Small fixes for rc2.
# gpg: Signature made Mon 28 Nov 2016 03:45:20 PM GMT
# gpg: using RSA key 0xBFFBD25F78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>"
# 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
* 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>
* hw/arm/boot: fix crash handling device trees with no /chosen
or /memory nodes
* generic-loader: only set PC if a CPU is specified
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJYPDVpAAoJEDwlJe0UNgze/WIQAKctEMKR/ct7S8AuEqzW6917
3x0lObOiEsogQAZX2kqo49/9d5H74/T1qVSgMAKRotcGdos3a2igj3dNOy+/mrvk
s2fsKLZri95tNSlHGS8A2E+SCUvynzpzG52vI/S+oAcx0/zKpD/GAUCcRDatQP7o
va/eMlbditeAG6Y8qaHafgrfgxlm0kQpywtli2ZMaaJz7kMmid8dfGqPm1sJFk8S
lxIJVsy5e/g8sQn/bR2i5RcE5Q+e6VAnwYifzi3YKPNPl+YHy0P8J99mXQ6kAPke
uxybd60c2isvqxRzGceNRNkVmati2wyHHH0lXY4p2Mf25FqkcWyCZHqg1/kNX1Ox
YBmYl01YQCCgTRCbw1qyjGq9F2R6RZbJdmtwiiVwUz/hbK/KHclrGeUVNh1Dqde+
xVqvxb9dVb02BM/X9k1u/u4AZHYffGJDHQWo2xSBHn8C/R6uVtXlDQ4h56XiU9Ij
eShVv5NiWK1VCSMltU0skzKZkBmLI9sddqBPywWdtgyjabFhq4vmW5MGBHIPIY+B
UKkP+K5sTHd8rjMd9KcTtGj2Q83XLkKTUJQXVQp1ti1wUSHdkqJt0sptxWOEIlaW
QXWHX4FiLniYU+fqj7V1EGld1I9SXncjexgxSKbvxWBEY0eX6eVo/nt19QqHzwcI
EBXbQHZifiSeWtGhKxVP
=7F5K
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161128' into staging
target-arm queue:
* hw/arm/boot: fix crash handling device trees with no /chosen
or /memory nodes
* generic-loader: only set PC if a CPU is specified
# gpg: Signature made Mon 28 Nov 2016 01:47:21 PM GMT
# gpg: using RSA key 0x3C2525ED14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
# gpg: aka "Peter Maydell <pmaydell@gmail.com>"
# gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>"
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* 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>
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>
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>
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>
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>
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>
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>
backends.
-----BEGIN PGP SIGNATURE-----
iEYEABECAAYFAlg1kVUACgkQAvw66wEB28IIzACfXKtN7ut2ZiakDKHH182CadeO
PoMAni7ivvO1KGqO9osvwiEeY2KPIkED
=ZAcB
-----END PGP SIGNATURE-----
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>
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.
domU.cfg:
'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2'
domU:
mkfs.ext4 -F /dev/xvda
Discarding device blocks: failed - Input/output error
Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS.
Add input range checking to avoid overflow.
Fixes f313520 ("xen_disk: add discard support")
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
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>
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>
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>
Unrealize should undo things that were set during realize in
reverse order. So should do in the error path in realize.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Greg Kurz <groug@kaod.org>
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.
There are also a few other assorted bug fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJYNP4mAAoJEGw4ysog2bOSouIQALsw0PNpduvEsUzgEZ6GOgFw
77jEawt4me+eCgB0oipj0Bz9ho2DIGeheiFrvU7vTsD/q00CDc5kZ6GNPlY43sGM
OzT65EyycQ7MDZFDfVgpmaHjXqIGVf5zZbyz8ZD5wU3w10DdRtrDogYcjb+ZQzCG
0vRnAkV/tuVkn9Z5ogWrdvhQa0/ER3Yk/BpTXoe4JFoLgViwydkI6yCSw5dwatEU
djprDinCsBziKDT03Z9wmiTGTvZk6iGHMJWPOLJOSTBd5v9pzdpxtuNrZrF1oOQd
pBE1qlNkCpnd+LLKyW+nsTdo1FyxUg0pg7kWqnSPwqm+KM09Phpp00FN69Hmz/DR
P+aMX9qKaTJoNPHklY15pmF/olIkcxVlidNKaqgKAbZZR5BuHF3YBVILWL8ZfaeE
n6Gw0GqJeTSW5mO81uikKTZt5kqOVChHbxXcxfVl/4vzk8TTS3fy5AW0IERbfgHN
NbBesSZejqL++xzVrfoVyfJV8nkF1M+08FITQdyXpkdYVB565e9YmlIaLpZ5a7It
gLVBqbAEOaC+5swlEyAp70h+nhjVN631+b8gs+bi9trrBL9IL8q3g7U0l7XKM0Zs
MU6nxV2zogbdVraiPv9KrwtOeUKXAPUJfe3fXRr4rBYTL7HK9CBQWjaGNVtFJPKk
vWybUBSmwF402OmslZKp
=cds8
-----END PGP SIGNATURE-----
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.
There are also a few other assorted bug fixes.
# gpg: Signature made Wed 23 Nov 2016 02:25:42 AM GMT
# gpg: using RSA key 0x6C38CACA20D9B392
# gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>"
# gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>"
# gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>"
# gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>"
# Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392
* 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>
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>
This reverts commit 9b54ca0ba7.
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>
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>
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>
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>
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>
This fixes SCSI adapter self-tests done in MIPS Jazz emulation,
broken since ff589551c8.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-Id: <1479508397-8443-1-git-send-email-hpoussin@reactos.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
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.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Add a bus for Xen backend devices in order to be able to establish a
dedicated device path for pluggable devices.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
A typo prevents ISA interrupts from being recognized on cpu0,
which is where the smp kernel normally wants to see them.
Signed-off-by: Richard Henderson <rth@twiddle.net>
Most notably this fixes a regression with vhost introduced by the pull before
last.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJYLyObAAoJECgfDbjSjVRptPoIAK/4SdEAqS9pnXPekPZpIddV
KHCFjj4Q68s22i0jpA1hxSXk1yQZIl56dnynU0DIAbCD1NYQIEmWx7uOJjppre9O
L64V2s2ItEagFBGFwQDoJnUDIyEhth8KRqsa36V2YWJXYOaH1Rx1QNb9tX9R0aeb
2lVwYE+yig1Gc/2PAYJrcKWwM3iwWrYW6ssycP2LEOGOhBCIrGZwDJkqv7ayDVL9
j4tH2eBRrOAzm8c3fybC3OZkeLqcQJnbVONmD8kV0Q0IphcFvloJQCvcefb/3Ox1
HAz57JxZfpxMZPVtvgU8Q+xzElz8noCXg+6lF/dx71CKicwXxg4lsMF1LyKHUoU=
=cuAn
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'mst/tags/for_upstream' into staging
virtio, vhost, pc: fixes
Most notably this fixes a regression with vhost introduced by the pull before
last.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Fri 18 Nov 2016 03:51:55 PM GMT
# gpg: using RSA key 0x281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* mst/tags/for_upstream:
acpi: Use apic_id_limit when calculating legacy ACPI table size
ipmi: fix qemu crash while migrating with ipmi
ivshmem: Fix 64 bit memory bar configuration
virtio: set ISR on dataplane notifications
virtio: access ISR atomically
virtio: introduce grab/release_ioeventfd to fix vhost
virtio-crypto: fix virtio_queue_set_notification() race
Message-id: 1479484366-7977-1-git-send-email-mst@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
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>
Qemu crash in the source side while migrating, after starting ipmi service inside vm.
./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -smp 4 -m 4096 \
-drive file=/work/suse/suse11_sp3_64_vt,format=raw,if=none,id=drive-virtio-disk0,cache=none \
-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 \
-vnc :99 -monitor vc -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-kcs,bmc=bmc0,ioport=0xca2
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>
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>
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>
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>
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:
kvm_mem_ioeventfd_add: error adding ioeventfd: File exists
Aborted
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.
[1] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07748.html
[2] http://lists.nongnu.org/archive/html/qemu-devel/2016-10/msg07760.html
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>
