linux-kernel - Re: [RFC] x86/kvm: Use native qspinlock by default when realtime hinted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <806e3449-a7b1-fa57-b220-b791428fb28b@loongson.cn>
Date: Wed, 2 Jul 2025 16:19:11 +0800
From: Bibo Mao <maobibo@...ngson.cn>
To: Liangyan <liangyan.peng@...edance.com>, pbonzini@...hat.com,
 vkuznets@...hat.com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, hpa@...or.com
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, kvm@...r.kernel.org
Subject: Re: [RFC] x86/kvm: Use native qspinlock by default when realtime
 hinted



On 2025/7/2 下午2:42, Liangyan wrote:
> When KVM_HINTS_REALTIME is set and KVM_FEATURE_PV_UNHALT is clear,
> currently guest will use virt_spin_lock.
> Since KVM_HINTS_REALTIME is set, use native qspinlock should be safe
> and have better performance than virt_spin_lock.
Just be curious, do you have actual data where native qspinlock has 
better performance than virt_spin_lock()?

By my understanding, qspinlock is not friendly with VM. When lock is 
released, it is acquired with one by one order in contending queue. If 
the first vCPU in contending queue is preempted, the other vCPUs can not 
get lock. On physical machine it is almost impossible that CPU 
contending lock is preempted.

Regards
Bibo Mao
> 
> Signed-off-by: Liangyan <liangyan.peng@...edance.com>
> ---
>   arch/x86/kernel/kvm.c | 18 +++++++++---------
>   1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 921c1c783bc1..9080544a4007 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -1072,6 +1072,15 @@ static void kvm_wait(u8 *ptr, u8 val)
>    */
>   void __init kvm_spinlock_init(void)
>   {
> +	/*
> +	 * Disable PV spinlocks and use native qspinlock when dedicated pCPUs
> +	 * are available.
> +	 */
> +	if (kvm_para_has_hint(KVM_HINTS_REALTIME)) {
> +		pr_info("PV spinlocks disabled with KVM_HINTS_REALTIME hints\n");
> +		goto out;
> +	}
> +
>   	/*
>   	 * In case host doesn't support KVM_FEATURE_PV_UNHALT there is still an
>   	 * advantage of keeping virt_spin_lock_key enabled: virt_spin_lock() is
> @@ -1082,15 +1091,6 @@ void __init kvm_spinlock_init(void)
>   		return;
>   	}
>   
> -	/*
> -	 * Disable PV spinlocks and use native qspinlock when dedicated pCPUs
> -	 * are available.
> -	 */
> -	if (kvm_para_has_hint(KVM_HINTS_REALTIME)) {
> -		pr_info("PV spinlocks disabled with KVM_HINTS_REALTIME hints\n");
> -		goto out;
> -	}
> -
>   	if (num_possible_cpus() == 1) {
>   		pr_info("PV spinlocks disabled, single CPU\n");
>   		goto out;
>