Documentation/virt/kvm/locking.rst

Source file repositories/reference/linux-study-clean/Documentation/virt/kvm/locking.rst

File Facts

System
Linux kernel
Corpus path
Documentation/virt/kvm/locking.rst
Extension
.rst
Size
14457 bytes
Lines
321
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

=================
KVM Lock Overview
=================

1. Acquisition Orders
---------------------

The acquisition orders for mutexes are as follows:

- cpus_read_lock() is taken outside kvm_lock

- kvm_usage_lock is taken outside cpus_read_lock()

- kvm->lock is taken outside vcpu->mutex

- kvm->lock is taken outside kvm->slots_lock and kvm->irq_lock

- vcpu->mutex is taken outside kvm->slots_lock and kvm->slots_arch_lock

- kvm->slots_lock is taken outside kvm->irq_lock, though acquiring
  them together is quite rare.

- kvm->mn_active_invalidate_count ensures that pairs of
  invalidate_range_start() and invalidate_range_end() callbacks
  use the same memslots array.  kvm->slots_lock and kvm->slots_arch_lock
  are taken on the waiting side when modifying memslots, so MMU notifiers
  must not take either kvm->slots_lock or kvm->slots_arch_lock.

cpus_read_lock() vs kvm_lock:

- Taking cpus_read_lock() outside of kvm_lock is problematic, despite that
  being the official ordering, as it is quite easy to unknowingly trigger
  cpus_read_lock() while holding kvm_lock.  Use caution when walking vm_list,
  e.g. avoid complex operations when possible.

For SRCU:

- ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections
  for kvm->lock, vcpu->mutex and kvm->slots_lock.  These locks _cannot_
  be taken inside a kvm->srcu read-side critical section; that is, the
  following is broken::

      srcu_read_lock(&kvm->srcu);
      mutex_lock(&kvm->slots_lock);

- kvm->slots_arch_lock instead is released before the call to
  ``synchronize_srcu()``.  It _can_ therefore be taken inside a
  kvm->srcu read-side critical section, for example while processing
  a vmexit.

On x86:

- vcpu->mutex is taken outside kvm->arch.hyperv.hv_lock and kvm->arch.xen.xen_lock

- kvm->arch.mmu_lock is an rwlock; critical sections for
  kvm->arch.tdp_mmu_pages_lock and kvm->arch.mmu_unsync_pages_lock must
  also take kvm->arch.mmu_lock

Everything else is a leaf: no other lock is taken inside the critical
sections.

2. Exception
------------

Fast page fault:

Fast page fault is the fast path which fixes the guest page fault out of
the mmu-lock on x86. Currently, the page fault can be fast in one of the

Annotation

Implementation Notes