Hi Bibo, On 2024-07-30 at 09:21:45 +0800, maobibo wrote: > Chenyu, > > Sorry to bother you, I am porting pv spinlock to LoongArch platform, I do > not know the history about function virt_spin_lock(). > > When CONFIG_PARAVIRT_SPINLOCKS is enabled, there is pv_enabled() before > virt_spin_lock(), it seems that virt_spin_lock is never called in this > condition. Right, if CONFIG_PARAVIRT_SPINLOCKS is enabled, virt_spin_lock() will not be checked at all and go directly to pv_queue lock section. > if (pv_enabled()) > goto pv_queue; > > if (virt_spin_lock(lock)) > return; > > When CONFIG_PARAVIRT_SPINLOCKS is disabled, there is no pv qspinlock > compiled, so what is the usage about function virt_spin_lock()? > Is it to switch spinlock method from test-set spinlock to qspinlock? > why is there such requirement for spinlock switching method? Firstly, according to the commit 2aa79af64263 ("locking/qspinlock: Revert to test-and-set on hypervisors"), virt_spin_lock() was originally introduced to avoid the over-preemption of native qspinlock(when paravirt-spinlock is disabled). Secondly, there is user requirement to use native qspinlock over test-set lock in the VM. For example, nopvspin parameter is parsed in xen_init_spinlocks(). commit 9043442b43b1 ("locking/paravirt: Use new static key for controlling call of virt_spin_lock()") was introduced to adjust the key from user boot up commandline. so the key switches between test-set and the native qspinlock. I've Cced Juergen and Peter in case I misunderstood. thanks, Chenyu