On Thu, 2 Sept 2021 at 03:18, Duo jia <jiaduo19920...@gmail.com> wrote: > > Hi, > thank you for your response. > As you say >> >> "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." > > I agree with that. I has try some method, But Still have some problems. > > Q1: > My guest(target) cpu seem don't have a "interrupt handled" , And I don't > know How/When to program the " interrupt controller" to check the second > interrupt when the first over.
There is always some way for the CPU to tell the system that an interrupt has been dealt with. You don't say what architecture you're working on, so it's impossible to be more specific. But I think it is very likely that you have misunderstood how the hardware works. Typically you don't need to program the interrupt controller to check for a second interrupt -- the hw specification says that it does that automatically. > Also I found the new problem(maybe bug) , when first interrupt > not over, the second interrupt may occur Whether this is permitted or not depends upon the specification of the hardware. Some interrupt controllers never allow preemption of interrupts like this. Some do. Some allow it but only if the guest has programmed it to permit it (eg by setting priority registers). As always, you need to look at what the hardware specification says each component in the system must do (and at how they interact with each other). thanks -- PMM
