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

GIC-400 controller virtual interrupt handling in VM and hypervisor

Hi, I am new to ARM architecture and as of now exploring GIC Controller GIC-400 and using ARM Cortex a57.

Sorry for asking very fundamental flow of interrupts handling GIC-Virtual extension

Let assume a physical interrupts acknowledged by hypervisor in EL2 , then it injects the virtual interrupt to VM by writting List registers in virtual CPU interface.

Then hypervisor writes GICC_EOIR register for priority drop (my question : what does priority drop means ? does interrupt controllers stops firing further interrupts ?)

Hypervisor returns from isr, than VM triggered with IRQ handler (my question : does processor has seperate vIRQ line inside ? how does GIC takes processor to EL1 IRQ handler when List registers are updated ? ) 

and VM has to acknowledge interrupt by reading GICV_IAR to change state of interrupt in GICV_IAR register. 

what are the next flow ?  should VM end the interrupt (GICV_EOIR) and also deactivate (GICV_DIR) ? should also hypervisor implement GICC_DIR to deactivate interrupt ? 

Parents
  • And now to try to answer your questions....

    When you acknowledge an interrupt (read IAR), two things happen:
    - The interrupt moves to the Active state
    - The CPU interface inherits the priority of the interrupt (called running priority)

    The running priority is used to decide whether to take future interrupts, only an interrupt higher priority than the runner priority can be taken. 

    So, that means there are two things to do while handling an interrupt; clear the active state and reset the running priority.

    Writing to the EOIR resets the running priority.  Whether it ALSO clears the Active state is controlled by the EOImode bit.

    So what the hypervisor is doing is clearing the running priority, but not the active state.  That's because it hasn't actually dealt with the interrupt, it's forwarding it on to a guest OS (using the List register).  Meaning it can recieve more interrupts of the same or lower priority.


    Creating the list register entry causes the GIC to send a virtual interrupt.  On A57, there is IRQ signal input and vIRQ signal interrupt.  The GIC asserts vIRQ to signal a virtual IRQ.  (strictly, the signals are active low)

    The List Register records the physical ID of the original interrupt.  When the Guest deactivates (clears the active state) of the virtual interrupt, the GIC uses this information to also update the physical interrupt.  This avoids the need to re-enter the hypervisor

Reply
  • And now to try to answer your questions....

    When you acknowledge an interrupt (read IAR), two things happen:
    - The interrupt moves to the Active state
    - The CPU interface inherits the priority of the interrupt (called running priority)

    The running priority is used to decide whether to take future interrupts, only an interrupt higher priority than the runner priority can be taken. 

    So, that means there are two things to do while handling an interrupt; clear the active state and reset the running priority.

    Writing to the EOIR resets the running priority.  Whether it ALSO clears the Active state is controlled by the EOImode bit.

    So what the hypervisor is doing is clearing the running priority, but not the active state.  That's because it hasn't actually dealt with the interrupt, it's forwarding it on to a guest OS (using the List register).  Meaning it can recieve more interrupts of the same or lower priority.


    Creating the list register entry causes the GIC to send a virtual interrupt.  On A57, there is IRQ signal input and vIRQ signal interrupt.  The GIC asserts vIRQ to signal a virtual IRQ.  (strictly, the signals are active low)

    The List Register records the physical ID of the original interrupt.  When the Guest deactivates (clears the active state) of the virtual interrupt, the GIC uses this information to also update the physical interrupt.  This avoids the need to re-enter the hypervisor

Children
No data