device: 0.187
other: 0.149
vnc: 0.107
semantic: 0.083
graphic: 0.075
performance: 0.070
socket: 0.058
files: 0.052
network: 0.051
permissions: 0.049
boot: 0.040
debug: 0.034
PID: 0.028
KVM: 0.018
debug: 0.277
files: 0.151
semantic: 0.131
device: 0.114
other: 0.088
PID: 0.044
performance: 0.041
network: 0.029
socket: 0.028
permissions: 0.025
boot: 0.022
vnc: 0.020
graphic: 0.017
KVM: 0.010

ARMv7-M software-triggered interrupts-- unexpected behaviour

The handling of the NVIC "Software Triggered Interrupt Register" in qemu-2.1.0/hw/intc/armv7m_nvic.c:375 isn't quite right.  As things stand, writing a zero to the STIR ends up transferring control to vector table entry zero, which, on ARMv7-M, holds the reset value of the stack pointer.  That's what I see with lm3s811evb emulation, and that's not what happens on my STM NUCLEO-F103RB board (Cortex-M3).

Seems like an oversight-- the handler probably wants armv7m_nvic_set_pending(), not gic_set_pending_private(), and the IRQ number needs 16 added onto it to get the exception number for the interrupt.

ARM DUI 0552A (Cortex-M3 Devices: Generic User's Guide), p. 134:
  "Interrupt ID of the interrupt to trigger, in the range 0-239. For example, a value of 0x03 specifies interrupt IRQ3."

Cheers,
Boris

This bug was fixed in QEMU 2.9 as part of the rewrite of M profile exception handling.