Lines Matching +full:non +full:- +full:ipi
1 .. SPDX-License-Identifier: GPL-2.0
46 ----------
49 order to perform some KVM maintenance. To do so, an IPI is sent, forcing
55 1) Send an IPI. This forces a guest mode exit.
64 ---------
66 VCPUs have a mode state, ``vcpu->mode``, that is used to track whether the
68 outside guest mode states. The architecture may use ``vcpu->mode`` to
70 as well as to avoid sending unnecessary IPIs (see "IPI Reduction"), and
71 even to ensure IPI acknowledgements are waited upon (see "Waiting for
96 VCPU requests are simply bit indices of the ``vcpu->requests`` bitmap.
97 This means general bitops, like those documented in [atomic-ops]_ could
100 clear_bit(KVM_REQ_UNBLOCK & KVM_REQUEST_MASK, &vcpu->requests);
108 ---------------------------------
137 guarantee the to-be-kicked vCPU has fully exited guest mode.
140 ----------------
148 ------------------
160 then the caller will wait for each VCPU to acknowledge its IPI before
162 If, for example, the VCPU is sleeping, so no IPI is necessary, then
178 scenario 3, Message and Flag, of [lwn-mb]_ and the kernel documentation
179 [memory-barriers]_.
192 kick will send an IPI to force an exit from guest mode when necessary.
197 enter guest mode. This means that an optimized implementation (see "IPI
198 Reduction") must be certain when it's safe to not send the IPI. One
201 - set ``vcpu->mode`` to IN_GUEST_MODE between disabling the interrupts and
203 - enable interrupts atomically when entering the guest.
208 !kvm_request_pending() on its last check and then not receiving an IPI for
211 (scenario 10 of [lwn-mb]_). As the Dekker pattern requires two variables,
212 this solution pairs ``vcpu->mode`` with ``vcpu->requests``. Substituting
218 WRITE_ONCE(vcpu->mode, IN_GUEST_MODE); kvm_make_request(REQ, vcpu);
220 if (kvm_request_pending(vcpu)) { if (READ_ONCE(vcpu->mode) ==
222 ...abort guest entry... ...send IPI...
225 As stated above, the IPI is only useful for VCPU threads in guest mode or
228 ``vcpu->mode`` to IN_GUEST_MODE. WRITE_ONCE() and READ_ONCE() are used to
230 compiler doesn't interfere with ``vcpu->mode``'s carefully planned
233 IPI Reduction
234 -------------
236 As only one IPI is needed to get a VCPU to check for any/all requests,
237 then they may be coalesced. This is easily done by having the first IPI
242 ----------------------------
249 KVM_REQUEST_WAIT flag changes the condition for sending an IPI from
253 Request-less VCPU Kicks
254 -----------------------
256 As the determination of whether or not to send an IPI depends on the
257 two-variable Dekker memory barrier pattern, then it's clear that
258 request-less VCPU kicks are almost never correct. Without the assurance
259 that a non-IPI generating kick will still result in an action by the
261 request-accompanying kicks, then the kick may not do anything useful at
262 all. If, for instance, a request-less kick was made to a VCPU that was
263 just about to set its mode to IN_GUEST_MODE, meaning no IPI is sent, then
268 even the request-less VCPU kick is coupled with the same
271 role of ``vcpu->requests``. When sending a posted interrupt, PIR.ON is
272 set before reading ``vcpu->mode``; dually, in the VCPU thread,
273 vmx_sync_pir_to_irr() reads PIR after setting ``vcpu->mode`` to
280 --------------
292 .. [atomic-ops] Documentation/atomic_bitops.txt and Documentation/atomic_t.txt
293 .. [memory-barriers] Documentation/memory-barriers.txt
294 .. [lwn-mb] https://lwn.net/Articles/573436/