Lines Matching refs:spte
36 spte.
39 SPTE_MMU_WRITEABLE bit on the spte:
45 On fast page fault path, we will use cmpxchg to atomically set the spte W
46 bit if spte.SPTE_HOST_WRITEABLE = 1 and spte.SPTE_WRITE_PROTECT = 1, or
59 spte is the shadow page table entry corresponding with gpte and
60 spte = pfn1
65 old_spte = *spte;
67 spte = 0;
73 spte = pfn1;
75 if (cmpxchg(spte, old_spte, old_spte+W)
81 For direct sp, we can easily avoid it since the spte of direct sp is fixed
95 In the origin code, the spte can be fast updated (non-atomically) if the
96 spte is read-only and the Accessed bit has already been set since the
99 But it is not true after fast page fault since the spte can be marked
100 writable between reading spte and updating spte. Like below case:
103 spte.W = 0
104 spte.Accessed = 1
109 old_spte = *spte;
114 spte = 0ull;
116 spte.W = 1
117 memory write on the spte:
118 spte.Dirty = 1
122 old_spte = xchg(spte, 0ull)
126 kvm_set_pfn_accessed(spte.pfn);
128 kvm_set_pfn_dirty(spte.pfn);
133 In order to avoid this kind of issue, we always treat the spte as "volatile"
135 the spte is always atomically updated in this case.
137 3): flush tlbs due to spte updated
138 If the spte is updated from writable to readonly, we should flush all TLBs,
139 otherwise rmap_write_protect will find a read-only spte, even though the
140 writable spte might be cached on a CPU's TLB.
142 As mentioned before, the spte can be updated to writable out of mmu-lock on
145 function to update spte (present -> present).
147 Since the spte is "volatile" if it can be updated out of mmu-lock, we always
148 atomically update the spte, the race caused by fast page fault can be avoided,