- 21 6月, 2018 29 次提交
-
-
由 Kevin Wolf 提交于
I couldn't find a case where this prevents something bad from happening that isn't already caught by other checks, but let's err on the safe side and check that mh_header_addr is as expected. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit dbf2dce7) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Kevin Wolf 提交于
The code path where mh_load_end_addr is non-zero in the Multiboot header checks that mh_load_end_addr >= mh_load_addr and so mb_load_size is checked. However, mb_load_size is not checked when calculated from the file size, when mh_load_end_addr is 0. If the kernel binary size is larger than can fit in the address space after load_addr, we ended up with a kernel_size that is smaller than load_size, which means that we read the file into a too small buffer. Add a check to reject kernel files with such Multiboot headers. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NJack Schwartz <jack.schwartz@oracle.com> (cherry picked from commit b17a9054) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jack Schwartz 提交于
Change all fprintf(stderr...) calls in hw/i386/multiboot.c to call error_report() instead, including the mb_debug macro. Remove the "\n" from strings passed to all modified calls, since error_report() appends one. Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 4b9006a4) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jack Schwartz 提交于
Refer to field names when displaying fields in printf and debug statements. Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit ce5eb6dc) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jack Schwartz 提交于
Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com> Reviewed-by: NPrasad J Pandit <pjp@fedoraproject.org> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 7a2e43cc) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Jack Schwartz 提交于
The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/), section 3.1.3, allows for bss_end_addr to be zero. A zero bss_end_addr signifies there is no .bss section. Suggested-by: NDaniel Kiper <daniel.kiper@oracle.com> Signed-off-by: NJack Schwartz <jack.schwartz@oracle.com> Reviewed-by: NDaniel Kiper <daniel.kiper@oracle.com> Reviewed-by: NPrasad J Pandit <pjp@fedoraproject.org> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 2a8fcd11) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Peter Lieven 提交于
Reset the dirty bitmap before reading to make sure we don't miss any new data. Cc: qemu-stable@nongnu.org Signed-off-by: NPeter Lieven <pl@kamp.de> Message-Id: <1520507908-16743-3-git-send-email-pl@kamp.de> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> (cherry picked from commit 86b124bc) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
Fixes: 11e732a5Reported-by: NCornelia Huck <cohuck@redhat.com> Reported-by: Nluigi burdo <intermediadc@hotmail.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Tested-by: NCornelia Huck <cohuck@redhat.com> Tested-by: NThomas Huth <thuth@redhat.com> Message-id: 20180307130238.19358-1-pbonzini@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> (cherry picked from commit b39b61e4) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
address_space_rw is calling address_space_to_flatview but it can be called outside the RCU lock. To fix it, transform flatview_rw into address_space_rw, since flatview_rw is otherwise unused. Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit db84fd97) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
address_space_map is calling address_space_to_flatview but it can be called outside the RCU lock. The function itself is calling rcu_read_lock/rcu_read_unlock, just in the wrong place, so the fix is easy. Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit ad0c60fa) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
address_space_access_valid 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_access_valid to address_space_access_valid. Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 11e732a5) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
address_space_read 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_read_full to address_space_read's constant size fast path and address_space_read_full. Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b2a44fca) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
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: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 4c6ebbb3) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
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: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 785a507e) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
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: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NAlexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 80d2b933) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 KONRAD Frederic 提交于
Since the commit af7a06ba: `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: NKONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (cherry picked from commit 6e10f37c) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Filippov 提交于
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: NMax Filippov <jcmvbkbc@gmail.com> Reviewed-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20180228221609.11265-8-jcmvbkbc@gmail.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu> (cherry picked from commit 78cf3390) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Filippov 提交于
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: NMax Filippov <jcmvbkbc@gmail.com> Reviewed-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20180228221609.11265-7-jcmvbkbc@gmail.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu> (cherry picked from commit 3c5f6a5f) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Filippov 提交于
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: NMax Filippov <jcmvbkbc@gmail.com> Reviewed-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20180307215010.30706-1-jcmvbkbc@gmail.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu> (cherry picked from commit ebf9a363) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Max Filippov 提交于
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: NMax Filippov <jcmvbkbc@gmail.com> (cherry picked from commit b55b1afd) Conflicts: target/xtensa/translate.c * drop context dependencies Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Mark Cave-Ayland 提交于
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 74976386: "tcx: switch to load_image_mr() and remove prom_addr hack". Suggested-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NMark Cave-Ayland <mark.cave-ayland@ilande.co.uk> (cherry picked from commit ca316c11) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Stefan Berger 提交于
The flags of the CMD_INIT control channel command were not initialized properly. Fix this and set to 0. Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com> (cherry picked from commit 30270587) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Kevin Wolf 提交于
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: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 71c87815) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Alberto Garcia 提交于
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: NAlberto Garcia <berto@igalia.com> Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com> (cherry picked from commit 156b46de) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
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: NEric Blake <eblake@redhat.com> Message-Id: <20180215032905.27146-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy<vsementsov@virtuozzo.com> (cherry picked from commit fd8d372d) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Greg Kurz 提交于
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: 0fac4aa9 spapr: Add pseries-2.12 machine type 9070f408 spapr: Treat Hardware Transactional Memory (HTM) as an optional capability 0fac4aa9 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, 9070f408 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: NGreg Kurz <groug@kaod.org> Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au> Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Tiwei Bie 提交于
Signed-off-by: NTiwei Bie <tiwei.bie@intel.com> Cc: qemu-stable@nongnu.org Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> (cherry picked from commit b86107ab) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Laszlo Ersek 提交于
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=1541839Signed-off-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> (cherry picked from commit ed247f40) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
由 Murilo Opsfelder Araujo 提交于
This patch prevents a possible segmentation fault when .desc members are checked against NULL. The ssh_runtime_opts was added by commit 8a6a8089 ("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: 8a6a8089 ("block/ssh: Use QemuOpts for runtime options") Cc: Max Reitz <mreitz@redhat.com> Cc: Eric Blake <eblake@redhat.com> Signed-off-by: NMurilo Opsfelder Araujo <muriloo@linux.vnet.ibm.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NJeff Cody <jcody@redhat.com> Signed-off-by: NJeff Cody <jcody@redhat.com> (cherry picked from commit fbd5c4c0) Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
-
- 22 5月, 2018 11 次提交
-
-
由 Greg Kurz 提交于
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: 72194664 ("spapr: use spapr->vsmt to compute VCPU ids") Reported-by: NLukas Doktor <ldoktor@redhat.com> Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 72fdd4de) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
Commit 5d0fb150 "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: 5d0fb150Reported-by: NCédric Le Goater <clg@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit b1a568c1) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
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: NGreg Kurz <groug@kaod.org> [dwg: Rename spapr_is_vcore() to spapr_is_thread0_in_vcore() for clarity] Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 5d0fb150) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
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: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 14bb4486) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
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: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NJose Ricardo Ziviani <joserz@linux.vnet.ibm.com> (cherry picked from commit abbc1247) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
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: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 648edb64) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Greg Kurz 提交于
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 "8904e5a7 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: 8904e5a7Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 72194664) Signed-off-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Laurent Vivier 提交于
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: 8904e5a7 ("spapr: Adjust default VSMT value for better migration compatibility") Signed-off-by: NLaurent Vivier <lvivier@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> (cherry picked from commit 4ad64cbd) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
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: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Reviewed-by: NJose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Reviewed-by: NGreg Kurz <groug@kaod.org> (cherry picked from commit 8904e5a7) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 David Gibson 提交于
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: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NLaurent Vivier <lvivier@redhat.com> Tested-by: NGreg Kurz <groug@kaod.org> Reviewed-by: NGreg Kurz <groug@kaod.org> (cherry picked from commit 1f20f2e0) Signed-off-by: NGreg Kurz <groug@kaod.org>
-
由 Gerd Hoffmann 提交于
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892087Signed-off-by: NGerd Hoffmann <kraxel@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com> Message-id: 20180307154258.9313-1-kraxel@redhat.com (cherry picked from commit 2ca5c430) Signed-off-by: NGreg Kurz <groug@kaod.org>
-