Matheus Ferst <matheus.ferst@eldorado.org.br> writes:
Move the interrupt masking logic to a new method, ppc_pending_interrupt,
and only handle the interrupt processing in ppc_hw_interrupt.
Signed-off-by: Matheus Ferst <matheus.ferst@eldorado.org.br>
---
target/ppc/excp_helper.c | 228 ++++++++++++++++++++++++---------------
1 file changed, 141 insertions(+), 87 deletions(-)
diff --git a/target/ppc/excp_helper.c b/target/ppc/excp_helper.c
<snip>
@@ -1884,15 +1915,38 @@ bool ppc_cpu_exec_interrupt(CPUState *cs, int
interrupt_request)
{
PowerPCCPU *cpu = POWERPC_CPU(cs);
CPUPPCState *env = &cpu->env;
+ int pending_interrupt;
I would give this a simpler name to avoid confusion with the other two
pending_interrupt terms.
- if (interrupt_request & CPU_INTERRUPT_HARD) {
- ppc_hw_interrupt(env);
- if (env->pending_interrupts == 0) {
- cs->interrupt_request &= ~CPU_INTERRUPT_HARD;
- }
- return true;
+ if ((interrupt_request & CPU_INTERRUPT_HARD) == 0) {
+ return false;
}
- return false;
+
It seems we're assuming that after this point we certainly have some
pending interrupt...
+ pending_interrupt = ppc_pending_interrupt(env);
+ if (pending_interrupt == 0) {
...but how then is this able to return 0?
+ if (env->resume_as_sreset) {
+ /*
+ * This is a bug ! It means that has_work took us out of halt
+ * without anything to deliver while in a PM state that requires
+ * getting out via a 0x100
+ *
+ * This means we will incorrectly execute past the power management
+ * instruction instead of triggering a reset.
+ *
+ * It generally means a discrepancy between the wakeup conditions
in
+ * the processor has_work implementation and the logic in this
+ * function.
+ */
+ cpu_abort(env_cpu(env),
+ "Wakeup from PM state but interrupt Undelivered");
This condition is BookS only. Perhaps it would be better to move it
inside each of the processor-specific functions. And since you're
merging has_work with pending_interrupts, can't you solve that issue
earlier? Specifically the "has_work tooks us out of halt..." part.