Message ID | 20230414232310.194293270@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp737293vqo; Fri, 14 Apr 2023 17:10:26 -0700 (PDT) X-Google-Smtp-Source: AKy350ZKxljb35v3eUE5QezYAq+ku6ahmdba8AlAAkEsxZZB3svytcPAG+SoxbqNXfTsgpwvzcS+ X-Received: by 2002:a17:90a:e28f:b0:247:4200:7432 with SMTP id d15-20020a17090ae28f00b0024742007432mr3296579pjz.40.1681517426440; Fri, 14 Apr 2023 17:10:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681517426; cv=none; d=google.com; s=arc-20160816; b=y5McttrnUp6+0ltpOP9Nkt8mW9TTPfZspNLNWUgG4tXtqlXY4uvpAZ765ay1Rvfnst KDUBhRhZukUsCBCm76iIa5rw2NELUMkikEYPa1evT56nH0fZb1T4irFrz1+euXtBoCfo RIHWKKA7l7xJ+tOXThXV2ad3ECv2H0PckApbAtVte2Kig7J6/LQm22ouFCmZ97kimmX1 qKMCp2cI7g68365HknFenvNPL7M8ibnqBkSIGhgt4lFzl3THzeZWm0XJKuOWKaqlJTJt MaRmizQ1n6GNZABK22d7XHLz6YiGhX/NTSdcfdhAB8lDETfcA9XQ60giLPwvyj6L2yK/ do/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:date:mime-version:references:subject:cc:to:from :dkim-signature:dkim-signature:message-id; bh=U86WQCD4/7f+Xqtkcp8tab/f3Qs5fwP9mDOYJzY6GfM=; b=VxwfkE62NN0jqCqd0XLfhdK/nor+/hN9tThByMQVsAck+huJhtlqwvCIBzrF7GW45k Hi+9FBm4BTQUM+0jyq8VgkE51SAeN3/rlD4FeQmhrcAOx1wIaRim2tDkUke1Gs20x27C 2GMPorkzXFAlKKx98INenhD9/os6gc5nSq6AFL/wxBmbsmpf2Hp1W7qticpg1OTAaJeK A6tJT3lTa0rZD5yXj9gv5t0gDkgmmVvlaMRqXzn2eLEcmrvSTC+oZSPO17aQSH+nNewK RS3gRwpA0O1opTFPw//vHI4UjuJsjRf0AbMRlPnw/HcBljlLDYGTUi7HTUg8eXeVdEw1 8l7A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=jVIvfWfM; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s32-20020a17090a2f2300b00240d7509eb8si7181578pjd.114.2023.04.14.17.10.11; Fri, 14 Apr 2023 17:10:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=jVIvfWfM; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230179AbjDNXpu (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Fri, 14 Apr 2023 19:45:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230163AbjDNXpS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Apr 2023 19:45:18 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C2D6B476; Fri, 14 Apr 2023 16:44:41 -0700 (PDT) Message-ID: <20230414232310.194293270@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1681515880; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=U86WQCD4/7f+Xqtkcp8tab/f3Qs5fwP9mDOYJzY6GfM=; b=jVIvfWfMQ/Mv7TLWicCCZIBuoCNHTQbWP9agDzTG7YCSq254hUFkclQNrmhW3hMxwO6BPK vpCyMRIt4O1v+XPm4hgw1E/lo8bQ+TLMoWfNV6id2wkbLsusQC6+QgLxHkmM7jqI5M1i8u WMWTwhPBiMRMlROawAHv6lnZ2lJwgt69Ha2d7Hel7C6kpu8UPNf7d9bEsHq2W4HMj8o6m6 dmaviMmKfYNuICvE6NIhMG4fkMK+1VZcm9tvKGIXKcaFCzlTUjXnuorDCoZhFXx/Hy5zi8 WucVMkf4GaCQOYOvuAmNqRgA5o2nLyY6ILSN9/5KO2/baOF9ZKuCj7IpPwPGyQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1681515880; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: references:references; bh=U86WQCD4/7f+Xqtkcp8tab/f3Qs5fwP9mDOYJzY6GfM=; b=bwxgSYDBNDOQrQ9qYJjd5x62eInfveDh14CbqLzga+9pzOoPfQod/ugWmc+ORstEOs2az4 q8XHnTNdR1jM1HBA== From: Thomas Gleixner <tglx@linutronix.de> To: LKML <linux-kernel@vger.kernel.org> Cc: x86@kernel.org, David Woodhouse <dwmw@infradead.org>, Andrew Cooper <andrew.cooper3@citrix.com>, Brian Gerst <brgerst@gmail.com>, "Arjan van de Veen" <arjan@linux.intel.com>, Paolo Bonzini <pbonzini@redhat.com>, Paul McKenney <paulmck@kernel.org>, Tom Lendacky <thomas.lendacky@amd.com>, Sean Christopherson <seanjc@google.com>, Oleksandr Natalenko <oleksandr@natalenko.name>, Paul Menzel <pmenzel@molgen.mpg.de>, "Guilherme G. Piccoli" <gpiccoli@igalia.com>, Piotr Gorski <lucjan.lucjanov@gmail.com>, Juergen Gross <jgross@suse.com>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xenproject.org, David Woodhouse <dwmw@amazon.co.uk>, Usama Arif <usama.arif@bytedance.com>, Russell King <linux@armlinux.org.uk>, Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Guo Ren <guoren@kernel.org>, linux-csky@vger.kernel.org, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, linux-mips@vger.kernel.org, "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>, Helge Deller <deller@gmx.de>, linux-parisc@vger.kernel.org, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, linux-riscv@lists.infradead.org, Mark Rutland <mark.rutland@arm.com>, Sabin Rapan <sabrapan@amazon.com> Subject: [patch 16/37] x86/xen/smp_pv: Remove wait for CPU online References: <20230414225551.858160935@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Date: Sat, 15 Apr 2023 01:44:39 +0200 (CEST) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763198817069863856?= X-GMAIL-MSGID: =?utf-8?q?1763198817069863856?= |
Series |
cpu/hotplug, x86: Reworked parallel CPU bringup
|
|
Commit Message
Thomas Gleixner
April 14, 2023, 11:44 p.m. UTC
Now that the core code drops sparse_irq_lock after the idle thread
synchronized, it's pointless to wait for the AP to mark itself online.
Whether the control CPU runs in a wait loop or sleeps in the core code
waiting for the online operation to complete makes no difference.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/smp_pv.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Comments
On 4/14/23 7:44 PM, Thomas Gleixner wrote: > Now that the core code drops sparse_irq_lock after the idle thread > synchronized, it's pointless to wait for the AP to mark itself online. > > Whether the control CPU runs in a wait loop or sleeps in the core code > waiting for the online operation to complete makes no difference. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Cc: Juergen Gross <jgross@suse.com> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > Cc: xen-devel@lists.xenproject.org > --- > arch/x86/xen/smp_pv.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > --- a/arch/x86/xen/smp_pv.c > +++ b/arch/x86/xen/smp_pv.c > @@ -340,11 +340,11 @@ static int xen_pv_cpu_up(unsigned int cp > > xen_pmu_init(cpu); > > - rc = HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL); > - BUG_ON(rc); > - > - while (cpu_report_state(cpu) != CPU_ONLINE) > - HYPERVISOR_sched_op(SCHEDOP_yield, NULL); > + /* > + * Why is this a BUG? If the hypercall fails then everything can be > + * rolled back, no? > + */ In many cases this indicates either some sort of hypervisor internal error or broken logic in the guest, so it is, well, a bug. But I suppose it may also be some transient condition in the hypervisor (I don't see it now but it can happen in the future) so perhaps we should indeed try not to die on the spot. -boris > + BUG_ON(HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL)); > > return 0; > } >
--- a/arch/x86/xen/smp_pv.c +++ b/arch/x86/xen/smp_pv.c @@ -340,11 +340,11 @@ static int xen_pv_cpu_up(unsigned int cp xen_pmu_init(cpu); - rc = HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL); - BUG_ON(rc); - - while (cpu_report_state(cpu) != CPU_ONLINE) - HYPERVISOR_sched_op(SCHEDOP_yield, NULL); + /* + * Why is this a BUG? If the hypercall fails then everything can be + * rolled back, no? + */ + BUG_ON(HYPERVISOR_vcpu_op(VCPUOP_up, xen_vcpu_nr(cpu), NULL)); return 0; }