Re: Question about edge-triggered interrupt

[LIU Zhiwei]

On 2021/3/11 21:17, Peter Maydell wrote:
> On Thu, 11 Mar 2021 at 12:59, LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
> >  From the specification, I find that software will not clean the pending bit on 
> > interrupt controller via a register write.
> >
> > "When a vectored interrupt is selected and serviced, the hardware will 
> > automatically clear the
> >
> > corresponding pending bit in edge-triggered mode. In this case, software does 
> > not need to clear
> >
> > pending bit at all in the service routine."
> >
> > Hardware can always select a pending interrupt as it is cycle-driven. But QEMU 
> > is event-driven.
> > I don't know if there is a chance to select other pending interrupts after 
> > serving the selected interrupt.
> Something must change that the hardware (and thus the model) can use to
> determine that it needs to do something else. The interrupt controller
> must be able to tell when the interrupt is "selected and serviced"
> somehow.
That's a case I can't understand.

1.  An device causes an edge-triggered interrupt A.
2.  The interrupt controller sample the interrupt A, and setting pending 
bit for A.
3.  The interrupt controller select the interrupt  A to CPU and clean 
the pending bit for A(according to the specification).
4.  CPU start to execute the A's service routine.
5.  Another device causes interrupt B.
6.  The interrupt controller sample the interrupt B, and setting pending 
bit for B.
7.  As B's priority is lower than A, it can't preempt  A's service routine.
8.  A's service routine return.
9. No other interrupt comes after B.

After the sequence, B is pending in interrupt controller, and has no 
chance to be selected by interrupt controller.
A's service routine will neither write interrupt controller's register 
nor device's register.

In my RTOS case, the interrupt A here is really a software interrupt. 
Just for clarity here.

Thanks for sharing your ideas.

Zhiwei
> thanks
> -- PMM