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.mayd...@linaro.org> 于2021年9月3日周五 下午7:20写道： > On Fri, 3 Sept 2021 at 11:54, Duo jia <jiaduo19920...@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 >
