Lines Matching +full:mode +full:- +full:flag
1 .. SPDX-License-Identifier: GPL-2.0
46 ----------
48 The goal of a VCPU kick is to bring a VCPU thread out of guest mode in
50 a guest mode exit. However, a VCPU thread may not be in guest mode at the
51 time of the kick. Therefore, depending on the mode and state of the VCPU
55 1) Send an IPI. This forces a guest mode exit.
57 mode that wait on waitqueues. Waking them removes the threads from
60 3) Nothing. When the VCPU is not in guest mode and the VCPU thread is not
63 VCPU Mode
64 ---------
66 VCPUs have a mode state, ``vcpu->mode``, that is used to track whether the
67 guest is running in guest mode or not, as well as some specific
68 outside guest mode states. The architecture may use ``vcpu->mode`` to
76 The VCPU thread is outside guest mode.
80 The VCPU thread is in guest mode.
89 The VCPU thread is outside guest mode, but it wants the sender of
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 ---------------------------------
131 This "request" ensures the target vCPU has exited guest mode prior to the
135 guest mode. A kick only guarantees the vCPU will exit at some point in the
137 guarantee the to-be-kicked vCPU has fully exited guest mode.
140 ----------------
148 ------------------
152 This flag is applied to requests that only need immediate attention
153 from VCPUs running in guest mode. That is, sleeping VCPUs do not need
159 When requests with this flag are made with kvm_make_all_cpus_request(),
161 proceeding. This flag only applies to VCPUs that would receive IPIs.
163 the requesting thread does not wait. This means that this flag may be
178 scenario 3, Message and Flag, of [lwn-mb]_ and the kernel documentation
179 [memory-barriers]_.
189 executing in guest mode for an arbitrary long time without handling the
191 thread checks kvm_request_pending() before entering guest mode and that a
192 kick will send an IPI to force an exit from guest mode when necessary.
194 kvm_request_pending() check and before it has entered guest mode, as kick
195 IPIs will only trigger guest mode exits for VCPU threads that are in guest
196 mode or at least have already disabled interrupts in order to prepare to
197 enter guest mode. This means that an optimized implementation (see "IPI
201 - set ``vcpu->mode`` to IN_GUEST_MODE between disabling the interrupts and
203 - enable interrupts atomically when entering the guest.
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) ==
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
234 -------------
238 sending kick also change the VCPU mode to something !IN_GUEST_MODE. The
242 ----------------------------
244 Some requests, those with the KVM_REQUEST_WAIT flag set, require IPIs to
247 is when a target VCPU thread is in READING_SHADOW_PAGE_TABLES mode, which
249 KVM_REQUEST_WAIT flag changes the condition for sending an IPI from
253 Request-less VCPU Kicks
254 -----------------------
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/