Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C03AFC64EC4 for ; Wed, 22 Feb 2023 09:49:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232279AbjBVJtZ (ORCPT ); Wed, 22 Feb 2023 04:49:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232305AbjBVJsj (ORCPT ); Wed, 22 Feb 2023 04:48:39 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C00FA234DC; Wed, 22 Feb 2023 01:46:53 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1677059186; 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: in-reply-to:in-reply-to:references:references; bh=lX7t4eNJpUd+FIylBrybVCZctPOCrlFQiVjFX2fFY+o=; b=u+ppGWmucKqpOWHmZ+NLpxavWBcEqSJst3Yn6S3sCmOef2TnWaNJXO/sZGTROz3ApcDQLo SJhAzjVFrg/C+IThgMV5rsDTFFRb70Ly8Yh07b93P3/mP4nAzeYAUekMtwQSO+NO2NVC/I P8RLqBXRlSRsKgSqvrEbcCe6Xng5yHfRPAqOhZR2XFoAaqJeQhA8voAmYWifS6KcNyUPkP 7cNNaRNMq3BToTBbBJs22begklQfppjwu7QUkErAWGBCilo4kmjBPVdvJYBYTiwYAXVppp NAAIzUVPWPVRV1qADuKB2C0fv0B492k2UwQ0LbdJBQ0XMW73LTKmnEuBZtqg9Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1677059186; 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: in-reply-to:in-reply-to:references:references; bh=lX7t4eNJpUd+FIylBrybVCZctPOCrlFQiVjFX2fFY+o=; b=jjPZw4ffdEwKY0XAY8DQfZ+9766w086OXQYFuDwgITe7wnvW5Af7B82bqySUquV/ekSq6g 7mb5Dv1MA25iXXBQ== To: David Woodhouse , Usama Arif , Oleksandr Natalenko Cc: Kim Phillips , arjan@linux.intel.com, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, x86@kernel.org, pbonzini@redhat.com, paulmck@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, rcu@vger.kernel.org, mimoja@mimoja.de, hewenliang4@huawei.com, thomas.lendacky@amd.com, seanjc@google.com, pmenzel@molgen.mpg.de, fam.zheng@bytedance.com, punit.agrawal@bytedance.com, simon.evans@bytedance.com, liangma@liangbit.com, "Limonciello, Mario" , Piotr Gorski Subject: Re: [External] Re: [PATCH v9 0/8] Parallel CPU bringup for x86_64 In-Reply-To: References: <20230215145425.420125-1-usama.arif@bytedance.com> <42dc683e2846ae8fc1e09715aaf7884660e1a386.camel@infradead.org> <37c18c3aeea2e558633b6da6886111d0@natalenko.name> <5A3B7074-0C6D-472B-803B-D76541828C1F@infradead.org> <3d8ed6e157df10c5175c636de0e21849@natalenko.name> <5c557f9b6f55dc2a612ee89142971298e6ae12d8.camel@infradead.org> <5b8f9c89f7015fa80c966c6c7f6fa259db6744f8.camel@infradead.org> <85ceb3f92abf3c013924de2f025517372bed19c0.camel@infradead.org> <3e5944de08ef0d23584d19bad7bae66c@natalenko.name> <26E5DC9C-0F19-4E4F-9076-04506A197374@infradead.org> <10CA27BB-ADC6-4421-86D2-A83BD7FA12E0@infradead.org> <9153284c37a79d303aa79dbf07c10329@natalenko.name> <87356yofw3.ffs@tglx> <11cc090b-82aa-f2f5-0f08-b8e63e662947@bytedance.com> Date: Wed, 22 Feb 2023 10:46:25 +0100 Message-ID: <87cz62m3ri.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 22 2023 at 08:19, David Woodhouse wrote: > But the BSP/CPU0 is different. It hasn't actually been taken offline, > and its idle thread context is still in cpu_startup_entry(CPUHP_ONLINE) > which got called from rest_init(). > > In testing I probably got away with it because we're only using the > *top* of the stack, don't use anything of the red zone, and thus don't > actually bother the true idle thread which is never going to return. :) > But I don't think it's correct; we really ought to have that temp_stack > unless we're going to refactor the wakeup_64 code to *become* the idle > thread just as startup_secondary() does, and *schedule* to the context > that was saved in the suspend code. And thereby messing up the scheduler state... Thanks, tglx