mirror of
https://github.com/qemu/qemu.git
synced 2024-12-14 23:13:29 +08:00
d1c2e3ce3d
There is a reliable way to make a CPU hotunplug fail in the pseries machine. Hotplug a CPU A, then offline all other CPUs inside the guest but A. When trying to hotunplug A the guest kernel will refuse to do it, because A is now the last online CPU of the guest. PAPR has no 'error callback' in this situation to report back to the platform, so the guest kernel will deny the unplug in silent and QEMU will never know what happened. The unplug pending state of A will remain until the guest is shutdown or rebooted. Previous attempts of fixing it (see [1] and [2]) were aimed at trying to mitigate the effects of the problem. In [1] we were trying to guess which guest CPUs were online to forbid hotunplug of the last online CPU in the QEMU layer, avoiding the scenario described above because QEMU is now failing in behalf of the guest. This is not robust because the last online CPU of the guest can change while we're in the middle of the unplug process, and our initial assumptions are now invalid. In [2] we were accepting that our unplug process is uncertain and the user should be allowed to spam the IRQ hotunplug queue of the guest in case the CPU hotunplug fails. This patch presents another alternative, using the timeout infrastructure introduced in the previous patch. CPU hotunplugs in the pSeries machine will now timeout after 15 seconds. This is a long time for a single CPU unplug to occur, regardless of guest load - although the user is *strongly* encouraged to *not* hotunplug devices from a guest under high load - and we can be sure that something went wrong if it takes longer than that for the guest to release the CPU (the same can't be said about memory hotunplug - more on that in the next patch). Timing out the unplug operation will reset the unplug state of the CPU and allow the user to try it again, regardless of the error situation that prevented the hotunplug to occur. Of all the not so pretty fixes/mitigations for CPU hotunplug errors in pSeries, timing out the operation is an admission that we have no control in the process, and must assume the worst case if the operation doesn't succeed in a sensible time frame. [1] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg03353.html [2] https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg04400.html Reported-by: Xujun Ma <xuma@redhat.com> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1911414 Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20210222194531.62717-5-danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au> |
||
|---|---|---|
| .. | ||
| e500-ccsr.h | ||
| e500.c | ||
| e500.h | ||
| e500plat.c | ||
| fdt.c | ||
| fw_cfg.c | ||
| Kconfig | ||
| mac_newworld.c | ||
| mac_oldworld.c | ||
| mac.h | ||
| meson.build | ||
| mpc8544_guts.c | ||
| mpc8544ds.c | ||
| pef.c | ||
| pnv_bmc.c | ||
| pnv_core.c | ||
| pnv_homer.c | ||
| pnv_lpc.c | ||
| pnv_occ.c | ||
| pnv_pnor.c | ||
| pnv_psi.c | ||
| pnv_xscom.c | ||
| pnv.c | ||
| ppc4xx_devs.c | ||
| ppc4xx_pci.c | ||
| ppc405_boards.c | ||
| ppc405_uc.c | ||
| ppc405.h | ||
| ppc440_bamboo.c | ||
| ppc440_pcix.c | ||
| ppc440_uc.c | ||
| ppc440.h | ||
| ppc_booke.c | ||
| ppc.c | ||
| ppce500_spin.c | ||
| prep_systemio.c | ||
| prep.c | ||
| rs6000_mc.c | ||
| sam460ex.c | ||
| spapr_caps.c | ||
| spapr_cpu_core.c | ||
| spapr_drc.c | ||
| spapr_events.c | ||
| spapr_hcall.c | ||
| spapr_iommu.c | ||
| spapr_irq.c | ||
| spapr_numa.c | ||
| spapr_nvdimm.c | ||
| spapr_ovec.c | ||
| spapr_pci_nvlink2.c | ||
| spapr_pci_vfio.c | ||
| spapr_pci.c | ||
| spapr_rng.c | ||
| spapr_rtas_ddw.c | ||
| spapr_rtas.c | ||
| spapr_rtc.c | ||
| spapr_tpm_proxy.c | ||
| spapr_vio.c | ||
| spapr.c | ||
| trace-events | ||
| trace.h | ||
| virtex_ml507.c | ||