Re: [PATCH RFC 01/12] Documentation: KVM: Elaborate comment on kvm_usage_lock
From: Sean Christopherson
Date: Thu Jun 25 2026 - 14:12:28 EST
On Wed, May 27, 2026, Ackerley Tng wrote:
> The original comment talks about cpus_read_lock() and kvm_usage_count, but
> doesn't explain why they are related.
>
> Elaborate comment on kvm_usage_lock to provide more context.
>
> Signed-off-by: Ackerley Tng <ackerleytng@xxxxxxxxxx>
> ---
> Documentation/virt/kvm/locking.rst | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
> index 662231e958a07..5564c8b38b9cc 100644
> --- a/Documentation/virt/kvm/locking.rst
> +++ b/Documentation/virt/kvm/locking.rst
> @@ -248,8 +248,23 @@ time it will be set using the Dirty tracking mechanism described above.
> :Arch: any
> :Protects: - kvm_usage_count
> - hardware virtualization enable/disable
> -:Comment: Exists to allow taking cpus_read_lock() while kvm_usage_count is
> - protected, which simplifies the virtualization enabling logic.
> +:Comment: ``kvm_usage_count`` serves to deduplicate hardware
> + virtualization enabling and disabling requests from different VMs
> + being created.
kvm_usage_count does that and more, i.e. this is 'wrong" by being incomplete.
> +
> + Hardware virtualization enabling/disabling requires taking
> + ``cpus_read_lock()``.
> +
> + ``kvm_lock`` used to also protect ``kvm_usage_count``, but other
> + parts of the Linux kernel holding ``cpus_read_lock()`` need to
> + call into KVM to ensure that VM state remains consistent with the
> + host's state. For example, when the CPU frequency changes, KVM is
> + notified. ``kvmclock_cpufreq_notifier()`` takes ``kvm_lock`` to
> + iterate ``vm_list``.
> +
> + To decouple these, use different locks, ``kvm_lock`` for
> + ``vm_list`` and ``kvm_usage_lock`` for enabling/disabling hardware
> + virtualization.
I appreciate the effort, but honestly I think this does more harm than good. I
already know what this code does, and the above confused me more than anything.
>
> ``kvm->mn_invalidate_lock``
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> --
> 2.54.0.823.g6e5bcc1fc9-goog
>