Lines Matching +full:interrupt +full:- +full:less

44 ----------
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
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 ---------------------------------
124   of a VCPU.  It informs the VCPU thread to inject a timer interrupt.
132   event or interrupt arrives kvm_vcpu_block() makes the request.  This is
138 ----------------
146 ------------------
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 -------------
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
265 One exception is x86's posted interrupt mechanism.  In this case, however,
266 even the request-less VCPU kick is coupled with the same
268 (Outstanding Notification) in the posted interrupt descriptor takes the
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/