Lines Matching +full:fast +full:- +full:read
1 .. SPDX-License-Identifier: GPL-2.0
8 ---------------------
12 - cpus_read_lock() is taken outside kvm_lock
14 - kvm_usage_lock is taken outside cpus_read_lock()
16 - kvm->lock is taken outside vcpu->mutex
18 - kvm->lock is taken outside kvm->slots_lock and kvm->irq_lock
20 - kvm->slots_lock is taken outside kvm->irq_lock, though acquiring
23 - kvm->mn_active_invalidate_count ensures that pairs of
25 use the same memslots array. kvm->slots_lock and kvm->slots_arch_lock
27 must not take either kvm->slots_lock or kvm->slots_arch_lock.
31 - Taking cpus_read_lock() outside of kvm_lock is problematic, despite that
38 - ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections
39 for kvm->lock, vcpu->mutex and kvm->slots_lock. These locks _cannot_
40 be taken inside a kvm->srcu read-side critical section; that is, the
43 srcu_read_lock(&kvm->srcu);
44 mutex_lock(&kvm->slots_lock);
46 - kvm->slots_arch_lock instead is released before the call to
48 kvm->srcu read-side critical section, for example while processing
53 - vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock and kvm->arch.xen.xen_lock
55 - kvm->arch.mmu_lock is an rwlock; critical sections for
56 kvm->arch.tdp_mmu_pages_lock and kvm->arch.mmu_unsync_pages_lock must
57 also take kvm->arch.mmu_lock
63 ------------
65 Fast page fault:
67 Fast page fault is the fast path which fixes the guest page fault out of
68 the mmu-lock on x86. Currently, the page fault can be fast in one of the
75 2. Write-Protection: The SPTE is present and the fault is caused by
76 write-protect. That means we just need to change the W bit of the spte.
78 What we use to avoid all the races is the Host-writable bit and MMU-writable bit
81 - Host-writable means the gfn is writable in the host kernel page tables and in
83 - MMU-writable means the gfn is writable in the guest's mmu and it is not
84 write-protected by shadow page write-protection.
86 On fast page fault path, we will use cmpxchg to atomically set the spte W
88 R/X bits if for an access-traced spte, or both. This is safe because whenever
99 +------------------------------------------------------------------------+
106 +------------------------------------------------------------------------+
107 | On fast page fault path: |
108 +------------------------------------+-----------------------------------+
110 +------------------------------------+-----------------------------------+
114 +------------------------------------+-----------------------------------+
119 | | pfn1 is re-alloced for gfn2. |
125 +------------------------------------+-----------------------------------+
129 | mark_page_dirty(vcpu->kvm, gfn1) |
131 +------------------------------------------------------------------------+
133 We dirty-log for gfn1, that means gfn2 is lost in dirty-bitmap.
136 to gfn. For indirect sp, we disabled fast page fault for simplicity.
141 - We have held the refcount of pfn; that means the pfn can not be freed and
143 - The pfn is writable and therefore it cannot be shared between different gfns
150 In the original code, the spte can be fast updated (non-atomically) if the
151 spte is read-only and the Accessed bit has already been set since the
154 But it is not true after fast page fault since the spte can be marked
157 +-------------------------------------------------------------------------+
162 +-------------------------------------+-----------------------------------+
164 +-------------------------------------+-----------------------------------+
174 +-------------------------------------+-----------------------------------+
175 | | on fast page fault path:: |
182 +-------------------------------------+-----------------------------------+
194 +-------------------------------------+-----------------------------------+
199 if it can be updated out of mmu-lock [see spte_has_volatile_bits()]; it means
204 If the spte is updated from writable to read-only, we should flush all TLBs,
205 otherwise rmap_write_protect will find a read-only spte, even though the
208 As mentioned before, the spte can be updated to writable out of mmu-lock on
209 fast page fault path. In order to easily audit the path, we see if TLBs needing
211 function to update spte (present -> present).
213 Since the spte is "volatile" if it can be updated out of mmu-lock, we always
214 atomically update the spte and the race caused by fast page fault can be avoided.
222 kvm_mmu_notifier_clear_flush_young), it marks the PTE not-present in hardware
225 generated and the fast page fault mechanism described above is used to
233 ------------
240 :Protects: - vm_list
247 :Protects: - kvm_usage_count
248 - hardware virtualization enable/disable
252 ``kvm->mn_invalidate_lock``
264 :Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset}
265 - tsc offset in vmcb
268 ``kvm->mmu_lock``
272 :Protects: -shadow page/shadow tlb entry
275 ``kvm->srcu``
279 :Protects: - kvm->memslots
280 - kvm->buses
281 :Comment: The srcu read lock must be held while accessing memslots (e.g.
282 when using gfn_to_* functions) and while accessing in-kernel
283 MMIO/PIO address->device structure mapping (kvm->buses).
284 The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu
287 ``kvm->slots_arch_lock``
291 :Protects: any arch-specific fields of memslots that have to be modified
292 in a ``kvm->srcu`` read-side critical section.
301 :Comment: This is a per-CPU lock and it is used for VT-d posted-interrupts.
302 When VT-d posted-interrupts are supported and the VM has assigned
304 protected by blocked_vcpu_on_cpu_lock. When VT-d hardware issues