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

Virtual interrupt EOI mode & irq state

Dear all,

After reading the http://infocenter.arm.com/help/topic/com.arm.doc.dai0492b/GICv3_Software_Overview_Official_Release_B.pdf

I have three questions about the virtual interrupt handing.

1) Can the hypervisor not use the EOI split mode and do the priority drop and inactive operation together to the irq. And then give a pending state to the LRs, the guest can still receive the virq then?

For example, the virtual timer for the vPE, PPI 27.

When the vtimer irq assert, it traps to EL2, and hypervisor do priority drop and inactive operation together. And create a LR, and assert to the VM.

Is it possible to do so?

2) The other question is about the irq state transcation. Assume the level trigger irq and split EOI mode.

1. pending -> active & pending if we ack the irq

2. if we drop the priority, how the state change? still in active & pending?

3. if we write to device reg and reset the device state, it may change from active & pending to active

4. finally, we deactive the irq.

but without split EOI mode, things turns like

1 3 4(with priority drop and deactive)?

3) Does the virq share the same state with the physic irq, i read from the doc that with virtualization extension, the virq state can affect to the pirq state, e.g., deactive the virq also deactive the pirq state, how they work togther indeed, it's confused if they share the same state, since pirq still in acive&pending when we inject the virq, while the virq in the LRs start from pending and waiting guest to ack it and finally deactive by the guest.

vtimer for example, for pirq, 

pending -> actv & pending -> priority drop to it and inject to the lr -> state changes by the guest handle ...

virq state start in lr from pending if i am not missing something

pending -> actv & pending -> clean the timer maybe and turn to actv state  -> deactive the irq, and it deative the pirq state too.

But I never find there is a way turn a actv & pending irq direct to inactive in the state machine for the irq.

Regards, George.

  • (1) Yes, it could.  A hypervisor can also set up a List Register without there having been any related physical interrupt.  The app note is just an example.

    But...
    There is a reason why a hypervisor might want to _not_ deactivate the physical interrupt from the timer.  If the interrupt is deactivated it can re-fire and cause additional entries into the hypervisor.  By doing priority drop - but not deactivation - you ensure that this specific interrupt cannot re-fire until the VM deals with the linked virtual interrupt.

    (2) At step 2 the state of the physical interrupt is unchanged.

    Priority drop and Deactivation are really two very different activities.  Deactivation is about updating the state machine of that specific interrupt.  Priority drop is about the running priority of the CPU, which determines which interrupts can pre-empt.

    (3) In GICv3.x - no, physical and virtual interrupts do not share state.

    A virtual interrupt's state and config is held in a List Register.
    A physical interrupt's state and config is held in the Distributor or Redistributors.

    You can link a physical and virtual interrupt for the purposes of deactivation.  But otherwise, they are independent.

    In GICv4 it gets a little more interesting.  GICv4 allows direct-injection of virtual interrupts.

    But I never find there is a way turn a actv & pending irq direct to inactive in the state machine for the irq

    Strictly, there isn't.  Assuming level-sensitive, the Pending part is cleared by de-asserting the input signal.  The Active part is cleared by a deactivation (write to EOIR or DIR).  The spec would see these as two separate steps, so either you'd see:

    A&P -> Pending -> Inactive

    or

    A&P -> Active -> Inactive

    The two operations might be so close together that it's like you went straight from A&P to Inactive.

    But I suspect most handlers would clear the interrupt in the peripheral a few steps before the GIC deactivation operation.