virt/kvm/vcpu-requests.rst

1 .. SPDX-License-Identifier: GPL-2.0
46 ----------
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
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 ---------------------------------
126   or in order to update the interrupt routing and ensure that assigned
137   guarantee the to-be-kicked vCPU has fully exited guest mode.
140 ----------------
148 ------------------
178 scenario 3, Message and Flag, of [lwn-mb]_ and the kernel documentation
179 [memory-barriers]_.
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) ==
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 -------------
242 ----------------------------
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
267 One exception is x86's posted interrupt mechanism.  In this case, however,
268 even the request-less VCPU kick is coupled with the same
270 (Outstanding Notification) in the posted interrupt descriptor takes the
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/