| df04d1f | Paolo Bonzini | 05 March 2018, 08:23:56 UTC | address_space_write: address_space_to_flatview needs RCU lock address_space_write is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock pair up from flatview_write to address_space_write. Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 4c6ebbb364aa6f42c5d8e83e932e967eb83f0e44) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:59 UTC |
| ac25a32 | Paolo Bonzini | 04 March 2018, 23:31:20 UTC | memory: inline some performance-sensitive accessors These accessors are called from inlined functions, and the call sequence is much more expensive than just inlining the access. Move the struct declaration to memory-internal.h so that exec.c and memory.c can both use an inline function. Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 785a507ec78bbda1c346f3d3593e5a58b62e73ef) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:59 UTC |
| 8e8b739 | Paolo Bonzini | 05 March 2018, 08:18:26 UTC | openpic_kvm: drop address_space_to_flatview call The MemoryListener is registered on address_space_memory, there is not much to assert. This currently works because the callback is invoked only once when the listener is registered, but section->fv is the _new_ FlatView, not the old one on later calls and that would break. This confines address_space_to_flatview to exec.c and memory.c. Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 80d2b933f9fe3e53d4f76a45a1bc1a0175669468) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:59 UTC |
| 4992118 | KONRAD Frederic | 02 March 2018, 09:59:25 UTC | sparc: fix leon3 casa instruction when MMU is disabled Since the commit af7a06bac7d3abb2da48ef3277d2a415772d2ae8: `casa [..](10), .., ..` (and probably others alternate space instructions) triggers a data access exception when the MMU is disabled. When we enter get_asi(...) dc->mem_idx is set to MMU_PHYS_IDX when the MMU is disabled. Just keep mem_idx unchanged in this case so we passthrough the MMU when it is disabled. Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (cherry picked from commit 6e10f37c86068e35151f982c976a85f1bec07ef2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| e1f5a04 | Max Filippov | 28 February 2018, 22:16:05 UTC | linux-user: fix target_mprotect/target_munmap error return values target_mprotect/target_munmap return value goes through get_errno at the call site, thus the functions must either set errno to host error code and return -1 or return negative guest error code. Do the latter. Cc: qemu-stable@nongnu.org Cc: Riku Voipio <riku.voipio@iki.fi> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20180228221609.11265-8-jcmvbkbc@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 78cf339039c325b336442f1d7f3ccc531b22c4a0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| 8fc971e | Max Filippov | 28 February 2018, 22:16:04 UTC | linux-user: fix assertion in shmdt shmdt fails to call mmap_lock/mmap_unlock around page_set_flags, resulting in the following assertion: page_set_flags: Assertion `have_mmap_lock()' failed. Wrap shmdt internals into mmap_lock/mmap_unlock. Cc: qemu-stable@nongnu.org Cc: Riku Voipio <riku.voipio@iki.fi> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20180228221609.11265-7-jcmvbkbc@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 3c5f6a5f888729f9fbc64211298f7c3e2fb42b64) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| 1801fab | Max Filippov | 07 March 2018, 21:50:10 UTC | linux-user: fix mmap/munmap/mprotect/mremap/shmat In linux-user QEMU that runs for a target with TARGET_ABI_BITS bigger than L1_MAP_ADDR_SPACE_BITS an assertion in page_set_flags fires when mmap, munmap, mprotect, mremap or shmat is called for an address outside the guest address space. mmap and mprotect should return ENOMEM in such case. Change definition of GUEST_ADDR_MAX to always be the last valid guest address. Account for this change in open_self_maps. Add macro guest_addr_valid that verifies if the guest address is valid. Add function guest_range_valid that verifies if address range is within guest address space and does not wrap around. Use that macro in mmap/munmap/mprotect/mremap/shmat for error checking. Cc: qemu-stable@nongnu.org Cc: Riku Voipio <riku.voipio@iki.fi> Cc: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20180307215010.30706-1-jcmvbkbc@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit ebf9a3630c911d0cfc9c20f7cafe9ba4f88cf583) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| 2ac8834 | Max Filippov | 28 February 2018, 19:48:04 UTC | target/xtensa: dump correct physical registers xtensa_cpu_dump_state outputs CPU physical registers as is, without synchronization from current window. That may result in different values printed for the current window and corresponding physical registers. Synchronize physical registers from window before dumping. Cc: qemu-stable@nongnu.org Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> (cherry picked from commit b55b1afda942306e4e40420aced1524bd83ba16d) Conflicts: target/xtensa/translate.c * drop context dependencies Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| 1f46379 | Mark Cave-Ayland | 23 February 2018, 11:10:17 UTC | loader: don't perform overlapping address check for memory region ROM images All memory region ROM images have a base address of 0 which causes the overlapping address check to fail if more than one memory region ROM image is present, or an existing ROM image is loaded at address 0. Make sure that we ignore the overlapping address check in rom_check_and_register_reset() if this is a memory region ROM image. In particular this fixes the "rom: requested regions overlap" error on startup when trying to run qemu-system-sparc with a -kernel image since commit 7497638642: "tcx: switch to load_image_mr() and remove prom_addr hack". Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (cherry picked from commit ca316c11526a1bc221fb542bdce6bac7238dde69) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| e2fc495 | Stefan Berger | 26 January 2018, 18:49:24 UTC | tpm: Set the flags of the CMD_INIT command to 0 The flags of the CMD_INIT control channel command were not initialized properly. Fix this and set to 0. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> (cherry picked from commit 302705876492a39f568035ce346e2c9176f5665e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| 4f81878 | Kevin Wolf | 16 February 2018, 18:14:55 UTC | rbd: Fix use after free in qemu_rbd_set_keypairs() error path If we want to include the invalid option name in the error message, we can't free the string earlier than that. Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> (cherry picked from commit 71c87815f9e0386b6f3e22942adc956fd603c82f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| 6f36bd3 | Alberto Garcia | 21 February 2018, 14:08:49 UTC | specs/qcow2: Fix documentation of the compressed cluster descriptor This patch fixes several mistakes in the documentation of the compressed cluster descriptor: 1) the documentation claims that the cluster descriptor contains the number of sectors used to store the compressed data, but what it actually contains is the number of sectors *minus one* or, in other words, the number of additional sectors after the first one. 2) the width of the fields is incorrectly specified. The number of bits used by each field is x = 62 - (cluster_bits - 8) for the offset field y = (cluster_bits - 8) for the size field So the offset field's location is [0, x-1], not [0, x] as stated. 3) the size field does not contain the size of the compressed data, but rather the number of sectors where that data is stored. The compressed data starts at the exact point specified in the offset field and ends when there's enough data to produce a cluster of decompressed data. Both points can be in the middle of a sector, allowing several compressed clusters to be stored next to one another, sharing sectors if necessary. Cc: qemu-stable@nongnu.org Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 156b46ded3853dfc6b34c5afae019ff61798491b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| 0430aa0 | Eric Blake | 15 February 2018, 03:29:05 UTC | nbd: Honor server's advertised minimum block size Commit 79ba8c98 (v2.7) changed the setting of request_alignment to occur only during bdrv_refresh_limits(), rather than at at bdrv_open() time; but at the time, NBD was unaffected, because it still used sector-based callbacks, so the block layer defaulted NBD to use 512 request_alignment. Later, commit 70c4fb26 (also v2.7) changed NBD to use byte-based callbacks, without setting request_alignment. This resulted in NBD using request_alignment of 1, which works great when the server supports it (as is the case for qemu-nbd), but falls apart miserably if the server requires alignment (but only if qemu actually sends a sub-sector request; qemu-io can do it, but most qemu operations still perform on sectors or larger). Even later, the NBD protocol was updated to document that clients should learn the server's minimum alignment during NBD_OPT_GO; and recommended that clients should assume a minimum size of 512 unless the server understands NBD_OPT_GO and replied with a smaller size. Commit 081dd1fe (v2.10) attempted to do that, by assigning request_alignment to whatever was learned from the server; but it has two flaws: the assignment is done during bdrv_open() so it gets unconditionally wiped out back to 1 during any later bdrv_refresh_limits(); and the code is not using a default of 512 when the server did not report a minimum size. Fix these issues by moving the assignment to request_alignment to the right function, and by using a sane default when the server does not advertise a minimum size. CC: qemu-stable@nongnu.org Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20180215032905.27146-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy<vsementsov@virtuozzo.com> (cherry picked from commit fd8d372dd36e839568a718684914d9960d8b1ebd) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:58 UTC |
| 327d464 | Greg Kurz | 20 June 2018, 12:54:15 UTC | spapr: make pseries-2.11 the default machine type The spapr capability framework was introduced in QEMU 2.12. It allows to have an explicit control on how host features are exposed to the guest. This is especially needed to handle migration between hetero- geneous hosts (eg, POWER8 to POWER9). It is also used to expose fixes/ workarounds against speculative execution vulnerabilities to guests. The framework was hence backported to QEMU 2.11.1, especially these commits: 0fac4aa93074 spapr: Add pseries-2.12 machine type 9070f408f491 spapr: Treat Hardware Transactional Memory (HTM) as an optional capability 0fac4aa93074 has the confusing effect of making pseries-2.12 the default machine type for QEMU 2.11.1, instead of the expected pseries-2.11. This patch changes the default machine back to pseries-2.11. Unfortunately, 9070f408f491 enforces the HTM capability for pseries-2.11 to be enabled by default, ie, when not passing cap-htm on the command line. This breaks several 'make check' testcases that run qemu-system-ppc64 with TCG. The only sane way to fix this is to adapt the impacted testcases so that they all pass cap-htm=off in this case. This patch does that as well. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 21 June 2018, 01:44:16 UTC |
| b940928 | Tiwei Bie | 25 January 2018, 07:12:43 UTC | virtio-balloon: unref the memory region before continuing Signed-off-by: Tiwei Bie <tiwei.bie@intel.com> Cc: qemu-stable@nongnu.org Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit b86107ab43b804e899a226fe287e34ab8acef596) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 20 June 2018, 20:20:44 UTC |
| c3c44a4 | Laszlo Ersek | 07 February 2018, 12:10:27 UTC | pci-bridge/i82801b11: clear bridge registers on platform reset The "i82801b11-bridge" device model is a descendant of "base-pci-bridge" (TYPE_PCI_BRIDGE). However, unlike other similar devices, such as - pci-bridge, - pcie-pci-bridge, - PCIE Root Port, - xio3130 switch upstream and downstream ports, - dec-21154-p2p-bridge, - pbm-bridge, - xilinx-pcie-root, "i82801b11-bridge" does not clear the bridge specific registers at platform reset. This is a problem because devices on "i82801b11-bridge" continue to respond to config space cycles after platform reset, when addressed with the bus number that was previously programmed into the secondary bus number register of "i82801b11-bridge". This error breaks OVMF's search for extra (PXB) root buses, for example. The device class reset method for "i82801b11-bridge" is currently NULL; set it directly to pci_bridge_reset(), like the last three bridge models in the above listing do. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: qemu-stable@nongnu.org Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1541839 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit ed247f40db84c8bd4bb7d10948702cd47cc4d5ae) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 20 June 2018, 20:20:44 UTC |
| 82c5191 | Murilo Opsfelder Araujo | 05 January 2018, 14:44:40 UTC | block/ssh: fix possible segmentation fault when .desc is not null-terminated This patch prevents a possible segmentation fault when .desc members are checked against NULL. The ssh_runtime_opts was added by commit 8a6a80896d6af03b8ee0c17cdf37219eca2588a7 ("block/ssh: Use QemuOpts for runtime options"). This fix was inspired by http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00883.html. Fixes: 8a6a80896d6af03b8ee0c17cdf37219eca2588a7 ("block/ssh: Use QemuOpts for runtime options") Cc: Max Reitz <mreitz@redhat.com> Cc: Eric Blake <eblake@redhat.com> Signed-off-by: Murilo Opsfelder Araujo <muriloo@linux.vnet.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Jeff Cody <jcody@redhat.com> (cherry picked from commit fbd5c4c0db47e578e3fdd88a0ebc4314a1ed3d42) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 20 June 2018, 20:20:44 UTC |
| 72cc467 | Greg Kurz | 27 February 2018, 15:22:58 UTC | spapr: register dummy ICPs later Some older machine types create more ICPs than needed. We hence need to register up to xics_max_server_number() dummy ICPs to accomodate the migration of these machine types. Recent VSMT rework changed xics_max_server_number() to return DIV_ROUND_UP(max_cpus * spapr->vsmt, smp_threads) instead of DIV_ROUND_UP(max_cpus * kvmppc_smt_threads(), smp_threads); The change is okay but it requires spapr->vsmt to be set, which isn't the case with the current code. This causes the formula to return zero and we don't create dummy ICPs. This breaks migration of older guests as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1549087 The dummy ICP workaround doesn't really have a dependency on XICS itself. But it does depend on proper VCPU id numbering and it must be applied before creating vCPUs (ie, creating real ICPs). So this patch moves the workaround to spapr_init_cpus(), which already assumes VSMT to be set. Fixes: 72194664c8a1 ("spapr: use spapr->vsmt to compute VCPU ids") Reported-by: Lukas Doktor <ldoktor@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 72fdd4de8e5fdc1a6078e000835fb54592a3fe97) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:59:00 UTC |
| 184da18 | Greg Kurz | 16 February 2018, 18:58:06 UTC | spapr: fix missing CPU core nodes in DT when running with TCG Commit 5d0fb1508e2d "spapr: consolidate the VCPU id numbering logic in a single place" introduced a helper to detect thread0 of a virtual core based on its VCPU id. This is used to create CPU core nodes in the DT, but it is broken in TCG. $ qemu-system-ppc64 -nographic -accel tcg -machine dumpdtb=dtb.bin \ -smp cores=16,maxcpus=16,threads=1 $ dtc -f -O dts dtb.bin | grep POWER8 PowerPC,POWER8@0 { PowerPC,POWER8@8 { instead of the expected 16 cores that we get with KVM: $ dtc -f -O dts dtb.bin | grep POWER8 PowerPC,POWER8@0 { PowerPC,POWER8@8 { PowerPC,POWER8@10 { PowerPC,POWER8@18 { PowerPC,POWER8@20 { PowerPC,POWER8@28 { PowerPC,POWER8@30 { PowerPC,POWER8@38 { PowerPC,POWER8@40 { PowerPC,POWER8@48 { PowerPC,POWER8@50 { PowerPC,POWER8@58 { PowerPC,POWER8@60 { PowerPC,POWER8@68 { PowerPC,POWER8@70 { PowerPC,POWER8@78 { This happens because spapr_get_vcpu_id() maps VCPU ids to cs->cpu_index in TCG mode. This confuses the code in spapr_is_thread0_in_vcore(), since it assumes thread0 VCPU ids to have a spapr->vsmt spacing. spapr_get_vcpu_id(cpu) % spapr->vsmt == 0 Actually, there's no real reason to expose cs->cpu_index instead of the VCPU id, since we also generate it with TCG. Also we already set it explicitly in spapr_set_vcpu_id(), so there's no real reason either to call kvm_arch_vcpu_id() with KVM. This patch unifies spapr_get_vcpu_id() to always return the computed VCPU id both in TCG and KVM. This is one step forward towards KVM<->TCG migration. Fixes: 5d0fb1508e2d Reported-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit b1a568c1c2192f090536b8ac76d135ce1f46a0ee) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:59:00 UTC |
| e676038 | Greg Kurz | 14 February 2018, 19:40:53 UTC | spapr: consolidate the VCPU id numbering logic in a single place Several places in the code need to calculate a VCPU id: (cpu_index / smp_threads) * spapr->vsmt + cpu_index % smp_threads (core_id / smp_threads) * spapr->vsmt (1 user) index * spapr->vsmt (2 users) or guess that the VCPU id of a given VCPU is the first thread of a virtual core: index % spapr->vsmt != 0 Even if the numbering logic isn't that complex, it is rather fragile to have these assumptions open-coded in several places. FWIW this was proved with recent issues related to VSMT. This patch moves the VCPU id formula to a single function to be called everywhere the code needs to compute one. It also adds an helper to guess if a VCPU is the first thread of a VCORE. Signed-off-by: Greg Kurz <groug@kaod.org> [dwg: Rename spapr_is_vcore() to spapr_is_thread0_in_vcore() for clarity] Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 5d0fb1508e2d279da74ef4a103e8def9b52c6304) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:59 UTC |
| 094706e | Greg Kurz | 14 February 2018, 19:40:44 UTC | spapr: rename spapr_vcpu_id() to spapr_get_vcpu_id() The spapr_vcpu_id() function is an accessor actually. Let's rename it for symmetry with the recently added spapr_set_vcpu_id() helper. The motivation behind this is that a later patch will consolidate the VCPU id formula in a function and spapr_vcpu_id looks like an appropriate name. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 14bb4486c819ea797a151b3e0fe53d6f5c7b3fc5) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:59 UTC |
| 8c0ec3c | David Gibson | 15 January 2018, 05:40:23 UTC | target/ppc: Clarify compat mode max_threads value We recently had some discussions that were sidetracked for a while, because nearly everyone misapprehended the purpose of the 'max_threads' field in the compatiblity modes table. It's all about guest expectations, not host expectations or support (that's handled elsewhere). In an attempt to avoid a repeat of that confusion, rename the field to 'max_vthreads' and add an explanatory comment. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> (cherry picked from commit abbc124753896f72e3715813ea20dd1924202ff0) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:59 UTC |
| a8074a5 | Greg Kurz | 14 February 2018, 19:40:35 UTC | spapr: move VCPU calculation to core machine code The VCPU ids are currently computed and assigned to each individual CPU threads in spapr_cpu_core_realize(). But the numbering logic of VCPU ids is actually a machine-level concept, and many places in hw/ppc/spapr.c also have to compute VCPU ids out of CPU indexes. The current formula used in spapr_cpu_core_realize() is: vcpu_id = (cc->core_id * spapr->vsmt / smp_threads) + i where: cc->core_id is a multiple of smp_threads cpu_index = cc->core_id + i 0 <= i < smp_threads So we have: cpu_index % smp_threads == i cc->core_id / smp_threads == cpu_index / smp_threads hence: vcpu_id = (cpu_index / smp_threads) * spapr->vsmt + cpu_index % smp_threads; This formula was used before VSMT at the time VCPU ids where computed at the target emulation level. It has the advantage of being useable to derive a VPCU id out of a CPU index only. It is fitted for all the places where the machine code has to compute a VCPU id. This patch introduces an accessor to set the VCPU id in a PowerPCCPU object using the above formula. It is a first step to consolidate all the VCPU id logic in a single place. Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 648edb64751ea0e550f36302fa66f9f11e480824) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:59 UTC |
| cc86c46 | Greg Kurz | 14 February 2018, 19:40:26 UTC | spapr: use spapr->vsmt to compute VCPU ids Since the introduction of VSMT in 2.11, the spacing of VCPU ids between cores is controllable through a machine property instead of being only dictated by the SMT mode of the host: cpu->vcpu_id = (cc->core_id * spapr->vsmt / smp_threads) + i Until recently, the machine code would try to change the SMT mode of the host to be equal to VSMT or exit. This allowed the rest of the code to assume that kvmppc_smt_threads() == spapr->vsmt is always true. Recent commit "8904e5a75005 spapr: Adjust default VSMT value for better migration compatibility" relaxed the rule. If the VSMT mode cannot be set in KVM for some reasons, but the requested CPU topology is compatible with the current SMT mode, then we let the guest run with kvmppc_smt_threads() != spapr->vsmt. This breaks quite a few places in the code, in particular when calculating DRC indexes. This is what happens on a POWER host with subcores-per-core=2 (ie, supports up to SMT4) when passing the following topology: -smp threads=4,maxcpus=16 \ -device host-spapr-cpu-core,core-id=4,id=core1 \ -device host-spapr-cpu-core,core-id=8,id=core2 qemu-system-ppc64: warning: Failed to set KVM's VSMT mode to 8 (errno -22) This is expected since KVM is limited to SMT4, but the guest is started anyway because this topology can run on SMT4 even with a VSMT8 spacing. But when we look at the DT, things get nastier: cpus { ... ibm,drc-indexes = <0x4 0x10000000 0x10000004 0x10000008 0x1000000c>; This means that we have the following association: CPU core device | DRC | VCPU id -----------------+------------+--------- boot core | 0x10000000 | 0 core1 | 0x10000004 | 4 core2 | 0x10000008 | 8 core3 | 0x1000000c | 12 But since the spacing of VCPU ids is 8, the DRC for core1 points to a VCPU that doesn't exist, the DRC for core2 points to the first VCPU of core1 and and so on... ... PowerPC,POWER8@0 { ... ibm,my-drc-index = <0x10000000>; ... }; PowerPC,POWER8@8 { ... ibm,my-drc-index = <0x10000008>; ... }; PowerPC,POWER8@10 { ... No ibm,my-drc-index property for this core since 0x10000010 doesn't exist in ibm,drc-indexes above. ... }; }; ... interrupt-controller { ... ibm,interrupt-server-ranges = <0x0 0x10>; With a spacing of 8, the highest VCPU id for the given topology should be: 16 * 8 / 4 = 32 and not 16 ... linux,phandle = <0x7e7323b8>; interrupt-controller; }; And CPU hot-plug/unplug is broken: (qemu) device_del core1 pseries-hotplug-cpu: Cannot find CPU (drc index 10000004) to remove (qemu) device_del core2 cpu 4 (hwid 8) Ready to die... cpu 5 (hwid 9) Ready to die... cpu 6 (hwid 10) Ready to die... cpu 7 (hwid 11) Ready to die... These are the VCPU ids of core1 actually (qemu) device_add host-spapr-cpu-core,core-id=12,id=core3 (qemu) device_del core3 pseries-hotplug-cpu: Cannot find CPU (drc index 1000000c) to remove This patches all the code in hw/ppc/spapr.c to assume the VSMT spacing when manipulating VCPU ids. Fixes: 8904e5a75005 Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 72194664c8a16b67865eb95054f984dd169cfa86) Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:59 UTC |
| c30b366 | Laurent Vivier | 09 February 2018, 08:18:58 UTC | spapr: set vsmt to MAX(8, smp_threads) We ignore silently the value of smp_threads when we set the default VSMT value, and if smp_threads is greater than VSMT kernel is going into trouble later. Fixes: 8904e5a750 ("spapr: Adjust default VSMT value for better migration compatibility") Signed-off-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 4ad64cbd0c3f9df15be5f7d1c920285551e802ca) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:59 UTC |
| af65bce | David Gibson | 15 January 2018, 06:51:33 UTC | spapr: Adjust default VSMT value for better migration compatibility fa98fbfc "PC: KVM: Support machine option to set VSMT mode" introduced the "vsmt" parameter for the pseries machine type, which controls the spacing of the vcpu ids of thread 0 for each virtual core. This was done to bring some consistency and stability to how that was done, while still allowing backwards compatibility for migration and otherwise. The default value we used for vsmt was set to the max of the host's advertised default number of threads and the number of vthreads per vcore in the guest. This was done to continue running without extra parameters on older KVM versions which don't allow the VSMT value to be changed. Unfortunately, even that smaller than before leakage of host configuration into guest visible configuration still breaks things. Specifically a guest with 4 (or less) vthread/vcore will get a different vsmt value when running on a POWER8 (vsmt==8) and POWER9 (vsmt==4) host. That means the vcpu ids don't line up so you can't migrate between them, though you should be able to. Long term we really want to make vsmt == smp_threads for sufficiently new machine types. However, that means that qemu will then require a sufficiently recent KVM (one which supports changing VSMT) - that's still not widely enough deployed to be really comfortable to do. In the meantime we need some default that will work as often as possible. This patch changes that default to 8 in all circumstances. This does change guest visible behaviour (including for existing machine versions) for many cases - just not the most common/important case. Following is case by case justification for why this is still the least worst option. Note that any of the old behaviours can still be duplicated after this patch, it's just that it requires manual intervention by setting the vsmt property on the command line. KVM HV on POWER8 host: This is the overwhelmingly common case in production setups, and is unchanged by design. POWER8 hosts will advertise a default VSMT mode of 8, and > 8 vthreads/vcore isn't permitted KVM HV on POWER7 host: Will break, but POWER7s allowing KVM were never released to the public. KVM HV on POWER9 host: Not yet released to the public, breaking this now will reduce other breakage later. KVM HV on PowerPC 970: Will theoretically break it, but it was barely supported to begin with and already required various user visible hacks to work. Also so old that I just don't care. TCG: This is the nastiest one; it means migration of TCG guests (without manual vsmt setting) will break. Since TCG is rarely used in production I think this is worth it for the other benefits. It does also remove one more barrier to TCG<->KVM migration which could be interesting for debugging applications. KVM PR: As with TCG, this will break migration of existing configurations, without adding extra manual vsmt options. As with TCG, it is rare in production so I think the benefits outweigh breakages. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 8904e5a75005fe579c28806003892d8ae4a27dfa) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:59 UTC |
| ad48411 | David Gibson | 16 January 2018, 04:37:37 UTC | spapr: Allow some cases where we can't set VSMT mode in the kernel At present if we require a vsmt mode that's not equal to the kernel's default, and the kernel doesn't let us change it (e.g. because it's an old kernel without support) then we always fail. But in fact we can cope with the kernel having a different vsmt as long as a) it's >= the actual number of vthreads/vcore (so that guest threads that are supposed to be on the same core act like it) b) it's a submultiple of the requested vsmt mode (so that guest threads spaced by the vsmt value will act like they're on different cores) Allowing this case gives us a bit more freedom to adjust the vsmt behaviour without breaking existing cases. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Tested-by: Greg Kurz <groug@kaod.org> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 1f20f2e0ee61d91abff4e86ed1cda1b5244647d3) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:59 UTC |
| 0a30cae | Gerd Hoffmann | 07 March 2018, 15:42:57 UTC | sdl: workaround bug in sdl 2.0.8 headers https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892087 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20180307154258.9313-1-kraxel@redhat.com (cherry picked from commit 2ca5c43091324a68772dc348cdf157c63888c168) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 10:58:05 UTC |
| 5892b5a | Paolo Bonzini | 28 November 2017, 10:51:27 UTC | memfd: fix configure test Recent glibc added memfd_create in sys/mman.h. This conflicts with the definition in util/memfd.c: /builddir/build/BUILD/qemu-2.11.0-rc1/util/memfd.c:40:12: error: static declaration of memfd_create follows non-static declaration Fix the configure test, and remove the sys/memfd.h inclusion since the file actually does not exist---it is a typo in the memfd_create(2) man page. Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 75e5b70e6b5dcc4f2219992d7cffa462aa406af0) Signed-off-by: Greg Kurz <groug@kaod.org> | 22 May 2018, 09:30:18 UTC |
| 7c1beb5 | Michael Roth | 14 February 2018, 20:41:05 UTC | Update version for 2.11.1 release Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 14 February 2018, 20:41:05 UTC |
| 00e9fba | Greg Kurz | 01 February 2018, 19:47:41 UTC | spapr: add missing break in h_get_cpu_characteristics() Detected by Coverity (CID 1385702). This fixes the recently added hypercall to let guests properly apply Spectre and Meltdown workarounds. Fixes: c59704b25473 "target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS" Reported-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit fa86f59234919b479b7e8da6b0dc2dad894a5eac) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 01:39:27 UTC |
| 63112b1 | linzhecheng | 11 January 2018, 13:27:24 UTC | vga: check the validation of memory addr when draw text Start a vm with qemu-kvm -enable-kvm -vnc :66 -smp 1 -m 1024 -hda redhat_5.11.qcow2 -device pcnet -vga cirrus, then use VNC client to connect to VM, and excute the code below in guest OS will lead to qemu crash: int main() { iopl(3); srand(time(NULL)); int a,b; while(1){ a = rand()%0x100; b = 0x3c0 + (rand()%0x20); outb(a,b); } return 0; } The above code is writing the registers of VGA randomly. We can write VGA CRT controller registers index 0x0C or 0x0D (which is the start address register) to modify the the display memory address of the upper left pixel or character of the screen. The address may be out of the range of vga ram. So we should check the validation of memory address when reading or writing it to avoid segfault. Signed-off-by: linzhecheng <linzhecheng@huawei.com> Message-id: 20180111132724.13744-1-linzhecheng@huawei.com Fixes: CVE-2018-5683 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 191f59dc17396bb5a8da50f8c59b6e0a430711a4) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 01:19:25 UTC |
| 30c3b48 | linzhecheng | 25 December 2017, 02:37:30 UTC | input: fix memory leak If kbd_queue is not empty and queue_count >= queue_limit, we should free evt. Change-Id: Ieeacf90d5e7e370a40452ec79031912d8b864d83 Signed-off-by: linzhecheng <linzhecheng@huawei.com> Message-id: 20171225023730.5512-1-linzhecheng@huawei.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit fca4774a96843ba9d32a5d5d1c3826e1478facae) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 01:19:15 UTC |
| 88ab853 | Daniel P. Berrangé | 01 February 2018, 15:58:41 UTC | ui: correctly advance output buffer when writing SASL data In this previous commit: commit 8f61f1c5a6bc06438a1172efa80bc7606594fa07 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Dec 18 19:12:20 2017 +0000 ui: track how much decoded data we consumed when doing SASL encoding I attempted to fix a flaw with tracking how much data had actually been processed when encoding with SASL. With that flaw, the VNC server could mistakenly discard queued data that had not been sent. The fix was not quite right though, because it merely decremented the vs->output.offset value. This is effectively discarding data from the end of the pending output buffer. We actually need to discard data from the start of the pending output buffer. We also want to free memory that is no longer required. The correct way to handle this is to use the buffer_advance() helper method instead of directly manipulating the offset value. Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20180201155841.27509-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 627ebec208a8809818589e17f4fce55a59420ad2) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:49 UTC |
| 64653b7 | Daniel P. Berrange | 18 January 2018, 15:52:54 UTC | ui: avoid sign extension using client width/height Pixman returns a signed int for the image width/height, but the VNC protocol only permits a unsigned int16. Effective framebuffer size is determined by the guest, limited by the video RAM size, so the dimensions are unlikely to exceed the range of an unsigned int16, but this is not currently validated. With the current use of 'int' for client width/height, the calculation of offsets in vnc_update_throttle_offset() suffers from integer size promotion and sign extension, causing coverity warnings *** CID 1385147: Integer handling issues (SIGN_EXTENSION) /ui/vnc.c: 979 in vnc_update_throttle_offset() 973 * than that the client would already suffering awful audio 974 * glitches, so dropping samples is no worse really). 975 */ 976 static void vnc_update_throttle_offset(VncState *vs) 977 { 978 size_t offset = >>> CID 1385147: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "vs->client_pf.bytes_per_pixel" with type "unsigned char" (8 bits, unsigned) is promoted in "vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 979 vs->client_width * vs->client_height * vs->client_pf.bytes_per_pixel; Change client_width / client_height to be a size_t to avoid sign extension and integer promotion. Then validate that dimensions are in range wrt the RFB protocol u16 limits. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20180118155254.17053-1-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 4c956bd81e2e16afd19d38d1fdeba6d9faa8a1ae) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:43 UTC |
| 9a26ca6 | Daniel P. Berrange | 18 December 2017, 19:12:28 UTC | ui: mix misleading comments & return types of VNC I/O helper methods While the QIOChannel APIs for reading/writing data return ssize_t, with negative value indicating an error, the VNC code passes this return value through the vnc_client_io_error() method. This detects the error condition, disconnects the client and returns 0 to indicate error. Thus all the VNC helper methods should return size_t (unsigned), and misleading comments which refer to the possibility of negative return values need fixing. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-14-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 30b80fd5269257f55203b7072c505b4ebaab5115) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:38 UTC |
| 172f4e5 | Daniel P. Berrange | 18 December 2017, 19:12:27 UTC | ui: add trace events related to VNC client throttling The VNC client throttling is quite subtle so will benefit from having trace points available for live debugging. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-13-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 6aa22a29187e1908f5db738d27c64a9efc8d0bfa) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:32 UTC |
| 0c85a40 | Daniel P. Berrange | 18 December 2017, 19:12:26 UTC | ui: place a hard cap on VNC server output buffer size The previous patches fix problems with throttling of forced framebuffer updates and audio data capture that would cause the QEMU output buffer size to grow without bound. Those fixes are graceful in that once the client catches up with reading data from the server, everything continues operating normally. There is some data which the server sends to the client that is impractical to throttle. Specifically there are various pseudo framebuffer update encodings to inform the client of things like desktop resizes, pointer changes, audio playback start/stop, LED state and so on. These generally only involve sending a very small amount of data to the client, but a malicious guest might be able to do things that trigger these changes at a very high rate. Throttling them is not practical as missed or delayed events would cause broken behaviour for the client. This patch thus takes a more forceful approach of setting an absolute upper bound on the amount of data we permit to be present in the output buffer at any time. The previous patch set a threshold for throttling the output buffer by allowing an amount of data equivalent to one complete framebuffer update and one seconds worth of audio data. On top of this it allowed for one further forced framebuffer update to be queued. To be conservative, we thus take that throttling threshold and multiply it by 5 to form an absolute upper bound. If this bound is hit during vnc_write() we forceably disconnect the client, refusing to queue further data. This limit is high enough that it should never be hit unless a malicious client is trying to exploit the sever, or the network is completely saturated preventing any sending of data on the socket. This completes the fix for CVE-2017-15124 started in the previous patches. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-12-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit f887cf165db20f405cb8805c716bd363aaadf815) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:26 UTC |
| f9e53c7 | Daniel P. Berrange | 18 December 2017, 19:12:25 UTC | ui: fix VNC client throttling when forced update is requested The VNC server must throttle data sent to the client to prevent the 'output' buffer size growing without bound, if the client stops reading data off the socket (either maliciously or due to stalled/slow network connection). The current throttling is very crude because it simply checks whether the output buffer offset is zero. This check is disabled if the client has requested a forced update, because we want to send these as soon as possible. As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM. They can first start something in the guest that triggers lots of framebuffer updates eg play a youtube video. Then repeatedly send full framebuffer update requests, but never read data back from the server. This can easily make QEMU's VNC server send buffer consume 100MB of RAM per second, until the OOM killer starts reaping processes (hopefully the rogue QEMU process, but it might pick others...). To address this we make the throttling more intelligent, so we can throttle full updates. When we get a forced update request, we keep track of exactly how much data we put on the output buffer. We will not process a subsequent forced update request until this data has been fully sent on the wire. We always allow one forced update request to be in flight, regardless of what data is queued for incremental updates or audio data. The slight complication is that we do not initially know how much data an update will send, as this is done in the background by the VNC job thread. So we must track the fact that the job thread has an update pending, and not process any further updates until this job is has been completed & put data on the output buffer. This unbounded memory growth affects all VNC server configurations supported by QEMU, with no workaround possible. The mitigating factor is that it can only be triggered by a client that has authenticated with the VNC server, and who is able to trigger a large quantity of framebuffer updates or audio samples from the guest OS. Mostly they'll just succeed in getting the OOM killer to kill their own QEMU process, but its possible other processes can get taken out as collateral damage. This is a more general variant of the similar unbounded memory usage flaw in the websockets server, that was previously assigned CVE-2017-15268, and fixed in 2.11 by: commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Oct 9 14:43:42 2017 +0100 io: monitor encoutput buffer size from websocket GSource This new general memory usage flaw has been assigned CVE-2017-15124, and is partially fixed by this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-11-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit ada8d2e4369ea49677d8672ac81bce73eefd5b54) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:21 UTC |
| f9c8767 | Daniel P. Berrange | 18 December 2017, 19:12:24 UTC | ui: fix VNC client throttling when audio capture is active The VNC server must throttle data sent to the client to prevent the 'output' buffer size growing without bound, if the client stops reading data off the socket (either maliciously or due to stalled/slow network connection). The current throttling is very crude because it simply checks whether the output buffer offset is zero. This check must be disabled if audio capture is enabled, because when streaming audio the output buffer offset will rarely be zero due to queued audio data, and so this would starve framebuffer updates. As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM. They can first start something in the guest that triggers lots of framebuffer updates eg play a youtube video. Then enable audio capture, and simply never read data back from the server. This can easily make QEMU's VNC server send buffer consume 100MB of RAM per second, until the OOM killer starts reaping processes (hopefully the rogue QEMU process, but it might pick others...). To address this we make the throttling more intelligent, so we can throttle when audio capture is active too. To determine how to throttle incremental updates or audio data, we calculate a size threshold. Normally the threshold is the approximate number of bytes associated with a single complete framebuffer update. ie width * height * bytes per pixel. We'll send incremental updates until we hit this threshold, at which point we'll stop sending updates until data has been written to the wire, causing the output buffer offset to fall back below the threshold. If audio capture is enabled, we increase the size of the threshold to also allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes per sample * frequency. This allows the output buffer to have a mixture of incremental framebuffer updates and audio data queued, but once the threshold is exceeded, audio data will be dropped and incremental updates will be throttled. This unbounded memory growth affects all VNC server configurations supported by QEMU, with no workaround possible. The mitigating factor is that it can only be triggered by a client that has authenticated with the VNC server, and who is able to trigger a large quantity of framebuffer updates or audio samples from the guest OS. Mostly they'll just succeed in getting the OOM killer to kill their own QEMU process, but its possible other processes can get taken out as collateral damage. This is a more general variant of the similar unbounded memory usage flaw in the websockets server, that was previously assigned CVE-2017-15268, and fixed in 2.11 by: commit a7b20a8efa28e5f22c26c06cd06c2f12bc863493 Author: Daniel P. Berrange <berrange@redhat.com> Date: Mon Oct 9 14:43:42 2017 +0100 io: monitor encoutput buffer size from websocket GSource This new general memory usage flaw has been assigned CVE-2017-15124, and is partially fixed by this patch. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-10-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit e2b72cb6e0443d90d7ab037858cb6834b6cca852) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:14 UTC |
| 5af9f25 | Daniel P. Berrange | 18 December 2017, 19:12:23 UTC | ui: refactor code for determining if an update should be sent to the client The logic for determining if it is possible to send an update to the client will become more complicated shortly, so pull it out into a separate method for easier extension later. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-9-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 0bad834228b9ee63e4239108d02dcb94568254d0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:09 UTC |
| 2e6571e | Daniel P. Berrange | 18 December 2017, 19:12:22 UTC | ui: correctly reset framebuffer update state after processing dirty regions According to the RFB protocol, a client sends one or more framebuffer update requests to the server. The server can reply with a single framebuffer update response, that covers all previously received requests. Once the client has read this update from the server, it may send further framebuffer update requests to monitor future changes. The client is free to delay sending the framebuffer update request if it needs to throttle the amount of data it is reading from the server. The QEMU VNC server, however, has never correctly handled the framebuffer update requests. Once QEMU has received an update request, it will continue to send client updates forever, even if the client hasn't asked for further updates. This prevents the client from throttling back data it gets from the server. This change fixes the flawed logic such that after a set of updates are sent out, QEMU waits for a further update request before sending more data. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-8-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 728a7ac95484a7ba5e624ccbac4c1326571576b0) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:34:04 UTC |
| 126617e | Daniel P. Berrange | 18 December 2017, 19:12:21 UTC | ui: introduce enum to track VNC client framebuffer update request state Currently the VNC servers tracks whether a client has requested an incremental or forced update with two boolean flags. There are only really 3 distinct states to track, so create an enum to more accurately reflect permitted states. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-7-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit fef1bbadfb2c3027208eb3d14b43e1bdb51166ca) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:33:55 UTC |
| 8a9c5c3 | Daniel P. Berrange | 18 December 2017, 19:12:20 UTC | ui: track how much decoded data we consumed when doing SASL encoding When we encode data for writing with SASL, we encode the entire pending output buffer. The subsequent write, however, may not be able to send the full encoded data in one go though, particularly with a slow network. So we delay setting the output buffer offset back to zero until all the SASL encoded data is sent. Between encoding the data and completing sending of the SASL encoded data, however, more data might have been placed on the pending output buffer. So it is not valid to set offset back to zero. Instead we must keep track of how much data we consumed during encoding and subtract only that amount. With the current bug we would be throwing away some pending data without having sent it at all. By sheer luck this did not previously cause any serious problem because appending data to the send buffer is always an atomic action, so we only ever throw away complete RFB protocol messages. In the case of frame buffer updates we'd catch up fairly quickly, so no obvious problem was visible. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-6-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 8f61f1c5a6bc06438a1172efa80bc7606594fa07) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:33:50 UTC |
| 616d64a | Daniel P. Berrange | 18 December 2017, 19:12:19 UTC | ui: avoid pointless VNC updates if framebuffer isn't dirty The vnc_update_client() method checks the 'has_dirty' flag to see if there are dirty regions that are pending to send to the client. Regardless of this flag, if a forced update is requested, updates must be sent. For unknown reasons though, the code also tries to sent updates if audio capture is enabled. This makes no sense as audio capture state does not impact framebuffer contents, so this check is removed. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-5-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 3541b08475d51bddf8aded36576a0ff5a547a978) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:33:39 UTC |
| a7b2537 | Daniel P. Berrange | 18 December 2017, 19:12:18 UTC | ui: remove redundant indentation in vnc_client_update Now that previous dead / unreachable code has been removed, we can simplify the indentation in the vnc_client_update method. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-4-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit b939eb89b6f320544a9328fa908d881d0024c1ee) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:33:33 UTC |
| de1e7a9 | Daniel P. Berrange | 18 December 2017, 19:12:17 UTC | ui: remove unreachable code in vnc_update_client A previous commit: commit 5a8be0f73d6f60ff08746377eb09ca459f39deab Author: Gerd Hoffmann <kraxel@redhat.com> Date: Wed Jul 13 12:21:20 2016 +0200 vnc: make sure we finish disconnect Added a check for vs->disconnecting at the very start of the vnc_update_client method. This means that the very next "if" statement check for !vs->disconnecting always evaluates true, and is thus redundant. This in turn means the vs->disconnecting check at the very end of the method never evaluates true, and is thus unreachable code. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-3-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit c53df961617736f94731d94b62c2954c261d2bae) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:33:28 UTC |
| 0181686 | Daniel P. Berrange | 18 December 2017, 19:12:16 UTC | ui: remove 'sync' parameter from vnc_update_client There is only one caller of vnc_update_client and that always passes false for the 'sync' parameter. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-id: 20171218191228.31018-2-berrange@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 6af998db05aec9af95a06f84ad94f1b96785e667) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 13 February 2018, 00:33:22 UTC |
| a3fd64f | Greg Kurz | 06 February 2018, 11:23:30 UTC | migration: incoming postcopy advise sanity checks If postcopy-ram was set on the source but not on the destination, migration doesn't occur, the destination prints an error and boots the guest: qemu-system-ppc64: Expected vmdescription section, but got 0 We end up with two running instances. This behaviour was introduced in 2.11 by commit 58110f0acb1a "migration: split common postcopy out of ram postcopy" to prepare ground for the upcoming dirty bitmap postcopy support. It adds a new case where the source may send an empty postcopy advise because dirty bitmap doesn't need to check page sizes like RAM postcopy does. If the source has enabled postcopy-ram, then it sends an advise with the page size values. If the destination hasn't enabled postcopy-ram, then loadvm_postcopy_handle_advise() leaves the page size values on the stream and returns. This confuses qemu_loadvm_state() later on and causes the destination to start execution. As discussed several times, postcopy-ram should be enabled both sides to be functional. This patch changes the destination to perform some extra checks on the advise length to ensure this is the case. Otherwise an error is returned and migration is aborted. Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <151791621042.19120.3103118434734245776.stgit@bahia> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 875fcd013ab68c64802998b22f54f0184479d21b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 12 February 2018, 15:28:28 UTC |
| 68d7e24 | Philippe Mathieu-Daudé | 05 December 2017, 17:00:13 UTC | target/sh4: add missing tcg_temp_free() in _decode_opc() missed in c55497ecb8c and 852d481faf7. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20171205170013.22337-3-f4bug@amsat.org> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> (cherry picked from commit e691e0ed135ac989221683ca9560c34d357edc57) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 12 February 2018, 03:06:46 UTC |
| 2095c5a | Daniel Henrique Barboza | 26 January 2018, 15:59:40 UTC | migration/savevm.c: set MAX_VM_CMD_PACKAGED_SIZE to 1ul << 32 MAX_VM_CMD_PACKAGED_SIZE is a constant used in qemu_savevm_send_packaged and loadvm_handle_cmd_packaged to determine whether a package is too big to be sent or received. qemu_savevm_send_packaged is called inside postcopy_start (migration/migration.c) to send the MigrationState in a single blob to the destination, using the MIG_CMD_PACKAGED subcommand, which will read it up using loadvm_handle_cmd_packaged. If the blob is larger than MAX_VM_CMD_PACKAGED_SIZE, an error is thrown and the postcopy migration is aborted. Both MAX_VM_CMD_PACKAGED_SIZE and MIG_CMD_PACKAGED were introduced by commit 11cf1d984b ("MIG_CMD_PACKAGED: Send a packaged chunk ..."). The constant has its original value of 1ul << 24 (16MB). The current MAX_VM_CMD_PACKAGED_SIZE value is not enough to support postcopy migration of bigger pseries guests. The blob size for a postcopy migration of a pseries guest with the following setup: qemu-system-ppc64 --nographic -vga none -machine pseries,accel=kvm -m 64G \ -smp 1,maxcpus=32 -device virtio-blk-pci,drive=rootdisk \ -drive file=f27.qcow2,if=none,cache=none,format=qcow2,id=rootdisk \ -netdev user,id=u1 -net nic,netdev=u1 Goes around 12MB. Bumping the RAM to 128G makes the blob sizes goes to 20MB. With 256G the blob goes to 37MB - more than twice the current maximum size. At this moment the pseries machine can handle guests with up to 1TB of RAM, making this postcopy blob goes to 128MB of size approximately. Following the discussions made in [1], there is a need to understand what devices are aggressively consuming the blob in that manner and see if that can be mitigated. Until then, we can set MAX_VM_CMD_PACKAGED_SIZE to the maximum value allowed. Since the size is a 32 bit int variable, we can set it as 1ul << 32, giving a maximum blob size of 4G that is enough to support postcopy migration of 32TB RAM guests given the above constraints. [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg06313.html Signed-off-by: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Reported-by: Balamuruhan S <bala24@linux.vnet.ibm.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit ee555cdf4d495ddd83633406e3099c5d1ef22e0a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 12 February 2018, 03:06:01 UTC |
| c8847f5 | Dr. David Alan Gilbert | 05 February 2018, 09:13:37 UTC | migration: Recover block devices if failure in device state In e91d895 I added the new pause-before-switchover mechanism to allow migration completion to be delayed; this changes the last state prior to completion to MIGRATE_STATUS_DEVICE rather than MIGRATE_STATUS_ACTIVE. Fix the failure path in migration_completion to recover the block devices if it fails in MIGRATE_STATUS_DEVICE, not just the MIGRATE_STATUS_ACTIVE that it previously had. This corresponds to rh bz: https://bugzilla.redhat.com/show_bug.cgi?id=1538494 whose symptom is an occasional source crash on a failed migration. Fixes: e91d8951d59d483f085f Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 6039dd5b1c45d76403b9dcadd2afd7efd8f42330) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 12 February 2018, 03:05:39 UTC |
| b9eec80 | Ross Lagerwall | 01 November 2017, 14:25:23 UTC | migration: Don't leak IO channels Since qemu_fopen_channel_{in,out}put take references on the underlying IO channels, make sure to release our references to them. Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Message-Id: <20171101142526.1006-2-ross.lagerwall@citrix.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 032b79f7173051e7f8742a43d106c7fc526856f9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 12 February 2018, 03:05:05 UTC |
| b8aa511 | Christian Borntraeger | 02 February 2018, 09:43:18 UTC | s390x/sclp: fix event mask handling commit 67915de9f038 ("s390x/event-facility: variable-length event masks") switched the sclp receive/send mask. This broke the sclp lm console. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Fixes: commit 67915de9f038 ("s390x/event-facility: variable-length event masks") Cc: Cornelia Huck <cohuck@redhat.com> Cc: Jason J. Herne <jjherne@linux.vnet.ibm.com> Cc: qemu-stable@nongnu.org Message-Id: <20180202094241.59537-1-borntraeger@de.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 869e676ae7c7ef678292652be8995a525e642bee) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 12 February 2018, 02:27:04 UTC |
| ab7b4f6 | linzhecheng | 14 January 2018, 12:55:19 UTC | memory: set ioeventfd_update_pending after address_space_update_ioeventfds We should set ioeventfd_update_pending same as memory_region_update_pending. Signed-off-by: linzhecheng <linzc@zju.edu.cn> Message-Id: <1515934519-16158-1-git-send-email-linzc@zju.edu.cn> Cc: qemu-stable@nongnu.org Fixes: ade9c1aac5292ff698fa550adebe794c37d86cc9 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 0b15209571e5eae706027f42da2ecd175eddc4e3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 12 February 2018, 02:24:14 UTC |
| ed8b4ec | Suraj Jitindar Singh | 19 January 2018, 05:00:05 UTC | target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS The new H-Call H_GET_CPU_CHARACTERISTICS is used by the guest to query behaviours and available characteristics of the cpu. Implement the handler for this new H-Call which formulates its response based on the setting of the spapr_caps cap-cfpc, cap-sbbc and cap-ibs. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit c59704b254734182c3202e0c261589ea2ccf485e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 01:07:38 UTC |
| eab4b51 | Suraj Jitindar Singh | 19 January 2018, 05:00:04 UTC | target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch Add new tristate cap cap-ibs to represent the indirect branch serialisation capability. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 4be8d4e7d935fc8919d61f53a0f0fb7230052bb3) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 01:07:38 UTC |
| d7aa3d0 | Suraj Jitindar Singh | 19 January 2018, 05:00:03 UTC | target/ppc/spapr_caps: Add new tristate cap safe_bounds_check Add new tristate cap cap-sbbc to represent the speculation barrier bounds checking capability. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 09114fd8179977e4157b36aab2e3d68eaf08adca) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 01:07:38 UTC |
| 3dc1227 | Suraj Jitindar Singh | 19 January 2018, 05:00:02 UTC | target/ppc/spapr_caps: Add new tristate cap safe_cache Add new tristate cap cap-cfpc to represent the cache flush on privilege change capability. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 8f38eaf8f9dd194c9961cf76c675724930ce4570) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 01:07:37 UTC |
| e9a8747 | Suraj Jitindar Singh | 19 January 2018, 05:00:01 UTC | target/ppc/spapr_caps: Add support for tristate spapr_capabilities spapr_caps are used to represent the level of support for various capabilities related to the spapr machine type. Currently there is only support for boolean capabilities. Add support for tristate capabilities by implementing their get/set functions. These capabilities can have the values 0, 1 or 2 corresponding to broken, workaround and fixed. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 6898aed77f4636c3e77af9c12631f583f22cb5db) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 01:07:37 UTC |
| 49b1fa3 | Suraj Jitindar Singh | 19 January 2018, 04:59:59 UTC | target/ppc/kvm: Add cap_ppc_safe_[cache/bounds_check/indirect_branch] Add three new kvm capabilities used to represent the level of host support for three corresponding workarounds. Host support for each of the capabilities is queried through the new ioctl KVM_PPC_GET_CPU_CHAR which returns four uint64 quantities. The first two, character and behaviour, represent the available characteristics of the cpu and the behaviour of the cpu respectively. The second two, c_mask and b_mask, represent the mask of known bits for the character and beheviour dwords respectively. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [dwg: Correct some compile errors due to name change in final kernel patch version] Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 8acc2ae5e91681ceda3ff4cf946ebf163f6012e9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 01:07:37 UTC |
| 43a29f0 | Suraj Jitindar Singh | 19 January 2018, 05:00:00 UTC | target/ppc/spapr_caps: Add macro to generate spapr_caps migration vmstate The vmstate description and the contained needed function for migration of spapr_caps is the same for each cap, with the name of the cap substituted. As such introduce a macro to allow for easier generation of these. Convert the three existing spapr_caps (htm, vsx, and dfp) to use this macro. Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 1f63ebaa91f73f469c8f107dbd266cabdbea3a40) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 01:07:37 UTC |
| d72e0a6 | Cédric Le Goater | 06 December 2017, 09:41:50 UTC | target/ppc: introduce the PPC_BIT() macro and use them in a couple of obvious places. Other macros will be used in the model of the XIVE interrupt controller. Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 2a83f9976efa9a85e8ceb9d1035a68f25c321334) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 01:07:37 UTC |
| 4374cbc | Greg Kurz | 17 January 2018, 09:20:42 UTC | spapr: fix device tree properties when using compatibility mode Commit 51f84465dd98 changed the compatility mode setting logic: - machine reset only sets compatibility mode for the boot CPU - compatibility mode is set for other CPUs when they are put online by the guest with the "start-cpu" RTAS call This causes a regression for machines started with max-compat-cpu: the device tree nodes related to secondary CPU cores contain wrong "cpu-version" and "ibm,pa-features" values, as shown below. Guest started on a POWER8 host with: -smp cores=2 -machine pseries,max-cpu-compat=compat7 ibm,pa-features = [18 00 f6 3f c7 c0 80 f0 80 00 00 00 00 00 00 00 00 00 80 00 80 00 80 00 00 00]; cpu-version = <0x4d0200>; ^^^ second CPU core ibm,pa-features = <0x600f63f 0xc70080c0>; cpu-version = <0xf000003>; ^^^ boot CPU core The second core is advertised in raw POWER8 mode. This happens because CAS assumes all CPUs to have the same compatibility mode. Since the boot CPU already has the requested compatibility mode, the CAS code does not set it for the secondary one, and exposes the bogus device tree properties in in the CAS response to the guest. A similar situation is observed when hot-plugging a CPU core. The related device tree properties are generated and exposed to guest with the "ibm,configure-connector" RTAS before "start-cpu" is called. The CPU core is advertised to the guest in raw mode as well. It both cases, it boils down to the fact that "start-cpu" happens too late. This can be fixed globally by propagating the compatibility mode of the boot CPU to the other CPUs during reset. For this to work, the compatibility mode of the boot CPU must be set before the machine code actually resets all CPUs. It is not needed to set the compatibility mode in "start-cpu" anymore, so the code is dropped. Fixes: 51f84465dd98 Signed-off-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 9012a53f067a78022947e18050b145c34a3dc599) Conflicts: hw/ppc/spapr_cpu_core.c hw/ppc/spapr_rtas.c * drop context dep on d6322252b32 Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:55:26 UTC |
| a1f33a5 | Jose Ricardo Ziviani | 14 January 2018, 19:23:48 UTC | ppc: Change Power9 compat table to support at most 8 threads/core Increases the max smt mode to 8 for Power9. That's because KVM supports smt emulation in this platform so QEMU should allow users to use it as well. Today if we try to pass -smp ...,threads=8, QEMU will silently truncate it to smt4 mode and may cause a crash if we try to perform a cpu hotplug. Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> [dwg: Added an explanatory comment] Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 03ee51d3548f5f553a3089f466483c1c6d5c666b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:55:26 UTC |
| 6a47136 | Suraj Jitindar Singh | 12 January 2018, 05:33:43 UTC | hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation Currently spapr_caps are tied to boolean values (on or off). This patch reworks the caps so that they can have any uint8 value. This allows more capabilities with various values to be represented in the same way internally. Capabilities are numbered in ascending order. The internal representation of capability values is an array of uint8s in the sPAPRMachineState, indexed by capability number. Capabilities can have their own name, description, options, getter and setter functions, type and allow functions. They also each have their own section in the migration stream. Capabilities are only migrated if they were explictly set on the command line, with the assumption that otherwise the default will match. On migration we ensure that the capability value on the destination is greater than or equal to the capability value from the source. So long at this remains the case then the migration is considered compatible and allowed to continue. This patch implements generic getter and setter functions for boolean capabilities. It also converts the existings cap-htm, cap-vsx and cap-dfp capabilities to this new format. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 4e5fe3688e23d61b45cc549ff1322aff8f50ef45) Conflicts: include/hw/ppc/spapr.h *drop context dep on 60c6823b9bc Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:54:33 UTC |
| e4f4fa0 | David Gibson | 11 December 2017, 06:34:30 UTC | spapr: Handle Decimal Floating Point (DFP) as an optional capability Decimal Floating Point has been available on POWER7 and later (server) cpus. However, it can be disabled on the hypervisor, meaning that it's not available to guests. We currently handle this by conditionally advertising DFP support in the device tree depending on whether the guest CPU model supports it - which can also depend on what's allowed in the host for -cpu host. That can lead to confusion on migration, since host properties are silently affecting guest visible properties. This patch handles it by treating it as an optional capability for the pseries machine type. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 2d1fb9bc8e6e78931d8e1bfeb0ed7a4d223b0480) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:53:54 UTC |
| ff6f7e1 | David Gibson | 07 December 2017, 06:08:47 UTC | spapr: Handle VMX/VSX presence as an spapr capability flag We currently have some conditionals in the spapr device tree code to decide whether or not to advertise the availability of the VMX (aka Altivec) and VSX vector extensions to the guest, based on whether the guest cpu has those features. This can lead to confusion and subtle failures on migration, since it makes a guest visible change based only on host capabilities. We now have a better mechanism for this, in spapr capabilities flags, which explicitly depend on user options rather than host capabilities. Rework the advertisement of VSX and VMX based on a new VSX capability. We no longer bother with a conditional for VMX support, because every CPU that's ever been supported by the pseries machine type supports VMX. NOTE: Some userspace distributions (e.g. RHEL7.4) already rely on availability of VSX in libc, so using cap-vsx=off may lead to a fatal SIGILL in init. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 2938664286499c0c30d6e455a7e2e5d3e6c3f63d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:53:46 UTC |
| 7c578cb | David Gibson | 11 December 2017, 06:41:34 UTC | target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM When constructing the "host" cpu class we modify whether the VMX and VSX vector extensions and DFP (Decimal Floating Point) are available based on whether KVM can support those instructions. This can depend on policy in the host kernel as well as on the actual host cpu capabilities. However, the way we probe for this is not very nice: we explicitly check the host's device tree. That works in practice, but it's not really correct, since the device tree is a property of the host kernel's platform which we don't really know about. We get away with it because the only modern POWER platforms happen to encode VMX, VSX and DFP availability in the device tree in the same way. Arguably we should have an explicit KVM capability for this, but we haven't needed one so far. Barring specific KVM policies which don't yet exist, each of these instruction classes will be available in the guest if and only if they're available in the qemu userspace process. We can determine that from the ELF AUX vector we're supplied with. Once reworked like this, there are no more callers for kvmppc_get_vmx() and kvmppc_get_dfp() so remove them. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 3f2ca480eb872b4946baf77f756236b637a5b15a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:53:42 UTC |
| 804e5ea | David Gibson | 11 December 2017, 04:09:37 UTC | spapr: Validate capabilities on migration Now that the "pseries" machine type implements optional capabilities (well, one so far) there's the possibility of having different capabilities available at either end of a migration. Although arguably a user error, it would be nice to catch this situation and fail as gracefully as we can. This adds code to migrate the capabilities flags. These aren't pulled directly into the destination's configuration since what the user has specified on the destination command line should take precedence. However, they are checked against the destination capabilities. If the source was using a capability which is absent on the destination, we fail the migration, since that could easily cause a guest crash or other bad behaviour. If the source lacked a capability which is present on the destination we warn, but allow the migration to proceed. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit be85537d654565e35e359a74b46fc08b7956525c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:53:31 UTC |
| 9070f40 | David Gibson | 11 December 2017, 02:10:44 UTC | spapr: Treat Hardware Transactional Memory (HTM) as an optional capability This adds an spapr capability bit for Hardware Transactional Memory. It is enabled by default for pseries-2.11 and earlier machine types. with POWER8 or later CPUs (as it must be, since earlier qemu versions would implicitly allow it). However it is disabled by default for the latest pseries-2.12 machine type. This means that with the latest machine type, HTM will not be available, regardless of CPU, unless it is explicitly enabled on the command line. That change is made on the basis that: * This way running with -M pseries,accel=tcg will start with whatever cpu and will provide the same guest visible model as with accel=kvm. - More specifically, this means existing make check tests don't have to be modified to use cap-htm=off in order to run with TCG * We hope to add a new "HTM without suspend" feature in the not too distant future which could work on both POWER8 and POWER9 cpus, and could be enabled by default. * Best guesses suggest that future POWER cpus may well only support the HTM-without-suspend model, not the (frankly, horribly overcomplicated) POWER8 style HTM with suspend. * Anecdotal evidence suggests problems with HTM being enabled when it wasn't wanted are more common than being missing when it was. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit ee76a09fc72cfbfab2bb5529320ef7e460adffd8) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:53:23 UTC |
| 78a38cd | David Gibson | 07 December 2017, 23:35:35 UTC | spapr: Capabilities infrastructure Because PAPR is a paravirtual environment access to certain CPU (or other) facilities can be blocked by the hypervisor. PAPR provides ways to advertise in the device tree whether or not those features are available to the guest. In some places we automatically determine whether to make a feature available based on whether our host can support it, in most cases this is based on limitations in the available KVM implementation. Although we correctly advertise this to the guest, it means that host factors might make changes to the guest visible environment which is bad: as well as generaly reducing reproducibility, it means that a migration between different host environments can easily go bad. We've mostly gotten away with it because the environments considered mature enough to be well supported (basically, KVM on POWER8) have had consistent feature availability. But, it's still not right and some limitations on POWER9 is going to make it more of an issue in future. This introduces an infrastructure for defining "sPAPR capabilities". These are set by default based on the machine version, masked by the capabilities of the chosen cpu, but can be overriden with machine properties. The intention is at reset time we verify that the requested capabilities can be supported on the host (considering TCG, KVM and/or host cpu limitations). If not we simply fail, rather than silently modifying the advertised featureset to the guest. This does mean that certain configurations that "worked" may now fail, but such configurations were already more subtly broken. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org> (cherry picked from commit 33face6b8981add8eba1f7cdaf4cf6cede415d2e) Conflicts: include/hw/ppc/spapr.h *drop context dep on 60c6823b9bc Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:52:49 UTC |
| 0fac4aa | David Gibson | 13 November 2017, 05:50:40 UTC | spapr: Add pseries-2.12 machine type While we're at it fix a couple of small errors in the 2.11 and 2.10 models (they didn't have any real effect, but don't quite match the template). Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 2b6154120cbd7f5514cefd3c6084d39922d26d88) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 06 February 2018, 00:52:01 UTC |
| 97d1755 | Laurent Vivier | 14 December 2017, 18:09:48 UTC | spapr: don't initialize PATB entry if max-cpu-compat < power9 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> | 05 February 2018, 05:38:26 UTC |
| 7e25155 | Peter Maydell | 30 January 2018, 13:17:19 UTC | linux-user/signal.c: Rename MC_* defines The SPARC code in linux-user/signal.c defines a set of MC_* constants. On some SPARC hosts these are also defined by sys/ucontext.h, resulting in build failures: linux-user/signal.c:2786:0: error: "MC_NGREG" redefined [-Werror] #define MC_NGREG 19 In file included from /usr/include/signal.h:302:0, from include/qemu/osdep.h:86, from linux-user/signal.c:19: /usr/include/sparc64-linux-gnu/sys/ucontext.h:59:0: note: this is the location of the previous definition # define MC_NGREG __MC_NGREG Rename all these constants to SPARC_MC_* to avoid the clash. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1517318239-15764-1-git-send-email-peter.maydell@linaro.org (cherry picked from commit 8ebb314b957403c1c9a3f1cf995f73c6ae9d5d10) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 01 February 2018, 21:22:33 UTC |
| 80277d7 | Greg Kurz | 26 January 2018, 22:25:24 UTC | spapr_pci: fix MSI/MSIX selection In various place we don't correctly check if the device supports MSI or MSI-X. This can cause devices to be advertised with MSI support, even if they only support MSI-X (like virtio-pci-* devices for example): ethernet@0 { ibm,req#msi = <0x1>; <--- wrong! . ibm,loc-code = "qemu_virtio-net-pci:0000:00:00.0"; . ibm,req#msi-x = <0x3>; }; Worse, this can also cause the "ibm,change-msi" RTAS call to corrupt the PCI status and cause migration to fail: qemu-system-ppc64: get_pci_config_device: Bad config data: i=0x6 read: 0 device: 10 cmask: 10 wmask: 0 w1cmask:0 ^^ PCI_STATUS_CAP_LIST bit which is assumed to be constant This patch changes spapr_populate_pci_child_dt() to properly check for MSI support using msi_present(): this ensures that PCIDevice::msi_cap was set by msi_init() and that msi_nr_vectors_allocated() will look at the right place in the config space. Checking PCIDevice::msix_entries_nr is enough for MSI-X but let's add a call to msix_present() there as well for consistency. It also changes rtas_ibm_change_msi() to select the appropriate MSI type in Function 1 instead of always selecting plain MSI. This new behaviour is compliant with LoPAPR 1.1, as described in "Table 71. ibm,change-msi Argument Call Buffer": Function 1: If Number Outputs is equal to 3, request to set to a new number of MSIs (including set to 0). If the “ibm,change-msix-capable” property exists and Number Outputs is equal to 4, request is to set to a new number of MSI or MSI-X (platform choice) interrupts (including set to 0). Since MSI is the the platform default (LoPAPR 6.2.3 MSI Option), let's check for MSI support first. And finally, it checks the input parameters are valid, as described in LoPAPR 1.1 "R1–7.3.10.5.1–3": For the MSI option: The platform must return a Status of -3 (Parameter error) from ibm,change-msi, with no change in interrupt assignments if the PCI configuration address does not support MSI and Function 3 was requested (that is, the “ibm,req#msi” property must exist for the PCI configuration address in order to use Function 3), or does not support MSI-X and Function 4 is requested (that is, the “ibm,req#msi-x” property must exist for the PCI configuration address in order to use Function 4), or if neither MSIs nor MSI-Xs are supported and Function 1 is requested. This ensures that the ret_intr_type variable contains a valid MSI type for this device, and that spapr_msi_setmsg() won't corrupt the PCI status. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 9cbe305b60cc49cfcd134765b85c28be95b1b57d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 01 February 2018, 21:21:29 UTC |
| 50c6998 | Fam Zheng | 17 January 2018, 00:52:22 UTC | usb-storage: Fix share-rw option parsing Because usb-storage creates an internal scsi device, we should propagate options. We already do so for bootindex etc, but failed to take care of share-rw. Fix it in an apparent way: add a new parameter to scsi_bus_legacy_add_drive and pass in s->conf.share_rw. Cc: qemu-stable@nongnu.org Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Message-id: 20180117005222.4781-1-famz@redhat.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> (cherry picked from commit 395b95395934785ca86baafd314d0c31b307d16d) Conflicts: hw/usb/dev-storage.c * dropped context dep on ceff3e1f01e Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 29 January 2018, 15:27:47 UTC |
| dccdaac | Fam Zheng | 26 December 2017, 06:53:00 UTC | osdep: Retry SETLK upon EINTR We could hit lock failure if there is a signal that makes fcntl return -1 and errno set to EINTR. In this case we should retry. Cc: qemu-stable@nongnu.org Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit f86428a1f4f91a460ed585682af70d3e8c31dc06) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 29 January 2018, 15:14:03 UTC |
| 5683983 | Christian Borntraeger | 18 January 2018, 08:56:28 UTC | s390x/kvm: provide stfle.81 stfle.81 (ppa15) is a transparent facility that can be passed to the guest without the need to implement hypervisor support. As this feature can be provided by firmware we add it to all full models. Cc: qemu-stable@nongnu.org Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20180118085628.40798-4-borntraeger@de.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.vnet.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 9f0d13f4f1de3cf9b70435cc4e87a301ee12471f) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 29 January 2018, 14:33:00 UTC |
| 4d79c0e | Christian Borntraeger | 18 January 2018, 08:56:27 UTC | s390x/kvm: Handle bpb feature We need to handle the bpb control on reset and migration. Normally stfle.82 is transparent (and the normal guest part works without hypervisor activity). To prevent any issues we require full host kernel support for this feature. Cc: qemu-stable@nongnu.org Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20180118085628.40798-3-borntraeger@de.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> [CH: 'Branch Prediction Blocking' -> 'Branch prediction blocking'] Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit b073c87517d4d348c7bac0f0b35e8e83e6354d82) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 29 January 2018, 14:32:50 UTC |
| 0981323 | Cornelia Huck | 22 January 2018, 10:07:47 UTC | linux-headers: update Update headers against 4.15-rc9. Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 9cbb636270b4df6f0a548e5c34b895330db5df8b) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 29 January 2018, 14:32:23 UTC |
| 61c8e67 | Eric Auger | 13 December 2017, 17:59:23 UTC | linux-headers: update to 4.15-rc1 Update headers against v4.15-rc1. Signed-off-by: Eric Auger <eric.auger@redhat.com> Message-id: 1511883692-11511-4-git-send-email-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit dd8739669f95b30653a3a05cb2e21da3f52894fa) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 29 January 2018, 14:32:18 UTC |
| e7857ad | Claudio Imbrenda | 18 January 2018, 17:51:44 UTC | s390x: fix storage attributes migration for non-small guests Fix storage attribute migration so that it does not fail for guests with more than a few GB of RAM. With such guests, the index in the buffer would go out of bounds, usually by large amounts, thus receiving -EFAULT from the kernel. Migration itself would be successful, but storage attributes would then not be migrated completely. This patch fixes the out of bounds access, and thus migration of all storage attributes when the guest have large amounts of memory. Cc: qemu-stable@nongnu.org Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com> Fixes: 903fd80b03243476 ("s390x/migration: Storage attributes device") Message-Id: <1516297904-18188-1-git-send-email-imbrenda@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com> (cherry picked from commit 46fa893355e0bd88f3c59b886f0d75cbd5f0bbbe) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 29 January 2018, 14:28:08 UTC |
| 9327a8e | Peter Maydell | 04 December 2017, 14:22:11 UTC | linux-user: Fix locking order in fork_start() Our locking order is that the tb lock should be taken inside the mmap_lock, but fork_start() grabs locks the other way around. This means that if a heavily multithreaded guest process (such as Java) calls fork() it can deadlock, with the thread that called fork() stuck in fork_start() with the tb lock and waiting for the mmap lock, but some other thread in tb_find() with the mmap lock and waiting for the tb lock. The cpu_list_lock() should also always be taken last, not first. Fix this by making fork_start() grab the locks in the right order. The order in which we drop locks doesn't matter, so we leave fork_end() the way it is. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-stable@nongnu.org Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <1512397331-15238-1-git-send-email-peter.maydell@linaro.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> (cherry picked from commit 024949caf32805f4cc3e7d363a80084b47aac1f6) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 29 January 2018, 14:27:35 UTC |
| 8ebfafa | Eduardo Habkost | 09 January 2018, 15:45:18 UTC | i386: Add EPYC-IBPB CPU model EPYC-IBPB is a copy of the EPYC CPU model with just CPUID_8000_0008_EBX_IBPB added. Cc: Jiri Denemark <jdenemar@redhat.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180109154519.25634-7-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 6cfbc54e8903a9bcc0346119949162d040c144c1) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 23:08:04 UTC |
| 61efbbf | Eduardo Habkost | 09 January 2018, 15:45:17 UTC | i386: Add new -IBRS versions of Intel CPU models The new MSR IA32_SPEC_CTRL MSR was introduced by a recent Intel microcode updated and can be used by OSes to mitigate CVE-2017-5715. Unfortunately we can't change the existing CPU models without breaking existing setups, so users need to explicitly update their VM configuration to use the new *-IBRS CPU model if they want to expose IBRS to guests. The new CPU models are simple copies of the existing CPU models, with just CPUID_7_0_EDX_SPEC_CTRL added and model_id updated. Cc: Jiri Denemark <jdenemar@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180109154519.25634-6-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit ac96c41354b7e4c70b756342d9b686e31ab87458) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 23:08:04 UTC |
| 1ade973 | Eduardo Habkost | 09 January 2018, 15:45:16 UTC | i386: Add FEAT_8000_0008_EBX CPUID feature word Add the new feature word and the "ibpb" feature flag. Based on a patch by Paolo Bonzini. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180109154519.25634-5-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 1b3420e1c4d523c49866cca4e7544753201cd43d) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 23:08:04 UTC |
| 803d42f | Eduardo Habkost | 09 January 2018, 15:45:15 UTC | i386: Add spec-ctrl CPUID bit Add the feature name and a CPUID_7_0_EDX_SPEC_CTRL macro. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180109154519.25634-4-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit a2381f0934432ef2cd47a335348ba8839632164c) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 23:08:04 UTC |
| cb2637a | Paolo Bonzini | 09 January 2018, 15:45:14 UTC | i386: Add support for SPEC_CTRL MSR Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180109154519.25634-3-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit a33a2cfe2f771b360b3422f6cdf566a560860bfc) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 23:08:04 UTC |
| 4b220d8 | Eduardo Habkost | 09 January 2018, 15:45:13 UTC | i386: Change X86CPUDefinition::model_id to const char* It is valid to have a 48-character model ID on CPUID, however the definition of X86CPUDefinition::model_id is char[48], which can make the compiler drop the null terminator from the string. If a CPU model happens to have 48 bytes on model_id, "-cpu help" will print garbage and the object_property_set_str() call at x86_cpu_load_def() will read data outside the model_id array. We could increase the array size to 49, but this would mean the compiler would not issue a warning if a 49-char string is used by mistake for model_id. To make things simpler, simply change model_id to be const char*, and validate the string length using an assert() on x86_register_cpudef_type(). Reported-by: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20180109154519.25634-2-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> (cherry picked from commit 807e9869b8c4119b81df902625af818519e01759) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 23:08:04 UTC |
| 1027f34 | Marcel Apfelbaum | 10 January 2018, 19:09:09 UTC | hw/pci-bridge: fix QEMU crash because of pcie-root-port If we try to use more pcie_root_ports then available slots and an IO hint is passed to the port, QEMU crashes because we try to init the "IO hint" capability even if the device is not created. Fix it by checking for error before adding the capability, so QEMU can fail gracefully. Signed-off-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit fced4d00e68e7559c73746d963265f7fd0b6abf9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 22:45:21 UTC |
| ccf82ae | Stefan Hajnoczi | 04 January 2018, 14:25:02 UTC | scsi-disk: release AioContext in unaligned WRITE SAME case scsi_write_same_complete() can retry the write if the request was unaligned. Make sure to release the AioContext when that code path is taken! This patch fixes a hang when QEMU terminates after an unaligned WRITE SAME request has been processed with dataplane. The hang occurs because iothread_stop_all() cannot acquire the AioContext lock that was leaked by the IOThread in scsi_write_same_complete(). Fixes: b9e413dd37 ("block: explicitly acquire aiocontext in aio callbacks that need it"). Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: qemu-stable@nongnu.org Reported-by: Cong Li <coli@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20180104142502.15175-1-stefanha@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 24355b79bdaf6ab12f7c610b032fc35ec045cd55) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 22:35:01 UTC |
| 1e14820 | Peter Maydell | 16 January 2018, 13:28:12 UTC | hw/sd/ssi-sd: Reset SD card on controller reset Since ssi-sd is still using the legacy SD card API, the SD card created by sd_init() is not plugged into any bus. This means that the controller has to reset it manually. Failing to do this mostly didn't affect the guest since the guest typically does a programmed SD card reset as part of its SD controller driver initialization, but meant that migration failed because it's only in sd_reset() that we set up the wpgrps_size field. In the case of sd-ssi, we have to implement an entire reset function since there wasn't one previously, and that requires a QOM cast macro that got omitted when this device was QOMified. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1515506513-31961-4-git-send-email-peter.maydell@linaro.org (cherry picked from commit 8046d44f3c9f67828d3368797d4d314433ee75e9) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 22:34:00 UTC |
| a22b809 | Peter Maydell | 16 January 2018, 13:28:12 UTC | hw/sd/milkymist-memcard: Reset SD card on controller reset Since milkymist-memcard is still using the legacy SD card API, the SD card created by sd_init() is not plugged into any bus. This means that the controller has to reset it manually. Failing to do this mostly didn't affect the guest since the guest typically does a programmed SD card reset as part of its SD controller driver initialization, but meant that migration failed because it's only in sd_reset() that we set up the wpgrps_size field. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1515506513-31961-3-git-send-email-peter.maydell@linaro.org (cherry picked from commit 16bf0e0e7aaa8efc0b8ee7e2aecb2fa235f82d38) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 22:33:50 UTC |
| 3f44190 | Peter Maydell | 16 January 2018, 13:28:11 UTC | hw/sd/pl181: Reset SD card on controller reset Since pl181 is still using the legacy SD card API, the SD card created by sd_init() is not plugged into any bus. This means that the controller has to reset it manually. Failing to do this mostly didn't affect the guest since the guest typically does a programmed SD card reset as part of its SD controller driver initialization, but meant that migration failed because it's only in sd_reset() that we set up the wpgrps_size field. Cc: qemu-stable@nongnu.org Fixes: https://bugs.launchpad.net/qemu/+bug/1739378 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 1515506513-31961-2-git-send-email-peter.maydell@linaro.org (cherry picked from commit 0cb57cc701839e7358918d5f2922ccbc04d28d17) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 22:33:39 UTC |
| 88bf4a7 | Jay Zhou | 12 January 2018, 02:47:57 UTC | vhost: remove assertion to prevent crash QEMU will assert on vhost-user backed virtio device hotplug if QEMU is using more RAM regions than VHOST_MEMORY_MAX_NREGIONS (for example if it were started with a lot of DIMM devices). Fix it by returning error instead of asserting and let callers of vhost_set_mem_table() handle error condition gracefully. Cc: qemu-stable@nongnu.org Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jay Zhou <jianjay.zhou@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit f4bf56fb78ed0e9f60fa1ed656c14ff4c494da5a) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 23 January 2018, 22:30:56 UTC |
| f793121 | Michael S. Tsirkin | 13 December 2017, 19:59:54 UTC | virtio_error: don't invoke status callbacks Backends don't need to know what frontend requested a reset, and notifying then from virtio_error is messy because virtio_error itself might be invoked from backend. Let's just set the status directly. Cc: qemu-stable@nongnu.org Reported-by: Ilya Maximets <i.maximets@samsung.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 8fc47c876de638353bb635872f2c25bb7f4a3d6e) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 16 January 2018, 00:18:05 UTC |
| 0af294d | Peter Maydell | 11 January 2018, 13:25:40 UTC | hw/intc/arm_gic: reserved register addresses are RAZ/WI The GICv2 specification says that reserved register addresses must RAZ/WI; now that we implement external abort handling for Arm CPUs this means we must return MEMTX_OK rather than MEMTX_ERROR, to avoid generating a spurious guest data abort. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1513183941-24300-3-git-send-email-peter.maydell@linaro.org Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> (cherry picked from commit 0cf09852015e47a5fbb974ff7ac320366afd21ee) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 11 January 2018, 21:10:57 UTC |
| 6242535 | Peter Maydell | 11 January 2018, 13:25:40 UTC | hw/intc/arm_gicv3: Make reserved register addresses RAZ/WI The GICv3 specification says that reserved register addresses should RAZ/WI. This means we need to return MEMTX_OK, not MEMTX_ERROR, because now that we support generating external aborts the latter will cause an abort on new board models. Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1513183941-24300-2-git-send-email-peter.maydell@linaro.org Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> (cherry picked from commit f1945632b43e36bd9f3e0c2feb0e5b152be7ed91) Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> | 11 January 2018, 21:10:48 UTC |
| d6f1448 | Alex Williamson | 13 December 2017, 17:19:32 UTC | vfio: Fix vfio-kvm group registration 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> | 09 January 2018, 17:09:36 UTC |
