Introduction

This document describes the working principles, application scenarios, environment requirements, and enablement procedure of the virtual machine (VM) lock optimization feature.

The VM lock mechanism safeguards VM resources by restricting access to a single user or process at any given time. However, in overcommitted environments, contention among multiple VMs for the same lock often degrades performance.

The lock optimization feature addresses this issue. The lock optimization feature addresses this issue. When requesting a lock, the guest OS checks shared memory to determine whether the target vCPU is already preempted by another VM. If so, the lock request is canceled. Otherwise, the VM enters a waiting state.

The lock optimization feature uses shared memory to relay vCPU preemption status from the hypervisor to VMs. A spinning vCPU aborts its wait state upon detecting that the lock holder has been preempted, minimizing conflict-induced errors and improving system stability.

1. Upon VM kernel boot, the memory address tracking the preempted state of each vCPU is transferred to the hypervisor via a hypercall.
2. The hypervisor invokes kvm_arch_vcpu_load to load the vCPU context and resets its preempted state to 0 when scheduling a vCPU to run.
3. When the hypervisor halts a vCPU or switches to another, it calls kvm_arch_vcpu_put to save the vCPU context and marks its preempted state as 1.
4. Inside the VM, if a vCPU requesting a lock (such as mutex, rwsem, and osq_lock) detects that the lock-holding vCPU has been scheduled to stop (preempted state is 1), it exits the spin wait state.

The preempted state value tracks whether the vCPU has been preempted on the host. A value of 0 indicates that the hypervisor is actively scheduling the vCPU, while 1 signifies the vCPU has been stopped by the hypervisor.