188 lines
9.3 KiB
Plaintext
188 lines
9.3 KiB
Plaintext
KVM/ARM VGIC Forwarded Physical Interrupts
|
|
==========================================
|
|
|
|
The KVM/ARM code implements software support for the ARM Generic
|
|
Interrupt Controller's (GIC's) hardware support for virtualization by
|
|
allowing software to inject virtual interrupts to a VM, which the guest
|
|
OS sees as regular interrupts. The code is famously known as the VGIC.
|
|
|
|
Some of these virtual interrupts, however, correspond to physical
|
|
interrupts from real physical devices. One example could be the
|
|
architected timer, which itself supports virtualization, and therefore
|
|
lets a guest OS program the hardware device directly to raise an
|
|
interrupt at some point in time. When such an interrupt is raised, the
|
|
host OS initially handles the interrupt and must somehow signal this
|
|
event as a virtual interrupt to the guest. Another example could be a
|
|
passthrough device, where the physical interrupts are initially handled
|
|
by the host, but the device driver for the device lives in the guest OS
|
|
and KVM must therefore somehow inject a virtual interrupt on behalf of
|
|
the physical one to the guest OS.
|
|
|
|
These virtual interrupts corresponding to a physical interrupt on the
|
|
host are called forwarded physical interrupts, but are also sometimes
|
|
referred to as 'virtualized physical interrupts' and 'mapped interrupts'.
|
|
|
|
Forwarded physical interrupts are handled slightly differently compared
|
|
to virtual interrupts generated purely by a software emulated device.
|
|
|
|
|
|
The HW bit
|
|
----------
|
|
Virtual interrupts are signalled to the guest by programming the List
|
|
Registers (LRs) on the GIC before running a VCPU. The LR is programmed
|
|
with the virtual IRQ number and the state of the interrupt (Pending,
|
|
Active, or Pending+Active). When the guest ACKs and EOIs a virtual
|
|
interrupt, the LR state moves from Pending to Active, and finally to
|
|
inactive.
|
|
|
|
The LRs include an extra bit, called the HW bit. When this bit is set,
|
|
KVM must also program an additional field in the LR, the physical IRQ
|
|
number, to link the virtual with the physical IRQ.
|
|
|
|
When the HW bit is set, KVM must EITHER set the Pending OR the Active
|
|
bit, never both at the same time.
|
|
|
|
Setting the HW bit causes the hardware to deactivate the physical
|
|
interrupt on the physical distributor when the guest deactivates the
|
|
corresponding virtual interrupt.
|
|
|
|
|
|
Forwarded Physical Interrupts Life Cycle
|
|
----------------------------------------
|
|
|
|
The state of forwarded physical interrupts is managed in the following way:
|
|
|
|
- The physical interrupt is acked by the host, and becomes active on
|
|
the physical distributor (*).
|
|
- KVM sets the LR.Pending bit, because this is the only way the GICV
|
|
interface is going to present it to the guest.
|
|
- LR.Pending will stay set as long as the guest has not acked the interrupt.
|
|
- LR.Pending transitions to LR.Active on the guest read of the IAR, as
|
|
expected.
|
|
- On guest EOI, the *physical distributor* active bit gets cleared,
|
|
but the LR.Active is left untouched (set).
|
|
- KVM clears the LR on VM exits when the physical distributor
|
|
active state has been cleared.
|
|
|
|
(*): The host handling is slightly more complicated. For some forwarded
|
|
interrupts (shared), KVM directly sets the active state on the physical
|
|
distributor before entering the guest, because the interrupt is never actually
|
|
handled on the host (see details on the timer as an example below). For other
|
|
forwarded interrupts (non-shared) the host does not deactivate the interrupt
|
|
when the host ISR completes, but leaves the interrupt active until the guest
|
|
deactivates it. Leaving the interrupt active is allowed, because Linux
|
|
configures the physical GIC with EOIMode=1, which causes EOI operations to
|
|
perform a priority drop allowing the GIC to receive other interrupts of the
|
|
default priority.
|
|
|
|
|
|
Forwarded Edge and Level Triggered PPIs and SPIs
|
|
------------------------------------------------
|
|
Forwarded physical interrupts injected should always be active on the
|
|
physical distributor when injected to a guest.
|
|
|
|
Level-triggered interrupts will keep the interrupt line to the GIC
|
|
asserted, typically until the guest programs the device to deassert the
|
|
line. This means that the interrupt will remain pending on the physical
|
|
distributor until the guest has reprogrammed the device. Since we
|
|
always run the VM with interrupts enabled on the CPU, a pending
|
|
interrupt will exit the guest as soon as we switch into the guest,
|
|
preventing the guest from ever making progress as the process repeats
|
|
over and over. Therefore, the active state on the physical distributor
|
|
must be set when entering the guest, preventing the GIC from forwarding
|
|
the pending interrupt to the CPU. As soon as the guest deactivates the
|
|
interrupt, the physical line is sampled by the hardware again and the host
|
|
takes a new interrupt if and only if the physical line is still asserted.
|
|
|
|
Edge-triggered interrupts do not exhibit the same problem with
|
|
preventing guest execution that level-triggered interrupts do. One
|
|
option is to not use HW bit at all, and inject edge-triggered interrupts
|
|
from a physical device as pure virtual interrupts. But that would
|
|
potentially slow down handling of the interrupt in the guest, because a
|
|
physical interrupt occurring in the middle of the guest ISR would
|
|
preempt the guest for the host to handle the interrupt. Additionally,
|
|
if you configure the system to handle interrupts on a separate physical
|
|
core from that running your VCPU, you still have to interrupt the VCPU
|
|
to queue the pending state onto the LR, even though the guest won't use
|
|
this information until the guest ISR completes. Therefore, the HW
|
|
bit should always be set for forwarded edge-triggered interrupts. With
|
|
the HW bit set, the virtual interrupt is injected and additional
|
|
physical interrupts occurring before the guest deactivates the interrupt
|
|
simply mark the state on the physical distributor as Pending+Active. As
|
|
soon as the guest deactivates the interrupt, the host takes another
|
|
interrupt if and only if there was a physical interrupt between injecting
|
|
the forwarded interrupt to the guest and the guest deactivating the
|
|
interrupt.
|
|
|
|
Consequently, whenever we schedule a VCPU with one or more LRs with the
|
|
HW bit set, the interrupt must also be active on the physical
|
|
distributor.
|
|
|
|
|
|
Forwarded LPIs
|
|
--------------
|
|
LPIs, introduced in GICv3, are always edge-triggered and do not have an
|
|
active state. They become pending when a device signal them, and as
|
|
soon as they are acked by the CPU, they are inactive again.
|
|
|
|
It therefore doesn't make sense, and is not supported, to set the HW bit
|
|
for physical LPIs that are forwarded to a VM as virtual interrupts,
|
|
typically virtual SPIs.
|
|
|
|
For LPIs, there is no other choice than to preempt the VCPU thread if
|
|
necessary, and queue the pending state onto the LR.
|
|
|
|
|
|
Putting It Together: The Architected Timer
|
|
------------------------------------------
|
|
The architected timer is a device that signals interrupts with level
|
|
triggered semantics. The timer hardware is directly accessed by VCPUs
|
|
which program the timer to fire at some point in time. Each VCPU on a
|
|
system programs the timer to fire at different times, and therefore the
|
|
hardware is multiplexed between multiple VCPUs. This is implemented by
|
|
context-switching the timer state along with each VCPU thread.
|
|
|
|
However, this means that a scenario like the following is entirely
|
|
possible, and in fact, typical:
|
|
|
|
1. KVM runs the VCPU
|
|
2. The guest programs the time to fire in T+100
|
|
3. The guest is idle and calls WFI (wait-for-interrupts)
|
|
4. The hardware traps to the host
|
|
5. KVM stores the timer state to memory and disables the hardware timer
|
|
6. KVM schedules a soft timer to fire in T+(100 - time since step 2)
|
|
7. KVM puts the VCPU thread to sleep (on a waitqueue)
|
|
8. The soft timer fires, waking up the VCPU thread
|
|
9. KVM reprograms the timer hardware with the VCPU's values
|
|
10. KVM marks the timer interrupt as active on the physical distributor
|
|
11. KVM injects a forwarded physical interrupt to the guest
|
|
12. KVM runs the VCPU
|
|
|
|
Notice that KVM injects a forwarded physical interrupt in step 11 without
|
|
the corresponding interrupt having actually fired on the host. That is
|
|
exactly why we mark the timer interrupt as active in step 10, because
|
|
the active state on the physical distributor is part of the state
|
|
belonging to the timer hardware, which is context-switched along with
|
|
the VCPU thread.
|
|
|
|
If the guest does not idle because it is busy, the flow looks like this
|
|
instead:
|
|
|
|
1. KVM runs the VCPU
|
|
2. The guest programs the time to fire in T+100
|
|
4. At T+100 the timer fires and a physical IRQ causes the VM to exit
|
|
(note that this initially only traps to EL2 and does not run the host ISR
|
|
until KVM has returned to the host).
|
|
5. With interrupts still disabled on the CPU coming back from the guest, KVM
|
|
stores the virtual timer state to memory and disables the virtual hw timer.
|
|
6. KVM looks at the timer state (in memory) and injects a forwarded physical
|
|
interrupt because it concludes the timer has expired.
|
|
7. KVM marks the timer interrupt as active on the physical distributor
|
|
7. KVM enables the timer, enables interrupts, and runs the VCPU
|
|
|
|
Notice that again the forwarded physical interrupt is injected to the
|
|
guest without having actually been handled on the host. In this case it
|
|
is because the physical interrupt is never actually seen by the host because the
|
|
timer is disabled upon guest return, and the virtual forwarded interrupt is
|
|
injected on the KVM guest entry path.
|