add mailinglist scraper results

1 files changed, 60 insertions, 0 deletions

diff --git a/mailinglist/output_launchpad/1226531 b/mailinglist/output_launchpad/1226531
new file mode 100644
index 00000000..35136b29
--- /dev/null
+++ b/mailinglist/output_launchpad/1226531
@@ -0,0 +1,60 @@
+Incorrect logic in ARMv7M interrupt handler
+
+On ARMv7M interrupts handlers will be called even if emulated code executes "cpsid i" instruction.
+
+Underlying cause described below:
+
+In cpu-exec.c:cpu_exec there is a block of code that determines if an interrupt should be raised or not:
+
+
+                    /* ARMv7-M interrupt return works by loading a magic value
+                       into the PC.  On real hardware the load causes the
+                       return to occur.  The qemu implementation performs the
+                       jump normally, then does the exception return when the
+                       CPU tries to execute code at the magic address.
+                       This will cause the magic PC value to be pushed to
+                       the stack if an interrupt occurred at the wrong time.
+                       We avoid this by disabling interrupts when
+                       pc contains a magic address.  */
+                    if (interrupt_request & CPU_INTERRUPT_HARD
+                        && ((IS_M(env) && env->regs[15] < 0xfffffff0)
+                            || !(env->uncached_cpsr & CPSR_I))) {
+                        env->exception_index = EXCP_IRQ;
+                        cc->do_interrupt(cpu);
+                        next_tb = 0;
+                    }
+
+I'm not convinced the logic is correct.
+The logic for ARMv7M should be:
+
+If an interrupt is pending (interrupt_request & CPU_INTERRUPT_HARD)
+AND
+Interrupts are not disabled ( !(env->uncached_cpsr & CPSR_I) )
+AND
+PC doesn't have a magic value (env->regs[15] < 0xfffffff0)
+
+The current logic seems fires the interrupt if interrupts are enabled OR the PC isn't magic, which is basically all the time.
+
+I'm not sure what the cleanest patch for this would be.
+
+On 17 September 2013 11:44, benno <email address hidden> wrote:
+> I'm not convinced the logic is correct.
+
+It's not. There have been a few attempts by people to submit patches
+to this though, but none of them have actually been sufficiently
+convincing. See for instance
+http://lists.nongnu.org/archive/html/qemu-devel/2013-05/msg04546.html
+
+If somebody produces a patch which comes with a good rationale
+for its change (ie with reference to the architecture manual and to
+what QEMU means when it sets "CPSR_I" on M profile) I'll apply
+it. But because the v7M code is currently not really maintained and
+v7M interrupts are complex I'm reluctant to apply patches which
+only come with "seems to fix things for me" levels of justification.
+
+-- PMM
+
+
+We finally fixed this longstanding ARMv7M emulation bug in the 2.10 release (by rewriting the NVIC handling entirely).
+
+