This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

GICv3: Purpose of EOIcount in ICH_HCR_EL2 and LRENPIE maintenance interrupt

My initial understanding was that with LRENPIE set, any EOI coming from the guest on IRQs that are not in any LRs, will result in a maintenance interrupt and the hypervisor can check which IRQ was deactivated.

Upon taking a closer look though, I can't understand how this can be done. Since such an event will cause an asynchronous exception and not a data abort (like a regular trap), you cannot use the ESR to get the register number that the guest used for the EOI/DIR. The manual only mentions EOIcount, but that's just a counter of how many EOIs occured without a relevant LR.

So my question is, how can you tell which IRQ the guest EOIed, by using the LRENPIE maintenance interrupt and without trapping all EOI guest accesses?

Parents
  • The answer is that the GIC arch requires interrupts to EOIed in a set order.  See section 4.1.1 (Physical CPU interface), the subsection on Priority Drop.

    This rules means that, assuming the software in the VM behaved legally, EL2 has enough information to infer what happened.  It knows what interrupts are in the LRs, which LRs it has spilled, the active priorities in the Virtual CPU IF and the EOICount. 

    (nice username by the way)

Reply
  • The answer is that the GIC arch requires interrupts to EOIed in a set order.  See section 4.1.1 (Physical CPU interface), the subsection on Priority Drop.

    This rules means that, assuming the software in the VM behaved legally, EL2 has enough information to infer what happened.  It knows what interrupts are in the LRs, which LRs it has spilled, the active priorities in the Virtual CPU IF and the EOICount. 

    (nice username by the way)

Children