On Fri, 6 Aug 2021 at 07:24, Duo jia <jiaduo19920...@gmail.com> wrote:
> I am simulating a device. When an interrupt occurs, another interrupt
> comes, and the second interrupt will not be triggered because the
> first interrupt has not yet finished.
>
> I want to know whether qemu can detect whether the interrupt has been
> executed, will there be a callback here?
> Or how can I deal with this situation?
End of interrupt handling is entirely dependent on what the
guest hardware being emulated is. Usually the guest software
will indicate "interrupt handled" back to the interrupt
controller (perhaps by writing a register; depends on the
interrupt controller), and the interrupt controller will
then look at what the next highest priority pending interrupt
is and signal that back to the CPU, or do nothing if there's
no new interrupt. So the second interrupt will automatically
be taken and handled once the first one has finished,
as a result of this interrupt controller and guest OS
interaction.
The original device usually doesn't get told when this
happens, and it doesn't need to know. For example, one common
form of device interrupt is level-triggered. Here the device
has some condition (perhaps "FIFO full") that causes an
interrupt. So it raises its outbound IRQ line when the FIFO
is full, and it doesn't lower it again until whatever the
device specification says is the condition (eg when the
guest reads from the FIFO, or if the guest writes to some
'clear interrupt' register on the device). It's the job of
the guest software to make sure that when it gets an interrupt
from the device that it handles it such that the device has
been satisfied and lowered the interrupt.
More rarely, some devices are specified to pulse their interrupt
line when a condition occurs.
In summary, you need to look at the specification of the device
you're emulating to find out when and how it is supposed to
raise or lower its interrupt line. ("I didn't get a second
interrupt" bugs might also be caused by bugs in the interrupt
controller or in the guest software device driver -- if you're
just using an existing known-to-work QEMU interrupt controller
model and a known-to-work device driver and OS, then the
bug is very likely in your device model. If you're also
writing the OS device driver at the same time then the bug
could be there instead.)
-- PMM
