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

[Rd Cheung]

>  Is the device also clearing the interrupt status by calling
>  qemu_set_irq() with a level of 0 (this should happen when your
>  guest's interrupt handler does whatever it needs to do to the
>  device to clear the interrupt) ? If the device is still asserting
>  the interrupt when the ISR returns, the M profile CPU architecture
>  requires that it is automatically made pending again (so it will
>  likely be taken immediately). This is documented in the ARMv7M
>  Architecture Reference Manual (DDI0403E.b) in section B3.4.1
>  "NVIC operation". QEMU implements this in the armv7m_nvic_complete_irq()
>  function.

Yes, it turns out the device does not clear the interrupt line when the

guest code tells it to. When it is fixed, this issue is solved! I can now

move on to solving other issues.

>  I think you're seeing the correct CPU behaviour here, and the
>  problem is that the device isn't deasserting the interrupt line.
>  Either the device code is wrong, or the guest code is wrong and
>  not doing what it should to tell the device to stop asserting the
>  interrupt line.

Yes, you are absolutely right. The interrupt line is not cleared, so I 

am seeing pending there.

Thank you for your help and patience, I really appreciate it!

Cheers,

Ruide Zhang

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

On 22 February 2018 at 13:19, Rd Cheung <address@hidden> wrote:
>> 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.

Is the device also clearing the interrupt status by calling
qemu_set_irq() with a level of 0 (this should happen when your
guest's interrupt handler does whatever it needs to do to the
device to clear the interrupt) ? If the device is still asserting
the interrupt when the ISR returns, the M profile CPU architecture
requires that it is automatically made pending again (so it will
likely be taken immediately). This is documented in the ARMv7M
Architecture Reference Manual (DDI0403E.b) in section B3.4.1
"NVIC operation". QEMU implements this in the armv7m_nvic_complete_irq()
function.

> 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.

I think you're seeing the correct CPU behaviour here, and the
problem is that the device isn't deasserting the interrupt line.
Either the device code is wrong, or the guest code is wrong and
not doing what it should to tell the device to stop asserting the
interrupt line.

thanks
-- PMM