diff options
| author | Oliver Upton | 2023-02-13 22:28:30 +0000 |
|---|---|---|
| committer | Oliver Upton | 2023-02-13 22:28:34 +0000 |
| commit | 92425e058ab6ab1a4c4a9d384d2d86b810f57e23 (patch) | |
| tree | 612588ba735977d3f5e73c4f7af72769f24bd059 /Documentation | |
| parent | 5dc4c995db9eb45f6373a956eb1f69460e69e6d4 (diff) | |
| parent | 9f1a4c004869d3c8061f286fec4d8096dd099b84 (diff) | |
Merge branch kvm/kvm-hw-enable-refactor into kvmarm/next
Merge the kvm_init() + hardware enable rework to avoid conflicts
with kvmarm.
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/virt/kvm/locking.rst | 25 |
1 files changed, 16 insertions, 9 deletions
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index a0146793d197..14c4e9fa501d 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -9,6 +9,8 @@ KVM Lock Overview The acquisition orders for mutexes are as follows: +- cpus_read_lock() is taken outside kvm_lock + - kvm->lock is taken outside vcpu->mutex - kvm->lock is taken outside kvm->slots_lock and kvm->irq_lock @@ -226,15 +228,10 @@ time it will be set using the Dirty tracking mechanism described above. :Type: mutex :Arch: any :Protects: - vm_list - -``kvm_count_lock`` -^^^^^^^^^^^^^^^^^^ - -:Type: raw_spinlock_t -:Arch: any -:Protects: - hardware virtualization enable/disable -:Comment: 'raw' because hardware enabling/disabling must be atomic /wrt - migration. + - kvm_usage_count + - hardware virtualization enable/disable +:Comment: KVM also disables CPU hotplug via cpus_read_lock() during + enable/disable. ``kvm->mn_invalidate_lock`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -292,3 +289,13 @@ time it will be set using the Dirty tracking mechanism described above. wakeup notification event since external interrupts from the assigned devices happens, we will find the vCPU on the list to wakeup. + +``vendor_module_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +:Type: mutex +:Arch: x86 +:Protects: loading a vendor module (kvm_amd or kvm_intel) +:Comment: Exists because using kvm_lock leads to deadlock. cpu_hotplug_lock is + taken outside of kvm_lock, e.g. in KVM's CPU online/offline callbacks, and + many operations need to take cpu_hotplug_lock when loading a vendor module, + e.g. updating static calls. |