Re: [Qemu-arm] ARM cortex-m3 instruction fetch misbehaves during do_v7m_exception_exit

[Rd Cheung]

> What device is the interrupt handler for? Sometimes you can get
> this behaviour in QEMU for timer interrupts if the guest code
> programs the timer for a fast interrupt rate that is faster
> than QEMU's emulation speed can handle.

The interrupt handler is for a real time clock device and the interrupt 

number is 5. I trim the gptm code for stellaris because the firmware 

image only need real time clock for now. I set up a  qemu_log_mask

right before the device use qemu_set_irq to raise an interrupt. And 

from the log, the qemu_set_irq is triggered only once. I guess fast 

interrupt rate would not affect in this case, since it is not

continuously triggering an interrupt. 

And from the log in previous email, I assume the interrupt has been 

cleared during exit, because the IABR (interrupt active bit register) 

is cleared after exit. I am confused about why ISPR (interrupt set 

pending register) is set after exception exit. The proper behavior shall 

not include this.

> If you're dealing with interrupt numbers larger than 32 you'll
> need the bug fix in master in commit 12fbf1a1639ed91, which
> fixed problems with ISPR for larger interrupt numbers.

The interrupt number is 5, so I guess it is not for this reason.

> Especially if you're stepping in gdb this can happen for timers,
> because the timer will expire while you're stopped in gdb, and
> then fire as soon as you let QEMU run.

As I mentioned above, the qemu_set_irq is trigger once. I donot 

understand why the execution flow keep going into 'Taking exception5'

after it 'Taking exception 8 [QEMU v7M exception exit]' for multiple times.

I am using qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL), so the 

timer should stop counting when I stop in gdb if I am understanding 

correctly.

Thank you! I am looking forward to your reply.

Ruide Zhang

On Thu, Feb 22, 2018 at 5:00 AM, Peter Maydell <address@hidden> wrote:

On 22 February 2018 at 04:09, Rd Cheung <address@hidden> wrote:
> I have turned on the log options and I find out the execution will go
> into the same interrupt service routine for multiple times as soon as
> it exits from execption handler, before it hits its expected return address.

What device is the interrupt handler for? Sometimes you can get
this behaviour in QEMU for timer interrupts if the guest code
programs the timer for a fast interrupt rate that is faster
than QEMU's emulation speed can handle.

> So I look into the NVIC registers in cortex M3. I find out the ISPR
> register (interrupt set pending registers) in NVIC is not function normally.

If you're dealing with interrupt numbers larger than 32 you'll
need the bug fix in master in commit 12fbf1a1639ed91, which
fixed problems with ISPR for larger interrupt numbers.

> I made a breakpoint just before the code exit the exception handler.
> And I use 'x /20xw 0xe000e200' to check the ISPR register. At this point,
> the
> value is 0x0, and then I type 'si' to gdb, and the code go to the expected
> return
>  address. Then I 'x /20xw 0xe000e200' again, but this time, the value is
> 0x10,
> which indicates an interrupt is pending. If I type 'c' in gdb, the code will
> go to the
> interrupt service routine again.

Especially if you're stepping in gdb this can happen for timers,
because the timer will expire while you're stopped in gdb, and
then fire as soon as you let QEMU run.

thanks
-- PMM