Thank you for your explanation.

 And finishing the execution of the interrupt routine will automatically
> allow a pending second interrupt to be taken immediately
>

I think this is a hardware feature. But how to achieve it with qemu

Peter Maydell <peter.maydell@linaro.org> 于2021年9月3日周五 下午7:20写道：

> On Fri, 3 Sept 2021 at 11:54, Duo jia <jiaduo19920301@gmail.com> wrote:
> >
> > I do some support on STM8 arch, the reference manual link is:
> >>
> >>
> https://www.st.com/resource/en/reference_manual/cd00218714-stm8l050j3-stm8l051f3-stm8l052c6-stm8l052r8-mcus-and-stm8l151l152-stm8l162-stm8al31-stm8al3l-lines-stmicroelectronics.pdf
> >
> > I don't kown when to check the "PENDING" because I can't get the when
> interrrupt exec over.
> > Is there a similar implementation in qemu？
>
> Thanks for the link. Looking at that spec, the condition
> for "interrupt execution has finished" is "the guest executes an
> IRET instruction". However, you don't need to do anything special
> at that point (beyond making the IRET instruction do the things
> it should do with restoring registers).
>
> If you look at the diagram, the check you need to make
> is "do the I1:I0 bits for this pending interrupt specify a
> higher priority than the values in CCR.I1 and I0?". That is
> how you determine "interrupt has higher priority than current one"
> to know whether to actually take the interrupt.
>
> On interrupt entry the CCR bits are set from the ITC_SPRx registers,
> which means that taking an interrupt automatically sets the CPU
> priority such that the interrupt cannot be nested. And
> finishing the execution of the interrupt routine will automatically
> allow a pending second interrupt to be taken immediately, because
> the IRET instruction restores the old values of CCR.I1,I0, and
> those old values then mean that the CPU is at a priority that
> permits the pending interrupt to be taken.
>
> thanks
> -- PMM
>