From: Glenn Miles <mil...@linux.ibm.com>
A problem was seen where uart interrupts would be lost resulting in the
console hanging. Traces showed that a lower priority interrupt was
preempting a higher priority interrupt, which would result in the higher
priority interrupt never being handled.
The new interrupt's priority was being compared against the CPPR
(Current Processor Priority Register) instead of the PIPR (Post
Interrupt Priority Register), as was required by the XIVE spec.
This allowed for a window between raising an interrupt and ACK'ing
the interrupt where a lower priority interrupt could slip in.
Fixes: 26c55b99418 ("ppc/xive2: Process group backlog when updating the CPPR")
Signed-off-by: Glenn Miles <mil...@linux.ibm.com>
Reviewed-by: Nicholas Piggin <npig...@gmail.com>
Reviewed-by: Michael Kowal <ko...@linux.ibm.com>
Reviewed-by: Caleb Schlossin <cal...@linux.ibm.com>
Tested-by: Gautam Menghani <gau...@linux.ibm.com>
Link:
https://lore.kernel.org/qemu-devel/20250512031100.439842-10-npig...@gmail.com
Signed-off-by: Cédric Le Goater <c...@redhat.com>
(cherry picked from commit 8d373176181fbc11f8d8eae2b4532b867f083ea6)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
diff --git a/hw/intc/xive2.c b/hw/intc/xive2.c
index 453fe37f18..2b4d0f51be 100644
--- a/hw/intc/xive2.c
+++ b/hw/intc/xive2.c
@@ -1283,7 +1283,7 @@ bool xive2_tm_irq_precluded(XiveTCTX *tctx, int ring,
uint8_t priority)
* priority to know if the thread can take the interrupt now or if
* it is precluded.
*/
- if (priority < alt_regs[TM_CPPR]) {
+ if (priority < alt_regs[TM_PIPR]) {
return false;
}
return true;
--
2.47.2
