On 2021/3/11 21:17, Peter Maydell wrote:
On Thu, 11 Mar 2021 at 12:59, LIU Zhiwei <zhiwei_...@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
