All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Boris Petkov <bp@suse.de>
Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	xen-devel@lists.xenproject.org, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, jgross@suse.com,
	boris.ostrovsky@oracle.com, luto@kernel.org
Subject: Re: [PATCH][tip] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init()
Date: Fri, 27 Oct 2017 19:09:32 +0200	[thread overview]
Message-ID: <87bmkszfeb.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <B8A2CA08-B52C-46E2-8F47-0ACDE933890D@suse.de> (Boris Petkov's message of "Fri, 27 Oct 2017 18:52:03 +0200")

Boris Petkov <bp@suse.de> writes:

> On October 27, 2017 6:02:00 PM GMT+02:00, Dou Liyang <douly.fnst@cn.fujitsu.com> wrote:
>>Commit:
>>
>>  9043442b43b1 ("locking/paravirt: Use new static key for controlling
>>  call of virt_spin_lock()")
>>
>>set the static virt_spin_lock_key to a value before jump_label_init()
>>has been called, which will result in a WARN().
>>
>>Move the native_pv_lock_init() into xx_smp_prepare_cpus(). Make the
>>setup later to avoid the WARN().
>>
>>Reported-by: Juergen Gross <jgross@suse.com>
>>Suggested-by: Juergen Gross <jgross@suse.com>
>>Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
>>---
>> arch/x86/kernel/smpboot.c | 3 ++-
>> arch/x86/xen/smp_pv.c     | 2 ++
>> arch/x86/xen/spinlock.c   | 6 ++++--
>> 3 files changed, 8 insertions(+), 3 deletions(-)
>>
>>diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
>>index aed1460..6b1335a 100644
>>--- a/arch/x86/kernel/smpboot.c
>>+++ b/arch/x86/kernel/smpboot.c
>>@@ -1323,6 +1323,8 @@ void __init native_smp_prepare_cpus(unsigned int
>>max_cpus)
>> 	pr_info("CPU0: ");
>> 	print_cpu_info(&cpu_data(0));
>> 
>>+	native_pv_lock_init();
>>+
>> 	uv_system_init();
>> 
>> 	set_mtrr_aps_delayed_init();
>>@@ -1350,7 +1352,6 @@ void __init native_smp_prepare_boot_cpu(void)
>> 	/* already set me in cpu_online_mask in boot_cpu_init() */
>> 	cpumask_set_cpu(me, cpu_callout_mask);
>> 	cpu_set_state_online(me);
>>-	native_pv_lock_init();
>> }
>> 
>> void __init native_smp_cpus_done(unsigned int max_cpus)
>>diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c
>>index 5147140..570b2bc 100644
>>--- a/arch/x86/xen/smp_pv.c
>>+++ b/arch/x86/xen/smp_pv.c
>>@@ -236,6 +236,8 @@ static void __init xen_pv_smp_prepare_cpus(unsigned
>>int max_cpus)
>> 		xen_raw_printk(m);
>> 		panic(m);
>> 	}
>>+	native_pv_lock_init();
>>+
>> 	xen_init_lock_cpu(0);
>> 
>> 	smp_store_boot_cpu_info();
>>diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
>>index e8ab80a..1e1462d 100644
>>--- a/arch/x86/xen/spinlock.c
>>+++ b/arch/x86/xen/spinlock.c
>>@@ -81,8 +81,11 @@ void xen_init_lock_cpu(int cpu)
>> 	int irq;
>> 	char *name;
>> 
>>-	if (!xen_pvspin)
>>+	if (!xen_pvspin) {
>>+		if (cpu == 0)
>>+			static_branch_disable(&virt_spin_lock_key);
>
> This is assuming CPU 0 is the boot cpu. I think you want boot_cpu_data.cpu_index here or whatever is used on xen to identify the BSP reliably. 

It seems both PV and PVHVM call xen_init_lock_cpu(0) so 0 here is
Linux's idea of CPU id, not Xen's.

In case Xen's idea is needed xen_vcpu_id mapping should be used. But I
don't think it's the case here.

-- 
  Vitaly

  parent reply	other threads:[~2017-10-27 17:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27 16:02 [PATCH][tip] x86/paravirt: Make the virt_spin_lock_key setup after jump_label_init() Dou Liyang
2017-10-27 16:52 ` Boris Petkov
2017-10-27 17:09   ` Vitaly Kuznetsov
2017-10-27 17:09   ` Vitaly Kuznetsov [this message]
2017-10-27 17:25     ` Juergen Gross
2017-10-28 10:55       ` Borislav Petkov
2017-10-28 10:55         ` Borislav Petkov
2017-10-29 12:15         ` Juergen Gross
2017-10-29 12:15         ` Juergen Gross
2017-10-27 17:25     ` Juergen Gross
2017-10-27 16:52 ` Boris Petkov
2017-10-27 17:27 ` Juergen Gross
2017-10-27 17:27 ` Juergen Gross
  -- strict thread matches above, loose matches on Subject: below --
2017-10-27 16:02 Dou Liyang

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=87bmkszfeb.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=douly.fnst@cn.fujitsu.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.