]> asedeno.scripts.mit.edu Git - linux.git/commit
KVM: PPC: Book3S HV: Fix XICS-on-XIVE H_IPI when priority = 0
authorPaul Mackerras <paulus@ozlabs.org>
Mon, 29 Apr 2019 05:42:36 +0000 (15:42 +1000)
committerPaul Mackerras <paulus@ozlabs.org>
Tue, 30 Apr 2019 09:29:23 +0000 (19:29 +1000)
commit1f80ba3d201e55ec204f93af372d09412ab42d76
tree26d5a7247a74150f6555e8c35f31c54bcb113a41
parent6fabc9f20c5eddaa3193b85ce56c37a989d01065
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>
arch/powerpc/kvm/book3s_xive_template.c