Lines Matching +full:wait +full:- +full:state
44 ----------
49 time of the kick. Therefore, depending on the mode and state of the VCPU
55 mode that wait on waitqueues. Waking them removes the threads from
62 ---------
64 VCPUs have a mode state, ``vcpu->mode``, that is used to track whether the
66 outside guest mode states. The architecture may use ``vcpu->mode`` to
88 certain VCPU requests, namely KVM_REQ_TLB_FLUSH, to wait until the VCPU
94 VCPU requests are simply bit indices of the ``vcpu->requests`` bitmap.
95 This means general bitops, like those documented in [atomic-ops]_ could
98 clear_bit(KVM_REQ_UNHALT & KVM_REQUEST_MASK, &vcpu->requests);
106 ---------------------------------
138 ----------------
146 ------------------
158 then the caller will wait for each VCPU to acknowledge its IPI before
161 the requesting thread does not wait. This means that this flag may be
166 VCPU Requests with Associated State
169 Requesters that want the receiving VCPU to handle new state need to ensure
170 the newly written state is observable to the receiving VCPU thread's CPU
172 must be inserted after writing the new state and before setting the VCPU
175 and before proceeding to read the new state associated with it. See
176 scenario 3, Message and Flag, of [lwn-mb]_ and the kernel documentation
177 [memory-barriers]_.
199 - set ``vcpu->mode`` to IN_GUEST_MODE between disabling the interrupts and
201 - enable interrupts atomically when entering the guest.
209 (scenario 10 of [lwn-mb]_). As the Dekker pattern requires two variables,
210 this solution pairs ``vcpu->mode`` with ``vcpu->requests``. Substituting
216 WRITE_ONCE(vcpu->mode, IN_GUEST_MODE); kvm_make_request(REQ, vcpu);
218 if (kvm_request_pending(vcpu)) { if (READ_ONCE(vcpu->mode) ==
226 ``vcpu->mode`` to IN_GUEST_MODE. WRITE_ONCE() and READ_ONCE() are used to
228 compiler doesn't interfere with ``vcpu->mode``'s carefully planned
232 -------------
237 transitional state, EXITING_GUEST_MODE, is used for this purpose.
240 ----------------------------
251 Request-less VCPU Kicks
252 -----------------------
255 two-variable Dekker memory barrier pattern, then it's clear that
256 request-less VCPU kicks are almost never correct. Without the assurance
257 that a non-IPI generating kick will still result in an action by the
259 request-accompanying kicks, then the kick may not do anything useful at
260 all. If, for instance, a request-less kick was made to a VCPU that was
266 even the request-less VCPU kick is coupled with the same
269 role of ``vcpu->requests``. When sending a posted interrupt, PIR.ON is
270 set before reading ``vcpu->mode``; dually, in the VCPU thread,
271 vmx_sync_pir_to_irr() reads PIR after setting ``vcpu->mode`` to
278 --------------
288 -----------------
298 themselves. A possible side-effect of that call is to make the
305 .. [atomic-ops] Documentation/core-api/atomic_ops.rst
306 .. [memory-barriers] Documentation/memory-barriers.txt
307 .. [lwn-mb] https://lwn.net/Articles/573436/