aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-12-18Update version for 2.10.2 releasev2.10.2Michael Roth
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-15spapr: don't initialize PATB entry if max-cpu-compat < power9Laurent Vivier
if KVM is enabled and KVM capabilities MMU radix is available, the partition table entry (patb_entry) for the radix mode is initialized by default in ppc_spapr_reset(). It's a problem if we want to migrate the guest to a POWER8 host while the kernel is not started to set the value to the one expected for a POWER8 CPU. The "-machine max-cpu-compat=power8" should allow to migrate a POWER9 KVM host to a POWER8 KVM host, but because patb_entry is set, the destination QEMU tries to enable radix mode on the POWER8 host. This fails and cancels the migration: Process table config unsupported by the host error while loading state for instance 0x0 of device 'spapr' load of migration failed: Invalid argument This patch doesn't set the PATB entry if the user provides a CPU compatibility mode that doesn't support radix mode. Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 1481fe5fcfeb7fcf3c1ebb9d8c0432e3e0188ccf) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-15target/ppc: Update setting of cpu features to account for compat modesSuraj Jitindar Singh
The device tree nodes ibm,arch-vec-5-platform-support and ibm,pa-features are used to communicate features of the cpu to the guest operating system. The properties of each of these are determined based on the selected cpu model and the availability of hypervisor features. Currently the compatibility mode of the cpu is not taken into account. The ibm,arch-vec-5-platform-support node is used to communicate the level of support for various ISAv3 processor features to the guest before CAS to inform the guests' request. The available mmu mode should only be hash unless the cpu is a POWER9 which is not in a prePOWER9 compat mode, in which case the available modes depend on the accelerator and the hypervisor capabilities. The ibm,pa-featues node is used to communicate the level of cpu support for various features to the guest os. This should only contain features relevant to the operating mode of the processor, that is the selected cpu model taking into account any compat mode. This means that the compat mode should be taken into account when choosing the properties of ibm,pa-features and they should match the compat mode selected, or the cpu model selected if no compat mode. Update the setting of these cpu features in the device tree as described above to properly take into account any compat mode. We use the ppc_check_compat function which takes into account the current processor model and the cpu compat mode. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 7abd43baec0649002d32bbb1380e936bec6f5867) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-14vfio: Fix vfio-kvm group registrationAlex Williamson
Commit 8c37faa475f3 ("vfio-pci, ppc64/spapr: Reorder group-to-container attaching") moved registration of groups with the vfio-kvm device from vfio_get_group() to vfio_connect_container(), but it missed the case where a group is attached to an existing container and takes an early exit. Perhaps this is a less common case on ppc64/spapr, but on x86 (without viommu) all groups are connected to the same container and thus only the first group gets registered with the vfio-kvm device. This becomes a problem if we then hot-unplug the devices associated with that first group and we end up with KVM being misinformed about any vfio connections that might remain. Fix by including the call to vfio_kvm_device_add_group() in this early exit path. Fixes: 8c37faa475f3 ("vfio-pci, ppc64/spapr: Reorder group-to-container attaching") Cc: qemu-stable@nongnu.org # qemu-2.10+ Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> (cherry picked from commit 2016986aedb6ea2839662eb5f60630f3e231bd1a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06spapr: Include "pre-plugged" DIMMS in ram size calculation at resetDavid Gibson
At guest reset time, we allocate a hash page table (HPT) for the guest based on the guest's RAM size. If dynamic HPT resizing is not available we use the maximum RAM size, if it is we use the current RAM size. But the "current RAM size" calculation is incorrect - we just use the "base" ram_size from the machine structure. This doesn't include any pluggable DIMMs that are already plugged at reset time. This means that if you try to start a 'pseries' machine with a DIMM specified on the command line that's much larger than the "base" RAM size, then the guest will get a woefully inadequate HPT. This can lead to a guest freeze during boot as it runs out of HPT space during initial MMU setup. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 768a20f3a491ed4afce73ebb65347d55251c0ebd) *drop dep on 9aa3397f Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06vga: handle cirrus vbe mode wraparounds.Gerd Hoffmann
Commit "3d90c62548 vga: stop passing pointers to vga_draw_line* functions" is incomplete. It doesn't handle the case that the vga rendering code tries to create a shared surface, i.e. a pixman image backed by vga video memory. That can not work in case the guest display wraps from end of video memory to the start. So force shadowing in that case. Also adjust the snapshot region calculation. Can trigger with cirrus only, when programming vbe modes using the bochs api (stdvga, also qxl and virtio-vga in vga compat mode) wrap arounds can't happen. Fixes: CVE-2017-13672 Fixes: 3d90c6254863693a6b13d918d2b8682e08bbc681 Cc: P J P <ppandit@redhat.com> Reported-by: David Buchanan <d@vidbuchanan.co.uk> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20171010141323.14049-3-kraxel@redhat.com (cherry picked from commit 28f77de26a4f9995458ddeb9d34bb06c0193bdc9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06vga: drop line_offset variableGerd Hoffmann
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 362f811793ff6cb4d209ab61d76cc4f841bb5e46) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06nbd/client: Don't hard-disconnect on ESHUTDOWN from serverEric Blake
The NBD spec says that a server may fail any transmission request with ESHUTDOWN when it is apparent that no further request from the client can be successfully honored. The client is supposed to then initiate a soft shutdown (wait for all remaining in-flight requests to be answered, then send NBD_CMD_DISC). However, since qemu's server never uses ESHUTDOWN errors, this code was mostly untested since its introduction in commit b6f5d3b5. More recently, I learned that nbdkit as the NBD server is able to send ESHUTDOWN errors, so I finally tested this code, and noticed that our client was special-casing ESHUTDOWN to cause a hard shutdown (immediate disconnect, with no NBD_CMD_DISC), but only if the server sends this error as a simple reply. Further investigation found that commit d2febedb introduced a regression where structured replies behave differently than simple replies - but that the structured reply behavior is more in line with the spec (even if we still lack code in nbd-client.c to properly quit sending further requests). So this patch reverts the portion of b6f5d3b5 that introduced an improper hard-disconnect special-case at the lower level, and leaves the future enhancement of a nicer soft-disconnect at the higher level for another day. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20171113194857.13933-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> (cherry picked from commit 01b05c66a3616d5a4adc39fc90962e9efaf791d1) Conflicts: nbd/client.c *drop dep on d2febedb Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06nbd-client: Refuse read-only client with BDRV_O_RDWREric Blake
The NBD spec says that clients should not try to write/trim to an export advertised as read-only by the server. But we failed to check that, and would allow the block layer to use NBD with BDRV_O_RDWR even when the server is read-only, which meant we were depending on the server sending a proper EPERM failure for various commands, and also exposes a leaky abstraction: using qemu-io in read-write mode would succeed on 'w -z 0 0' because of local short-circuiting logic, but 'w 0 0' would send a request over the wire (where it then depends on the server, and fails at least for qemu-nbd but might pass for other NBD implementations). With this patch, a client MUST request read-only mode to access a server that is doing a read-only export, or else it will get a message like: can't open device nbd://localhost:10809/foo: request for write access conflicts with read-only export It is no longer possible to even attempt writes over the wire (including the corner case of 0-length writes), because the block layer enforces the explicit read-only request; this matches the behavior of qcow2 when backed by a read-only POSIX file. Fix several iotests to comply with the new behavior (since qemu-nbd of an internal snapshot, as well as nbd-server-add over QMP, default to a read-only export, we must tell blockdev-add/qemu-io to set up a read-only client). CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20171108215703.9295-3-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> (cherry picked from commit 1104d83c726d2b20f9cec7b99ab3570a2fdbd46d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06nbd/server: fix nbd_negotiate_handle_infoVladimir Sementsov-Ogievskiy
namelen should be here, length is unrelated, and always 0 at this point. Broken in introduction in commit f37708f6, but mostly harmless (replying with '' as the name does not violate protocol, and does not confuse qemu as the nbd client since our implementation does not ask for the name; but might confuse some other client that does ask for the name especially if the default export is different than the export name being queried). Adding an assert makes it obvious that we are not skipping any bytes in the client's message, as well as making it obvious that we were using the wrong variable. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> CC: qemu-stable@nongnu.org Message-Id: <20171101154204.27146-1-vsementsov@virtuozzo.com> [eblake: improve commit message, squash in assert addition] Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 46321d6b5f8c880932a6b3d07bd0ff6f892e665c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06vhost: fix error check in vhost_verify_ring_mappings()Greg Kurz
Since commit f1f9e6c5 "vhost: adapt vhost_verify_ring_mappings() to virtio 1 ring layout", we check the mapping of each part (descriptor table, available ring and used ring) of each virtqueue separately. The checking of a part is done by the vhost_verify_ring_part_mapping() function: it returns either 0 on success or a negative errno if the part cannot be mapped at the same place. Unfortunately, the vhost_verify_ring_mappings() function checks its return value the other way round. It means that we either: - only verify the descriptor table of the first virtqueue, and if it is valid we ignore all the other mappings - or ignore all broken mappings until we reach a valid one ie, we only raise an error if all mappings are broken, and we consider all mappings are valid otherwise (false success), which is obviously wrong. This patch ensures that vhost_verify_ring_mappings() only returns success if ALL mappings are okay. Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 2fe45ec3bffbd3a26f2ed39f60bab0ca5217d8f6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06nbd/server: CVE-2017-15118 Stack smash on large export nameEric Blake
Introduced in commit f37708f6b8 (2.10). The NBD spec says a client can request export names up to 4096 bytes in length, even though they should not expect success on names longer than 256. However, qemu hard-codes the limit of 256, and fails to filter out a client that probes for a longer name; the result is a stack smash that can potentially give an attacker arbitrary control over the qemu process. The smash can be easily demonstrated with this client: $ qemu-io f raw nbd://localhost:10809/$(printf %3000d 1 | tr ' ' a) If the qemu NBD server binary (whether the standalone qemu-nbd, or the builtin server of QMP nbd-server-start) was compiled with -fstack-protector-strong, the ability to exploit the stack smash into arbitrary execution is a lot more difficult (but still theoretically possible to a determined attacker, perhaps in combination with other CVEs). Still, crashing a running qemu (and losing the VM) is bad enough, even if the attacker did not obtain full execution control. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 51ae4f8455c9e32c54770c4ebc25bf86a8128183) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06nbd/server: CVE-2017-15119 Reject options larger than 32MEric Blake
The NBD spec gives us permission to abruptly disconnect on clients that send outrageously large option requests, rather than having to spend the time reading to the end of the option. No real option request requires that much data anyways; and meanwhile, we already have the practice of abruptly dropping the connection on any client that sends NBD_CMD_WRITE with a payload larger than 32M. For comparison, nbdkit drops the connection on any request with more than 4096 bytes; however, that limit is probably too low (as the NBD spec states an export name can theoretically be up to 4096 bytes, which means a valid NBD_OPT_INFO could be even longer) - even if qemu doesn't permit exports longer than 256 bytes. It could be argued that a malicious client trying to get us to read nearly 4G of data on a bad request is a form of denial of service. In particular, if the server requires TLS, but a client that does not know the TLS credentials sends any option (other than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated payload of nearly 4G, then the server was keeping the connection alive trying to read all the payload, tying up resources that it would rather be spending on a client that can get past the TLS handshake. Hence, this warranted a CVE. Present since at least 2.5 when handling known options, and made worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE to handle unknown options. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> (cherry picked from commit fdad35ef6c5839d50dfc14073364ac893afebc30) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06virtio-net: don't touch virtqueue if vm is stoppedJason Wang
Guest state should not be touched if VM is stopped, unfortunately we didn't check running state and tried to drain tx queue unconditionally in virtio_net_set_status(). A crash was then noticed as a migration destination when user type quit after virtqueue state is loaded but before region cache is initialized. In this case, virtio_net_drop_tx_queue_data() tries to access the uninitialized region cache. Fix this by only dropping tx queue data when vm is running. Fixes: 283e2c2adcb80 ("net: virtio-net discards TX data after link down") Cc: Yuri Benditovich <yuri.benditovich@daynix.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit 70e53e6e4da3db4b2c31981191753a7e974936d0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06block/nfs: fix nfs_client_open for filesize greater than 1TBPeter Lieven
DIV_ROUND_UP(st.st_size, BDRV_SECTOR_SIZE) was overflowing ret (int) if st.st_size is greater than 1TB. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Lieven <pl@kamp.de> Message-id: 1511798407-31129-1-git-send-email-pl@kamp.de Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit f1a7ff770f7d71ee7833ff019aac9d6cc3d13f71) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06scripts/make-release: ship u-boot source as a tarballMichael Roth
The u-boot sources we ship currently cause problems with unpacking on a case-insensitive filesystem due to path conflicts. This has been fixed in upstream u-boot via commit 610eec7f, but since it is not yet included in an official release we implement this approach as a temporary workaround. Once we move to a u-boot containing commit 610eec7f we should revert this patch. Cc: qemu-stable@nongnu.org Cc: Alexander Graf <agraf@suse.de> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Suggested-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20171107205201.10207-1-mdroth@linux.vnet.ibm.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit d0dead3b6df7f6cd970ed02e8369ab8730aac9d3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06spapr: reset DRCs after devicesGreg Kurz
A DRC with a pending unplug request releases its associated device at machine reset time. In the case of LMB, when all DRCs for a DIMM device have been reset, the DIMM gets unplugged, causing guest memory to disappear. This may be very confusing for anything still using this memory. This is exactly what happens with vhost backends, and QEMU aborts with: qemu-system-ppc64: used ring relocated for ring 2 qemu-system-ppc64: qemu/hw/virtio/vhost.c:649: vhost_commit: Assertion `r >= 0' failed. The issue is that each DRC registers a QEMU reset handler, and we don't control the order in which these handlers are called (ie, a LMB DRC will unplug a DIMM before the virtio device using the memory on this DIMM could stop its vhost backend). To avoid such situations, let's reset DRCs after all devices have been reset. Reported-by: Mallesh N. Koti <mallesh@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Reviewed-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 82512483940c756e2db1bd67ea91b02bc29c5e01) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06hw/ppc: clear pending_events on machine resetDaniel Henrique Barboza
The sPAPR machine isn't clearing up the pending events QTAILQ on machine reboot. This allows for unprocessed hotplug/epow events to persist in the queue after reset and, when reasserting the IRQs in check_exception later on, these will be being processed by the OS. This patch implements a new function called 'spapr_clear_pending_events' that clears up the pending_events QTAILQ. This helper is then called inside ppc_spapr_reset to clear up the events queue, preventing old/deprecated events from persisting after a reset. Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 56258174238eb25df629a53a96e1ac16a32dc7d4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06vhost: restore avail index from vring used index on disconnectionMaxime Coquelin
vhost_virtqueue_stop() gets avail index value from the backend, except if the backend is not responding. It happens when the backend crashes, and in this case, internal state of the virtio queue is inconsistent, making packets to corrupt the vring state. With a Linux guest, it results in following error message on backend reconnection: [ 22.444905] virtio_net virtio0: output.0:id 0 is not a head! [ 22.446746] net enp0s3: Unexpected TXQ (0) queue failure: -5 [ 22.476360] net enp0s3: Unexpected TXQ (0) queue failure: -5 Fixes: 283e2c2adcb8 ("net: virtio-net discards TX data after link down") Cc: qemu-stable@nongnu.org Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 2ae39a113af311cb56a0c35b7f212dafcef15303) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06virtio: Add queue interface to restore avail index from vring used indexMaxime Coquelin
In case of backend crash, it is not possible to restore internal avail index from the backend value as vhost_get_vring_base callback fails. This patch provides a new interface to restore internal avail index from the vring used index, as done by some vhost-user backend on reconnection. Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 2d4ba6cc741df15df6fbb4feaa706a02e103083a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06util/stats64: Fix min/max comparisonsMax Reitz
stat64_min_slow() and stat64_max_slow() compare the wrong way. This makes iotest 136 fail with clang and -m32. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20171114232223.25207-1-mreitz@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 26a5db322be1e424a815d070ddd04442a5e5df50) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06nbd/client: Use error_prepend() correctlyEric Blake
When using error prepend(), it is necessary to end with a space in the format string; otherwise, messages come out incorrectly, such as when connecting to a socket that hangs up immediately: can't open device nbd://localhost:10809/: Failed to read dataUnexpected end-of-file before all bytes were read Originally botched in commit e44ed99d, then several more instances added in the meantime. Pre-existing and not fixed here: we are inconsistent on capitalization; some of our messages start with lower case, and others start with upper, although the use of error_prepend() is much nicer to read when all fragments consistently start with lower. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20171113152424.25381-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> (cherry picked from commit cb6b1a3fc30c52ffd94ed0b69ca5991b19651724) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06net: fix check for number of parameters to -netdev socketJens Freimann
Since commit 0f8c289ad "net: fix -netdev socket,fd= for UDP sockets" we allow more than one parameter for -netdev socket. But now we run into an assert when no parameter at all is specified > qemu-system-x86_64 -netdev socket socket.c:729: net_init_socket: Assertion `sock->has_udp' failed. Fix this by reverting the change of the if condition done in 0f8c289ad. Cc: Jason Wang <jasowang@redhat.com> Cc: qemu-stable@nongnu.org Fixes: 0f8c289ad539feb5135c545bea947b310a893f4b Reported-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Signed-off-by: Jens Freimann <jfreimann@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit ff86d5762552787f1fcb7da695ec4f8c1be754b4) Conflicts: net/socket.c * drop context dep on 0522a959 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06net/socket: fix coverity issueJens Freimann
This fixes coverity issue CID1005339. Make sure that saddr is not used uninitialized if the mcast parameter is NULL. Cc: qemu-stable@nongnu.org Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Jens Freimann <jfreimann@redhat.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit bb160b571fe469b03228d4502c75a18045978a74) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06hw/intc/arm_gicv3_its: Don't abort on table save failureEric Auger
The ITS is not fully properly reset at the moment. Caches are not emptied. After a reset, in case we attempt to save the state before the bound devices have registered their MSIs and after the 1st level table has been allocated by the ITS driver (device BASER is valid), the first level entries are still invalid. If the device cache is not empty (devices registered before the reset), vgic_its_save_device_tables fails with -EINVAL. This causes a QEMU abort(). Cc: qemu-stable@nongnu.org Signed-off-by: Eric Auger <eric.auger@redhat.com> Reported-by: wanghaibin <wanghaibin.wang@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 8a7348b5d62d7ea16807e6bea54b448a0184bb0f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06translate.c: Fix usermode big-endian AArch32 LDREXD and STREXDPeter Maydell
For AArch32 LDREXD and STREXD, architecturally the 32-bit word at the lowest address is always Rt and the one at addr+4 is Rt2, even if the CPU is big-endian. Our implementation does these with a single 64-bit store, so if we're big-endian then we need to put the two 32-bit halves together in the opposite order to little-endian, so that they end up in the right places. We were trying to do this with the gen_aa32_frob64() function, but that is not correct for the usermode emulator, because there there is a distinction between "load a 64 bit value" (which does a BE 64-bit access and doesn't need swapping) and "load two 32 bit values as one 64 bit access" (where we still need to do the swapping, like system mode BE32). Fixes: https://bugs.launchpad.net/qemu/+bug/1725267 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 1509622400-13351-1-git-send-email-peter.maydell@linaro.org (cherry picked from commit 3448d47b3172015006b79197eb5a69826c6a7b6d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06ppc: fix setting of compat modeGreg Kurz
While trying to make KVM PR usable again, commit 5dfaa532ae introduced a regression: the current compat_pvr value is passed to KVM instead of the new one. This means that we always pass 0 instead of the max-cpu-compat PVR during the initial machine reset. And at CAS time, we either pass the PVR from the command line or even don't call kvmppc_set_compat() at all, ie, the PCR will not be set as expected. For example if we start a big endian fedora26 guest in power7 compat mode on a POWER8 host, we get this in the guest: $ cat /proc/cpuinfo processor : 0 cpu : POWER7 (architected), altivec supported clock : 4024.000000MHz revision : 2.0 (pvr 004d 0200) timebase : 512000000 platform : pSeries model : IBM pSeries (emulated by qemu) machine : CHRP IBM pSeries (emulated by qemu) MMU : Hash but the guest can still execute POWER8 instructions, and the following program succeeds: int main() { asm("vncipher 0,0,0"); // ISA 2.07 instruction } Let's pass the new compat_pvr to kvmppc_set_compat() and the program fails with SIGILL as expected. Reported-by: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit e4f0c6bb1a9f72ad9e32c3171d36bae17ea1cd67) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06io: monitor encoutput buffer size from websocket GSourceDaniel P. Berrange
The websocket GSource is monitoring the size of the rawoutput buffer to determine if the channel can accepts more writes. The rawoutput buffer, however, is merely a temporary staging buffer before data is copied into the encoutput buffer. Thus its size will always be zero when the GSource runs. This flaw causes the encoutput buffer to grow without bound if the other end of the underlying data channel doesn't read data being sent. This can be seen with VNC if a client is on a slow WAN link and the guest OS is sending many screen updates. A malicious VNC client can act like it is on a slow link by playing a video in the guest and then reading data very slowly, causing QEMU host memory to expand arbitrarily. This issue is assigned CVE-2017-15268, publically reported in https://bugs.launchpad.net/qemu/+bug/1718964 (cherry picked from commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493) Reviewed-by: Eric Blake <eblake@redhat.com> [Dan: Added extra checks to deal with code refactored in master but not stable 2.10] Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-06nios2: define tcg_envPaolo Bonzini
This should be done by all target and, since commit 53f6672bcf ("gen-icount: use tcg_ctx.tcg_env instead of cpu_env", 2017-06-30), is causing the NIOS2 target to hang. This is because the test for "should I exit to the main loop" was being done with the correct offset to the icount decrementer, but using TCG temporary 0 (the frame pointer) rather than the env pointer. Cc: qemu-stable@nongnu.org Cc: Marek Vasut <marex@denx.de> Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 17bd9597be45b96ae00716b0ae01a4d11bbee1ab) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-05iotests: Add cluster_size=64k to 125Max Reitz
Apparently it would be a good idea to test that, too. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20171009215533.12530-4-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 4c112a397c2f61038914fa315a7896ce6d645d18) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-05qcow2: Always execute preallocate() in a coroutineMax Reitz
Some qcow2 functions (at least perform_cow()) expect s->lock to be taken. Therefore, if we want to make use of them, we should execute preallocate() (as "preallocate_co") in a coroutine so that we can use the qemu_co_mutex_* functions. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20171009215533.12530-3-mreitz@redhat.com Cc: qemu-stable@nongnu.org Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit 572b07bea1d1a0f7726fd95c2613c76002a379bc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-05qcow2: Fix unaligned preallocated truncationMax Reitz
A qcow2 image file's length is not required to have a length that is a multiple of the cluster size. However, qcow2_refcount_area() expects an aligned value for its @start_offset parameter, so we need to round @old_file_size up to the next cluster boundary. Reported-by: Ping Li <pingl@redhat.com> Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1414049 Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20171009215533.12530-2-mreitz@redhat.com Cc: qemu-stable@nongnu.org Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> (cherry picked from commit e400ad1e1f0127b4fdabcb1c8de1e99be91788df) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-05hw/sd: fix out-of-bounds check for multi block readsMichael Olbrich
The current code checks if the next block exceeds the size of the card. This generates an error while reading the last block of the card. Do the out-of-bounds check when starting to read a new block to fix this. This issue became visible with increased error checking in Linux 4.13. Cc: qemu-stable@nongnu.org Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Message-id: 20170916091611.10241-1-m.olbrich@pengutronix.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 8573378e62d19e25a2434e23462ec99ef4d065ac) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: fix off-by-one error in memory_region_notify_one()Maxime Coquelin
This patch fixes an off-by-one error that could lead to the notifyee to receive notifications for ranges it is not registered to. The bug has been spotted by code review. Fixes: bd2bfa4c52e5 ("memory: introduce memory_region_notify_one()") Cc: qemu-stable@nongnu.org Cc: Peter Xu <peterx@redhat.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Message-Id: <20171010094247.10173-4-maxime.coquelin@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b021d1c04452276f4926eed2d104ccbd1037a6e1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04exec: simplify address_space_get_iotlb_entryPeter Xu
This patch let address_space_get_iotlb_entry() to use the newly introduced page_mask parameter in flatview_do_translate(). Then we will be sure the IOTLB can be aligned to page mask, also we should nicely support huge pages now when introducing a764040. Fixes: a764040 ("exec: abstract address_space_do_translate()") Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <20171010094247.10173-3-maxime.coquelin@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 076a93d7972c9c1e3839d2f65edc32568a2cce93) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04exec: add page_mask for flatview_do_translatePeter Xu
The function is originally used for flatview_space_translate() and what we care about most is (xlat, plen) range. However for iotlb requests, we don't really care about "plen", but the size of the page that "xlat" is located on. While, plen cannot really contain this information. A simple example to show why "plen" is not good for IOTLB translations: E.g., for huge pages, it is possible that guest mapped 1G huge page on device side that used this GPA range: 0x100000000 - 0x13fffffff Then let's say we want to translate one IOVA that finally mapped to GPA 0x13ffffe00 (which is located on this 1G huge page). Then here we'll get: (xlat, plen) = (0x13fffe00, 0x200) So the IOTLB would be only covering a very small range since from "plen" (which is 0x200 bytes) we cannot tell the size of the page. Actually we can really know that this is a huge page - we just throw the information away in flatview_do_translate(). This patch introduced "page_mask" optional parameter to capture that page mask info. Also, I made "plen" an optional parameter as well, with some comments for the whole function. No functional change yet. Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com> Message-Id: <20171010094247.10173-2-maxime.coquelin@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit d5e5fafd11be4458443c43f19c1ebdd24d99a751) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Share special empty FlatViewAlexey Kardashevskiy
This shares an cached empty FlatView among address spaces. The empty FV is used every time when a root MR renders into a FV without memory sections which happens when MR or its children are not enabled or zero-sized. The empty_view is not NULL to keep the rest of memory API intact; it also has a dispatch tree for the same reason. On POWER8 with 255 CPUs, 255 virtio-net, 40 PCI bridges guest this halves the amount of FlatView's in use (557 -> 260) and dispatch tables (~800000 -> ~370000). In an unrelated experiment with 112 non-virtio devices on x86 ("-M pc"), only 4 FlatViews are alive, and about ~2000 are created at startup. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-16-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 092aa2fc65b7a35121616aad8f39d47b8f921618) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: seek FlatView sharing candidates among children subregionsPaolo Bonzini
A container can be used instead of an alias to allow switching between multiple subregions. In this case we cannot directly share the subregions (since they only belong to a single parent), but if the subregions are aliases we can in turn walk those. This is not enough to remove all source of quadratic FlatView creation, but it enables sharing of the PCI bus master FlatViews (and their AddressSpaceDispatch structures) across all PCI devices. For 112 virtio-net-pci devices, boot time is reduced from 25 to 10 seconds and memory consumption from 1.4 to 1 G. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit e673ba9af9bf8fd8e0f44025ac738b8285b3ed27) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: trace FlatView creation and destructionPaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 02d9651d6a46479e9d70b72dca34e43605d06cda) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Create FlatView directlyAlexey Kardashevskiy
This avoids usual memory_region_transaction_commit() which rebuilds all FVs. On POWER8 with 255 CPUs, 255 virtio-net, 40 PCI bridges guest this brings down the boot time from 25s to 20s and reduces the amount of temporary FVs allocated during machine constructon (~800000 -> ~640000) and amount of temporary dispatch trees (~370000 -> ~300000), the total memory footprint goes down (18G -> 17G). Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-18-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 202fc01b05572ecb258fdf4c5bd56cf6de8140c7) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Get rid of address_space_init_shareableAlexey Kardashevskiy
Since FlatViews are shared now and ASes not, this gets rid of address_space_init_shareable(). This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-17-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b516572f31c0ea0937cd9d11d9bd72dd83809886) Conflicts: target/arm/cpu.c * drop context deps on 1d2091bc and 1e577cc7 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Do not allocate FlatView in address_space_initAlexey Kardashevskiy
This creates a new AS object without any FlatView as memory_region_transaction_commit() may want to reuse the empty FV. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-14-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 67ace39b253ed5ae465275bc870f7e495547658b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Share FlatView's and dispatch trees between address spacesAlexey Kardashevskiy
This allows sharing flat views between address spaces (AS) when the same root memory region is used when creating a new address space. This is done by walking through all ASes and caching one FlatView per a physical root MR (i.e. not aliased). This removes search for duplicates from address_space_init_shareable() as FlatViews are shared elsewhere and keeping as::ref_count correct seems an unnecessary and useless complication. This should cause no change and memory use or boot time yet. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-13-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 967dc9b1194a9281124b2e1ce67b6c3359a2138f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Move address_space_update_ioeventfdsAlexey Kardashevskiy
So it is called (twice) from the same function. This is to make the next patches a bit simpler. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-12-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 02218487649558ed66c3689d4cc55250a42601d8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Alloc dispatch tree where topology is generaredAlexey Kardashevskiy
This is to make next patches simpler. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-11-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 9bf561e36cf8fed9565011a19ba9ea0100e1811e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Store physical root MR in FlatViewAlexey Kardashevskiy
Address spaces get to keep a root MR (alias or not) but FlatView stores the actual MR as this is going to be used later on to decide whether to share a particular FlatView or not. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-10-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 89c177bbdd6cf8e50b3fd4831697d50e195d6432) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Rename mem_begin/mem_commit/mem_add helpersAlexey Kardashevskiy
This renames some helpers to reflect better what they do. This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-9-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 8629d3fcb77e9775e44d9051bad0fb5187925eae) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Cleanup after switching to FlatViewAlexey Kardashevskiy
We store AddressSpaceDispatch* in FlatView anyway so there is no need to carry it from mem_add() to register_subpage/register_multipage. This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-8-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 9950322a593ff900a860fb52938159461798a831) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: Switch memory from using AddressSpace to FlatViewAlexey Kardashevskiy
FlatView's will be shared between AddressSpace's and subpage_t and MemoryRegionSection cannot store AS anymore, hence this change. In particular, for: typedef struct subpage_t { MemoryRegion iomem; - AddressSpace *as; + FlatView *fv; hwaddr base; uint16_t sub_section[]; } subpage_t; struct MemoryRegionSection { MemoryRegion *mr; - AddressSpace *address_space; + FlatView *fv; hwaddr offset_within_region; Int128 size; hwaddr offset_within_address_space; bool readonly; }; This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20170921085110.25598-7-aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 166206845f7fd75e720e6feea0bb01957c8da07f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
2017-12-04memory: avoid "resurrection" of dead FlatViewsPaolo Bonzini
It's possible for address_space_get_flatview() as it currently stands to cause a use-after-free for the returned FlatView, if the reference count is incremented after the FlatView has been replaced by a writer: thread 1 thread 2 RCU thread ------------------------------------------------------------- rcu_read_lock read as->current_map set as->current_map flatview_unref '--> call_rcu flatview_ref [ref=1] rcu_read_unlock flatview_destroy <badness> Since FlatViews are not updated very often, we can just detect the situation using a new atomic op atomic_fetch_inc_nonzero, similar to Linux's atomic_inc_not_zero, which performs the refcount increment only if it hasn't already hit zero. This is similar to Linux commit de09a9771a53 ("CRED: Fix get_task_cred() and task_state() to not resurrect dead credentials", 2010-07-29). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 447b0d0b9ee8a0ac216c3186e0f3c427a1001f0c) Conflicts: docs/devel/atomics.txt * drop documentation ref to atomic_fetch_xor * prereq for 166206845f Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-07 14:17:54 +0000