On Thu, 11 Mar 2021 at 16:40, LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
On 2021/3/12 0:07, Peter Maydell wrote:
On Thu, 11 Mar 2021 at 16:01, LIU Zhiwei <zhiwei_liu@c-sky.com> wrote:
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 the hardware does it like that, your model of the hardware
should do it like that. Don't invent QEMU-specific weirdness
if you can avoid it.
More generally, if the specification says that something has to
happen when the CPU does an interrupt-return instruction, then the
obvious implementation is to put suitable code in the helper function
for the interrupt return instruction.
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.
So for instance:
You can have an interrupt controller which holds a signal line
to the CPU high while it has any pending interrupt. When the
CPU executes return-from-interrupt this involves unblocking interrupts,
and so if there's still another pending interrupt the CPU will just
immediately take it, because the signal line is still high. Arm FIQ/IRQ
with a GICv2 works like this. (It's also how QEMU handles the GICv3,
which is not exactly the same as the typical h/w implementation.)
You can have a more complicated scheme where the interrupt
controller and the CPU are very tightly integrated, and so
'return from interrupt' executed by the CPU means "look at whatever
is next up as the next highest priority interrupt and do that,
possibly avoiding a bunch of stack frame unstack/stack actions".
The Arm M-profile NVIC is like that.