diff options
author | Greg Kurz <groug@kaod.org> | 2019-12-04 20:43:37 +0100 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2019-12-17 10:39:48 +1100 |
commit | 401774387aeb37f2ada9bb18f7c7e307b21a3e93 (patch) | |
tree | 10eeb3201b37d8ef14a4bb72aa26e541fef0620d /hw/cpu | |
parent | d1d32d6255a395eb071c10aeffb932a3485bdfcd (diff) | |
download | qemu-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/cpu')
0 files changed, 0 insertions, 0 deletions