Lines Matching refs:spte
68 write-protect. That means we just need to change the W bit of the spte.
71 on the spte:
78 On fast page fault path, we will use cmpxchg to atomically set the spte W
79 bit if spte.HOST_WRITEABLE = 1 and spte.WRITE_PROTECT = 1, to restore the saved
80 R/X bits if for an access-traced spte, or both. This is safe because whenever
96 | spte is the shadow page table entry corresponding with gpte and |
97 | spte = pfn1 |
105 | old_spte = *spte; | |
109 | | spte = 0; |
116 | | spte = pfn1; |
120 | if (cmpxchg(spte, old_spte, old_spte+W) |
127 For direct sp, we can easily avoid it since the spte of direct sp is fixed
142 In the origin code, the spte can be fast updated (non-atomically) if the
143 spte is read-only and the Accessed bit has already been set since the
146 But it is not true after fast page fault since the spte can be marked
147 writable between reading spte and updating spte. Like below case:
152 | spte.W = 0 |
153 | spte.Accessed = 1 |
159 | old_spte = *spte; | |
165 | spte = 0ull; | |
169 | | spte.W = 1 |
171 | | memory write on the spte:: |
173 | | spte.Dirty = 1 |
178 | old_spte = xchg(spte, 0ull) | |
180 | kvm_set_pfn_accessed(spte.pfn);| |
182 | kvm_set_pfn_dirty(spte.pfn); | |
188 In order to avoid this kind of issue, we always treat the spte as "volatile"
190 the spte is always atomically updated in this case.
192 3) flush tlbs due to spte updated
194 If the spte is updated from writable to read-only, we should flush all TLBs,
195 otherwise rmap_write_protect will find a read-only spte, even though the
196 writable spte might be cached on a CPU's TLB.
198 As mentioned before, the spte can be updated to writable out of mmu-lock on
201 function to update spte (present -> present).
203 Since the spte is "volatile" if it can be updated out of mmu-lock, we always
204 atomically update the spte and the race caused by fast page fault can be avoided.