Lines Matching refs:guest
6 allowing software to inject virtual interrupts to a VM, which the guest
12 lets a guest OS program the hardware device directly to raise an
15 event as a virtual interrupt to the guest. Another example could be a
17 by the host, but the device driver for the device lives in the guest OS
19 the physical one to the guest OS.
31 Virtual interrupts are signalled to the guest by programming the List
34 Active, or Pending+Active). When the guest ACKs and EOIs a virtual
46 interrupt on the physical distributor when the guest deactivates the
58 interface is going to present it to the guest.
59 - LR.Pending will stay set as long as the guest has not acked the interrupt.
60 - LR.Pending transitions to LR.Active on the guest read of the IAR, as
62 - On guest EOI, the *physical distributor* active bit gets cleared,
69 distributor before entering the guest, because the interrupt is never actually
72 when the host ISR completes, but leaves the interrupt active until the guest
82 physical distributor when injected to a guest.
85 asserted, typically until the guest programs the device to deassert the
87 distributor until the guest has reprogrammed the device. Since we
89 interrupt will exit the guest as soon as we switch into the guest,
90 preventing the guest from ever making progress as the process repeats
92 must be set when entering the guest, preventing the GIC from forwarding
93 the pending interrupt to the CPU. As soon as the guest deactivates the
98 preventing guest execution that level-triggered interrupts do. One
101 potentially slow down handling of the interrupt in the guest, because a
102 physical interrupt occurring in the middle of the guest ISR would
103 preempt the guest for the host to handle the interrupt. Additionally,
106 to queue the pending state onto the LR, even though the guest won't use
107 this information until the guest ISR completes. Therefore, the HW
110 physical interrupts occurring before the guest deactivates the interrupt
112 soon as the guest deactivates the interrupt, the host takes another
114 the forwarded interrupt to the guest and the guest deactivating the
149 2. The guest programs the time to fire in T+100
150 3. The guest is idle and calls WFI (wait-for-interrupts)
158 11. KVM injects a forwarded physical interrupt to the guest
168 If the guest does not idle because it is busy, the flow looks like this
172 2. The guest programs the time to fire in T+100
176 5. With interrupts still disabled on the CPU coming back from the guest, KVM
184 guest without having actually been handled on the host. In this case it
186 timer is disabled upon guest return, and the virtual forwarded interrupt is
187 injected on the KVM guest entry path.