On Thu, Mar 11, 2021 at 11:21 AM LIU Zhiwei <zhiwei_...@c-sky.com> wrote: > > > > 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).
I'm not a CLIC expert but from what I can tell I think the interrupt is only cleared after being read. The key lines in the spec are: "When a vectored interrupt is selected and serviced, the hardware will automatically clear the corresponding pending bit in edge-triggered mode." and "The xnxti CSR can be used by software to service the next horizontal interrupt..." The C-ABI code (https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#81-c-abi-trampoline-code) seems to say something similar csrrsi a0, mnxti, MIE # Get highest current interrupt and enable interrupts. # Will return original interrupt if no others appear. (6) Does that sound right? Alistair > 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 > >
