@@ -9,7 +9,7 @@ KVM Lock Overview
99
1010The acquisition orders for mutexes are as follows:
1111
12- - cpus_read_lock() is taken outside kvm_lock
12+ - cpus_read_lock() is taken outside kvm_lock and kvm_usage_lock
1313
1414- kvm->lock is taken outside vcpu->mutex
1515
@@ -24,6 +24,13 @@ The acquisition orders for mutexes are as follows:
2424 are taken on the waiting side when modifying memslots, so MMU notifiers
2525 must not take either kvm->slots_lock or kvm->slots_arch_lock.
2626
27+ cpus_read_lock() vs kvm_lock:
28+
29+ - Taking cpus_read_lock() outside of kvm_lock is problematic, despite that
30+ being the official ordering, as it is quite easy to unknowingly trigger
31+ cpus_read_lock() while holding kvm_lock. Use caution when walking vm_list,
32+ e.g. avoid complex operations when possible.
33+
2734For SRCU:
2835
2936- ``synchronize_srcu(&kvm->srcu) `` is called inside critical sections
@@ -228,10 +235,17 @@ time it will be set using the Dirty tracking mechanism described above.
228235:Type: mutex
229236:Arch: any
230237:Protects: - vm_list
231- - kvm_usage_count
238+
239+ ``kvm_usage_lock ``
240+ ^^^^^^^^^^^^^^^^^^
241+
242+ :Type: mutex
243+ :Arch: any
244+ :Protects: - kvm_usage_count
232245 - hardware virtualization enable/disable
233- :Comment: KVM also disables CPU hotplug via cpus_read_lock() during
234- enable/disable.
246+ :Comment: Exists because using kvm_lock leads to deadlock (see earlier comment
247+ on cpus_read_lock() vs kvm_lock). Note, KVM also disables CPU hotplug via
248+ cpus_read_lock() when enabling/disabling virtualization.
235249
236250``kvm->mn_invalidate_lock ``
237251^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -291,11 +305,12 @@ time it will be set using the Dirty tracking mechanism described above.
291305 wakeup.
292306
293307``vendor_module_lock ``
294- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
308+ ^^^^^^^^^^^^^^^^^^^^^^
295309:Type: mutex
296310:Arch: x86
297311:Protects: loading a vendor module (kvm_amd or kvm_intel)
298- :Comment: Exists because using kvm_lock leads to deadlock. cpu_hotplug_lock is
299- taken outside of kvm_lock, e.g. in KVM's CPU online/offline callbacks, and
300- many operations need to take cpu_hotplug_lock when loading a vendor module,
301- e.g. updating static calls.
312+ :Comment: Exists because using kvm_lock leads to deadlock. kvm_lock is taken
313+ in notifiers, e.g. __kvmclock_cpufreq_notifier(), that may be invoked while
314+ cpu_hotplug_lock is held, e.g. from cpufreq_boost_trigger_state(), and many
315+ operations need to take cpu_hotplug_lock when loading a vendor module, e.g.
316+ updating static calls.
0 commit comments