virt/kvm/locking.rst

39    the spte.
42 SPTE_MMU_WRITEABLE bit on the spte:
49 On fast page fault path, we will use cmpxchg to atomically set the spte W
50 bit if spte.SPTE_HOST_WRITEABLE = 1 and spte.SPTE_WRITE_PROTECT = 1, or
67 |	spte is the shadow page table entry corresponding with gpte and  |
68 |	spte = pfn1                                                      |
76 |   old_spte = *spte;                |                                   |
80 |                                    |    spte = 0;                      |
87 |                                    |    spte = pfn1;                   |
91 |   if (cmpxchg(spte, old_spte, old_spte+W)                              |
98 For direct sp, we can easily avoid it since the spte of direct sp is fixed
113 In the origin code, the spte can be fast updated (non-atomically) if the
114 spte is read-only and the Accessed bit has already been set since the
117 But it is not true after fast page fault since the spte can be marked
118 writable between reading spte and updating spte. Like below case:
123 |	spte.W = 0                                                       |
124 |	spte.Accessed = 1                                                |
130 |  old_spte = *spte;                 |                                   |
136 |     spte = 0ull;                   |                                   |
140 |                                    |    spte.W = 1                     |
142 |                                    | memory write on the spte::        |
144 |                                    |    spte.Dirty = 1                 |
149 |     old_spte = xchg(spte, 0ull)    |                                   |
151 |     kvm_set_pfn_accessed(spte.pfn);|                                   |
153 |     kvm_set_pfn_dirty(spte.pfn);   |                                   |
159 In order to avoid this kind of issue, we always treat the spte as "volatile"
161 the spte is always atomically updated in this case.
163 3) flush tlbs due to spte updated
165 If the spte is updated from writable to readonly, we should flush all TLBs,
166 otherwise rmap_write_protect will find a read-only spte, even though the
167 writable spte might be cached on a CPU's TLB.
169 As mentioned before, the spte can be updated to writable out of mmu-lock on
172 function to update spte (present -> present).
174 Since the spte is "volatile" if it can be updated out of mmu-lock, we always
175 atomically update the spte, the race caused by fast page fault can be avoided,