Lines Matching refs:spte
56 write-protect. That means we just need to change the W bit of the spte.
59 on the spte:
66 On fast page fault path, we will use cmpxchg to atomically set the spte W
67 bit if spte.HOST_WRITEABLE = 1 and spte.WRITE_PROTECT = 1, to restore the saved
68 R/X bits if for an access-traced spte, or both. This is safe because whenever
84 | spte is the shadow page table entry corresponding with gpte and |
85 | spte = pfn1 |
93 | old_spte = *spte; | |
97 | | spte = 0; |
104 | | spte = pfn1; |
108 | if (cmpxchg(spte, old_spte, old_spte+W) |
115 For direct sp, we can easily avoid it since the spte of direct sp is fixed
130 In the origin code, the spte can be fast updated (non-atomically) if the
131 spte is read-only and the Accessed bit has already been set since the
134 But it is not true after fast page fault since the spte can be marked
135 writable between reading spte and updating spte. Like below case:
140 | spte.W = 0 |
141 | spte.Accessed = 1 |
147 | old_spte = *spte; | |
153 | spte = 0ull; | |
157 | | spte.W = 1 |
159 | | memory write on the spte:: |
161 | | spte.Dirty = 1 |
166 | old_spte = xchg(spte, 0ull) | |
168 | kvm_set_pfn_accessed(spte.pfn);| |
170 | kvm_set_pfn_dirty(spte.pfn); | |
176 In order to avoid this kind of issue, we always treat the spte as "volatile"
178 the spte is always atomically updated in this case.
180 3) flush tlbs due to spte updated
182 If the spte is updated from writable to readonly, we should flush all TLBs,
183 otherwise rmap_write_protect will find a read-only spte, even though the
184 writable spte might be cached on a CPU's TLB.
186 As mentioned before, the spte can be updated to writable out of mmu-lock on
189 function to update spte (present -> present).
191 Since the spte is "volatile" if it can be updated out of mmu-lock, we always
192 atomically update the spte, the race caused by fast page fault can be avoided,