Lines Matching full:are

12   /* Check if any requests are pending for VCPU @vcpu. */
39 (kvm_make_request() calls) are followed by a call to kvm_vcpu_kick(),
50 thread, there are two other actions a kick may take.  All three actions
51 are listed below:
54 2) Waking a sleeping VCPU.  Sleeping VCPUs are VCPU threads outside guest
67 ensure VCPU requests are seen by VCPUs (see "Ensuring Requests Are Seen"),
69 even to ensure IPI acknowledgements are waited upon (see "Waiting for
70 Acknowledgements").  The following modes are defined:
94 VCPU requests are simply bit indices of the ``vcpu->requests`` bitmap.
101 break the abstraction.  The first 8 bits are reserved for architecture
102 independent requests, all additional bits are available for architecture
117   When shadow page tables are used and memory slots are removed it's
141 bitops.  This is because only the lower 8 bits are used to represent the
142 request's number.  The upper bits are used as flags.  Currently only two
143 flags are defined.
153   requests when they are awaken later for some other reason.
157   When requests with this flag are made with kvm_make_all_cpus_request(),
183 Ensuring Requests Are Seen
193 IPIs will only trigger guest mode exits for VCPU threads that are in guest
226 ``vcpu->mode`` to IN_GUEST_MODE.  WRITE_ONCE() and READ_ONCE() are used to
244 VCPU threads are in modes other than IN_GUEST_MODE.  For example, one case
256 request-less VCPU kicks are almost never correct.  Without the assurance
292 thread and the receiving VCPU thread are executed serially, such as when
293 they are the same thread, or when they are using some form of concurrency
297 examples of this are kvm_vcpu_block() calls made by VCPUs to block