Lines Matching refs:spte

17 we just need change the W bit of the spte.
20 SPTE_MMU_WRITEABLE bit on the spte:
26 On fast page fault path, we will use cmpxchg to atomically set the spte W
27 bit if spte.SPTE_HOST_WRITEABLE = 1 and spte.SPTE_WRITE_PROTECT = 1, this
39 spte is the shadow page table entry corresponding with gpte and
40 spte = pfn1
45    old_spte = *spte;
47                                     spte = 0;
53                                     spte = pfn1;
55    if (cmpxchg(spte, old_spte, old_spte+W)
61 For direct sp, we can easily avoid it since the spte of direct sp is fixed
75 In the origin code, the spte can be fast updated (non-atomically) if the
76 spte is read-only and the Accessed bit has already been set since the
79 But it is not true after fast page fault since the spte can be marked
80 writable between reading spte and updating spte. Like below case:
83 spte.W = 0
84 spte.Accessed = 1
89    old_spte = *spte;
94       spte = 0ull;
96                                              spte.W = 1
97                                          memory write on the spte:
98                                              spte.Dirty = 1
102       old_spte = xchg(spte, 0ull)
106       kvm_set_pfn_accessed(spte.pfn);
108       kvm_set_pfn_dirty(spte.pfn);
113 In order to avoid this kind of issue, we always treat the spte as "volatile"
115 the spte is always atomically updated in this case.
117 3): flush tlbs due to spte updated
118 If the spte is updated from writable to readonly, we should flush all TLBs,
119 otherwise rmap_write_protect will find a read-only spte, even though the
120 writable spte might be cached on a CPU's TLB.
122 As mentioned before, the spte can be updated to writable out of mmu-lock on
125 function to update spte (present -> present).
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,