On 2021/3/12 0:07, Peter Maydell wrote:
On Thu, 11 Mar 2021 at 16:01, LIU Zhiwei <zhiwei_...@c-sky.com> wrote:
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.
I'm pretty sure that there is some interaction between the CPU and the
interrupt controller on a return-from-interrupt that you are
missing.
I have asked my CPU design workmates. They said, "you have to pull a
pending interrupt at the interrupt return instruction".
But I don't want to do this way, because it influences the interrupt
return instruction's behavior. The specification doesn't
point that explicitly. It's just our CPU implementation.
If I lock the iothread in interrupt return instruction helper function,
and pull a pending interrupt. It really works, but I don't think
it will be appropriate for other CPU implementation.
There are several ways to do it in principle;
I am curious about the ways. If you like, a simple list please.
you need
a risc-v expert to answer your question more specifically.
Thanks for your advice.
Zhiwei
thanks
-- PMM
