Lines Matching +full:fast +full:- +full:read
1 .. SPDX-License-Identifier: GPL-2.0
8 ---------------------
12 - kvm->lock is taken outside vcpu->mutex
14 - kvm->lock is taken outside kvm->slots_lock and kvm->irq_lock
16 - kvm->slots_lock is taken outside kvm->irq_lock, though acquiring
19 - Unlike kvm->slots_lock, kvm->slots_arch_lock is released before
20 synchronize_srcu(&kvm->srcu). Therefore kvm->slots_arch_lock
21 can be taken inside a kvm->srcu read-side critical section,
22 while kvm->slots_lock cannot.
24 - kvm->mn_active_invalidate_count ensures that pairs of
26 use the same memslots array. kvm->slots_lock and kvm->slots_arch_lock
28 must not take either kvm->slots_lock or kvm->slots_arch_lock.
32 - vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock
34 - kvm->arch.mmu_lock is an rwlock. kvm->arch.tdp_mmu_pages_lock and
35 kvm->arch.mmu_unsync_pages_lock are taken inside kvm->arch.mmu_lock, and
36 cannot be taken without already holding kvm->arch.mmu_lock (typically with
43 ------------
45 Fast page fault:
47 Fast page fault is the fast path which fixes the guest page fault out of
48 the mmu-lock on x86. Currently, the page fault can be fast in one of the
55 2. Write-Protection: The SPTE is present and the fault is caused by
56 write-protect. That means we just need to change the W bit of the spte.
58 What we use to avoid all the race is the Host-writable bit and MMU-writable bit
61 - Host-writable means the gfn is writable in the host kernel page tables and in
63 - MMU-writable means the gfn is writable in the guest's mmu and it is not
64 write-protected by shadow page write-protection.
66 On fast page fault path, we will use cmpxchg to atomically set the spte W
68 R/X bits if for an access-traced spte, or both. This is safe because whenever
79 +------------------------------------------------------------------------+
86 +------------------------------------------------------------------------+
87 | On fast page fault path: |
88 +------------------------------------+-----------------------------------+
90 +------------------------------------+-----------------------------------+
94 +------------------------------------+-----------------------------------+
99 | | pfn1 is re-alloced for gfn2. |
105 +------------------------------------+-----------------------------------+
109 | mark_page_dirty(vcpu->kvm, gfn1) |
111 +------------------------------------------------------------------------+
113 We dirty-log for gfn1, that means gfn2 is lost in dirty-bitmap.
116 to gfn. For indirect sp, we disabled fast page fault for simplicity.
121 - We have held the refcount of pfn that means the pfn can not be freed and
123 - The pfn is writable and therefore it cannot be shared between different gfns
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
137 +------------------------------------------------------------------------+
142 +------------------------------------+-----------------------------------+
144 +------------------------------------+-----------------------------------+
154 +------------------------------------+-----------------------------------+
155 | | on fast page fault path:: |
162 +------------------------------------+-----------------------------------+
172 +------------------------------------+-----------------------------------+
177 if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means,
183 otherwise rmap_write_protect will find a read-only spte, even though the
186 As mentioned before, the spte can be updated to writable out of mmu-lock on
187 fast page fault path, in order to easily audit the path, we see if TLBs need
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,
200 kvm_mmu_notifier_clear_flush_young), it marks the PTE not-present in hardware
203 generated and the fast page fault mechanism described above is used to
211 ------------
218 :Protects: - vm_list
225 :Protects: - hardware virtualization enable/disable
229 ``kvm->mn_invalidate_lock``
241 :Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset}
242 - tsc offset in vmcb
245 ``kvm->mmu_lock``
249 :Protects: -shadow page/shadow tlb entry
252 ``kvm->srcu``
256 :Protects: - kvm->memslots
257 - kvm->buses
258 :Comment: The srcu read lock must be held while accessing memslots (e.g.
259 when using gfn_to_* functions) and while accessing in-kernel
260 MMIO/PIO address->device structure mapping (kvm->buses).
261 The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu
264 ``kvm->slots_arch_lock``
268 :Protects: any arch-specific fields of memslots that have to be modified
269 in a ``kvm->srcu`` read-side critical section.
278 :Comment: This is a per-CPU lock and it is used for VT-d posted-interrupts.
279 When VT-d posted-interrupts is supported and the VM has assigned
281 protected by blocked_vcpu_on_cpu_lock, when VT-d hardware issues