aboutsummaryrefslogtreecommitdiff
path: root/hw/arm
diff options
context:
space:
mode:
authorGreg Kurz <groug@kaod.org>2019-12-04 20:43:37 +0100
committerDavid Gibson <david@gibson.dropbear.id.au>2019-12-17 10:39:48 +1100
commit401774387aeb37f2ada9bb18f7c7e307b21a3e93 (patch)
tree10eeb3201b37d8ef14a4bb72aa26e541fef0620d /hw/arm
parentd1d32d6255a395eb071c10aeffb932a3485bdfcd (diff)
downloadqemu-401774387aeb37f2ada9bb18f7c7e307b21a3e93.zip
qemu-401774387aeb37f2ada9bb18f7c7e307b21a3e93.tar.gz
qemu-401774387aeb37f2ada9bb18f7c7e307b21a3e93.tar.bz2
ppc: Deassert the external interrupt pin in KVM on reset
When a CPU is reset, QEMU makes sure no interrupt is pending by clearing CPUPPCstate::pending_interrupts in ppc_cpu_reset(). In the case of a complete machine emulation, eg. a sPAPR machine, an external interrupt request could still be pending in KVM though, eg. an IPI. It will be eventually presented to the guest, which is supposed to acknowledge it at the interrupt controller. If the interrupt controller is emulated in QEMU, either XICS or XIVE, ppc_set_irq() won't deassert the external interrupt pin in KVM since it isn't pending anymore for QEMU. When the vCPU re-enters the guest, the interrupt request is still pending and the vCPU will try again to acknowledge it. This causes an infinite loop and eventually hangs the guest. The code has been broken since the beginning. The issue wasn't hit before because accel=kvm,kernel-irqchip=off is an awkward setup that never got used until recently with the LC92x IBM systems (aka, Boston). Add a ppc_irq_reset() function to do the necessary cleanup, ie. deassert the IRQ pins of the CPU in QEMU and most importantly the external interrupt pin for this vCPU in KVM. Reported-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <157548861740.3650476.16879693165328764758.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'hw/arm')
0 files changed, 0 insertions, 0 deletions