summaryrefslogtreecommitdiffstats
path: root/arch/powerpc/kvm/book3s_hv_rmhandlers.S
diff options
context:
space:
mode:
authorPaul Mackerras2019-04-29 07:42:36 +0200
committerPaul Mackerras2019-04-30 11:29:23 +0200
commit1f80ba3d201e55ec204f93af372d09412ab42d76 (patch)
tree26d5a7247a74150f6555e8c35f31c54bcb113a41 /arch/powerpc/kvm/book3s_hv_rmhandlers.S
parentKVM: PPC: Book3S HV: smb->smp comment fixup (diff)
downloadkernel-qcow2-linux-1f80ba3d201e55ec204f93af372d09412ab42d76.tar.gz
kernel-qcow2-linux-1f80ba3d201e55ec204f93af372d09412ab42d76.tar.xz
kernel-qcow2-linux-1f80ba3d201e55ec204f93af372d09412ab42d76.zip
KVM: PPC: Book3S HV: Fix XICS-on-XIVE H_IPI when priority = 0
This fixes a bug in the XICS emulation on POWER9 machines which is triggered by the guest doing a H_IPI with priority = 0 (the highest priority). What happens is that the notification interrupt arrives at the destination at priority zero. The loop in scan_interrupts() sees that a priority 0 interrupt is pending, but because xc->mfrr is zero, we break out of the loop before taking the notification interrupt out of the queue and EOI-ing it. (This doesn't happen when xc->mfrr != 0; in that case we process the priority-0 notification interrupt on the first iteration of the loop, and then break out of a subsequent iteration of the loop with hirq == XICS_IPI.) To fix this, we move the prio >= xc->mfrr check down to near the end of the loop. However, there are then some other things that need to be adjusted. Since we are potentially handling the notification interrupt and also delivering an IPI to the guest in the same loop iteration, we need to update pending and handle any q->pending_count value before the xc->mfrr check, rather than at the end of the loop. Also, we need to update the queue pointers when we have processed and EOI-ed the notification interrupt, since we may not do it later. Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Diffstat (limited to 'arch/powerpc/kvm/book3s_hv_rmhandlers.S')
0 files changed, 0 insertions, 0 deletions