Lines Matching refs:can

15 the mmu-lock on x86. Currently, the page fault can be fast only if the
28 is safe because whenever changing these bits can be detected by cmpxchg.
32 The mapping from gfn to pfn may be changed since we can only ensure the pfn
61 For direct sp, we can easily avoid it since the spte of direct sp is fixed
64 - We have held the refcount of pfn that means the pfn can not be freed and
66 - The pfn is writable that means it can not be shared between different gfns
69 Then, we can ensure the dirty bitmaps is correctly set for a gfn.
75 In the origin code, the spte can be fast updated (non-atomically) if the
77 Accessed bit and Dirty bit can not be lost.
79 But it is not true after fast page fault since the spte can be marked
114 if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means,
122 As mentioned before, the spte can be updated to writable out of mmu-lock on
127 Since the spte is "volatile" if it can be updated out of mmu-lock, we always
128 atomically update the spte, the race caused by fast page fault can be avoided,
167 		The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu