From: Chen Yu <yu.c.chen@intel.com>
To: maobibo <maobibo@loongson.cn>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, Arnd Bergmann <arnd@arndb.de>,
<virtualization@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
Juergen Gross <jgross@suse.com>,
"Nikolay Borisov" <nik.borisov@suse.com>,
Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
"Prem Nath Dey" <prem.nath.dey@intel.com>,
Xiaoping Zhou <xiaoping.zhou@intel.com>
Subject: Re: [PATCH v4] x86/paravirt: Disable virt spinlock on bare metal
Date: Thu, 1 Aug 2024 22:40:26 +0800 [thread overview]
Message-ID: <ZqueWhX6lqS+1vwg@chenyu5-mobl2> (raw)
In-Reply-To: <4d31e1b4-2113-c557-b60a-3a45b2840f26@loongson.cn>
Hi Bibo,
On 2024-08-01 at 16:00:19 +0800, maobibo wrote:
> Chenyu,
>
> I do not know much about x86, just give some comments(probably incorrected)
> from the code.
>
> On 2024/7/29 下午2:52, Chen Yu wrote:
> > X86_FEATURE_HYPERVISOR Y Y Y N
> > CONFIG_PARAVIRT_SPINLOCKS Y Y N Y/N
> > PV spinlock Y N N Y/N
> >
> > virt_spin_lock_key N N Y N
> >
> > -DECLARE_STATIC_KEY_TRUE(virt_spin_lock_key);
> > +DECLARE_STATIC_KEY_FALSE(virt_spin_lock_key);
>
> @@ -87,7 +87,7 @@ static inline bool virt_spin_lock(struct qspinlock *lock)
> {
> int val;
>
> - if (!static_branch_likely(&virt_spin_lock_key))
> + if (!static_branch_unlikely(&virt_spin_lock_key))
> return false;
>
> Do we need change it with static_branch_unlikely() if value of key is false
> by fault?
My understanding is that, firstly, whether it is likely() or unlikely()
depends on the 'expected' value of the key, rather than its default
initialized value. The compiler can arrange the if 'jump' condition to
avoid the overhead of branch jump(to keep the instruction pipeline)
as much as possible. Secondly, before this patch, the 'expected' value
of virt_spin_lock_key is 'true', so I'm not sure if we should change
its behavior. Although it seems that in most VM guest, with para-virt
spinlock enabled, this key should be false at most time, but just in
case of any regression...
> > /*
> > * Shortcut for the queued_spin_lock_slowpath() function that allows
> > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> > index 5358d43886ad..fec381533555 100644
> > --- a/arch/x86/kernel/paravirt.c
> > +++ b/arch/x86/kernel/paravirt.c
> > @@ -51,13 +51,12 @@ DEFINE_ASM_FUNC(pv_native_irq_enable, "sti", .noinstr.text);
> > DEFINE_ASM_FUNC(pv_native_read_cr2, "mov %cr2, %rax", .noinstr.text);
> > #endif
> > -DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
> > +DEFINE_STATIC_KEY_FALSE(virt_spin_lock_key);
> > void __init native_pv_lock_init(void)
> > {
> > - if (IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS) &&
> > - !boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > - static_branch_disable(&virt_spin_lock_key);
> > + if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > + static_branch_enable(&virt_spin_lock_key);
> > }
>
> From my point, the sentence static_branch_disable(&virt_spin_lock_key) can
> be removed in file arch/x86/xen/spinlock.c and arch/x86/kernel/kvm.c, since
> function native_smp_prepare_boot_cpu() is already called by
> xen_smp_prepare_boot_cpu() and kvm_smp_prepare_boot_cpu().
>
The key is enabled by native_smp_prepare_boot_cpu() for VM guest as
the initial value(default to true). And later either arch/x86/xen/spinlock.c
or arch/x86/kernel/kvm.c disable this key in a on-demand manner.
thanks,
Chenyu
next prev parent reply other threads:[~2024-08-01 14:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 6:52 [PATCH v4] x86/paravirt: Disable virt spinlock on bare metal Chen Yu
2024-07-29 12:43 ` Thomas Gleixner
2024-07-29 18:47 ` Chen Yu
2024-07-30 1:21 ` maobibo
2024-07-30 8:46 ` Chen Yu
2024-07-30 9:39 ` maobibo
2024-08-01 8:00 ` maobibo
2024-08-01 14:40 ` Chen Yu [this message]
2024-08-02 1:27 ` maobibo
2024-08-02 7:56 ` Chen Yu
2024-08-02 8:13 ` maobibo
2024-08-02 13:52 ` Chen Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZqueWhX6lqS+1vwg@chenyu5-mobl2 \
--to=yu.c.chen@intel.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maobibo@loongson.cn \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=prem.nath.dey@intel.com \
--cc=qiuxu.zhuo@intel.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux.dev \
--cc=xiaoping.zhou@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox