From nobody Thu May 2 23:29:28 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=linutronix.de ARC-Seal: i=1; a=rsa-sha256; t=1685443621; cv=none; d=zohomail.com; s=zohoarc; b=QbasZS9P245yhHxWGL0LTib9XnzK0YyHlsOTYALDPwfHift5aKYn9uWXElIDBI0yRFUzONXgnMRRBYxdBxF2nuegulsH6Zy1dfJ1Bbfhu4iThsvURP6032ydh0pP6la8hT50UfHgZX0gZSYcTSK+ayzNEym0UtgZX21Hsst+MxE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1685443621; h=Content-Type:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=aczuPZRXM/3T3zeRyckgFz17tXnOXBoIRzMvbCKmwP4=; b=X1QbYxg09aNP+YX5Xn3+G7O7pEg2gkstuiMJboeWZJ6rThmkSZAltJwaUZ69dYy2N+4Ln+89KXb8dyM9Mu+RJbg7AgJwsdfDfmt1o5lXxonjuVdyYfRz3CA5JRmNs1jNo4DX+urkC2hJuSadL5Mu6aLYae0kv4tUpKc/SYFKBlo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1685443621129798.2281974145598; Tue, 30 May 2023 03:47:01 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.541086.843439 (Exim 4.92) (envelope-from ) id 1q3ws1-00070M-64; Tue, 30 May 2023 10:46:29 +0000 Received: by outflank-mailman (output) from mailman id 541086.843439; Tue, 30 May 2023 10:46:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1q3ws1-00070F-3T; Tue, 30 May 2023 10:46:29 +0000 Received: by outflank-mailman (input) for mailman id 541086; Tue, 30 May 2023 10:46:27 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1q3wrz-000709-DO for xen-devel@lists.xenproject.org; Tue, 30 May 2023 10:46:27 +0000 Received: from galois.linutronix.de (galois.linutronix.de [193.142.43.55]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3977eee4-fed7-11ed-b231-6b7b168915f2; Tue, 30 May 2023 12:46:25 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3977eee4-fed7-11ed-b231-6b7b168915f2 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1685443583; 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=aczuPZRXM/3T3zeRyckgFz17tXnOXBoIRzMvbCKmwP4=; b=jtpE+gCbIAd5N53RxGc6sgaT2si80ubO5trdzq0YZPJgj0u0uGxnEtLhxrdtPRPKOaDE18 ztu5b4k5XEjvK/fjpfaluMv16JvaD5E4Z3L+jqW7tLBl5pCr13VXjUoqvtgyKLd/Y/xqu/ 84SV1UbOvwmhndn5fFxZSGrnlbePrrHSpEQPGnffMATrvpt3ZAkTXG6ylWpzmAYhS4dUem FTBfKKPOVhev4++C/nR20YRFt6jyNNtCz9uhzfOoHg4olSWAigaKti8fg/vEQYtVI0MLbc gP2h3BhbdhTtPHPbM7xx+svbc8m0rHw4UqvtNs/L/faaOGodmpnGf4MovXV/Gg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1685443583; 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=aczuPZRXM/3T3zeRyckgFz17tXnOXBoIRzMvbCKmwP4=; b=Hfhdo2/Q/3z4khc8VnhVtRu45XjAYTmDIx3ynzUXbEbUuJzXZUdsmlA0kYxl32RnfB9UKw 25lgiYCSG2Kzr+Dw== To: "Kirill A. Shutemov" Cc: LKML , x86@kernel.org, David Woodhouse , Andrew Cooper , Brian Gerst , Arjan van de Veen , Paolo Bonzini , Paul McKenney , Tom Lendacky , Sean Christopherson , Oleksandr Natalenko , Paul Menzel , "Guilherme G. Piccoli" , Piotr Gorski , Usama Arif , Juergen Gross , Boris Ostrovsky , xen-devel@lists.xenproject.org, Russell King , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Guo Ren , linux-csky@vger.kernel.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, "James E.J. Bottomley" , Helge Deller , linux-parisc@vger.kernel.org, Paul Walmsley , Palmer Dabbelt , linux-riscv@lists.infradead.org, Mark Rutland , Sabin Rapan , "Michael Kelley (LINUX)" , Dave Hansen Subject: [patch] x86/realmode: Make stack lock work in trampoline_compat() In-Reply-To: <20230529203129.sthnhzgds7ynddxd@box.shutemov.name> References: <20230508181633.089804905@linutronix.de> <20230508185218.962208640@linutronix.de> <20230524204818.3tjlwah2euncxzmh@box.shutemov.name> <87y1lbl7r6.ffs@tglx> <87sfbhlwp9.ffs@tglx> <20230529023939.mc2akptpxcg3eh2f@box.shutemov.name> <87bki3kkfi.ffs@tglx> <20230529203129.sthnhzgds7ynddxd@box.shutemov.name> Date: Tue, 30 May 2023 12:46:22 +0200 Message-ID: <87h6rujdvl.ffs@tglx> MIME-Version: 1.0 X-ZohoMail-DKIM: pass (identity @linutronix.de) X-ZM-MESSAGEID: 1685443622780100001 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The stack locking and stack assignment macro LOAD_REALMODE_ESP fails to work when invoked from the 64bit trampoline entry point: trampoline_start64 trampoline_compat LOAD_REALMODE_ESP <- lock Accessing tr_lock is only possible from 16bit mode. For the compat entry point this needs to be pa_tr_lock so that the required relocation entry is generated. Otherwise it locks the non-relocated address which is aside of being wrong never cleared in secondary_startup_64() causing all but the first CPU to get stuck on the lock. Make the macro take an argument lock_pa which defaults to 0 and rename it to LOCK_AND_LOAD_REALMODE_ESP to make it clear what this is about. Fixes: f6f1ae9128d2 ("x86/smpboot: Implement a bit spinlock to protect the = realmode stack") Reported-by: Kirill A. Shutemov Signed-off-by: Thomas Gleixner Tested-by: Kirill A. Shutemov --- arch/x86/realmode/rm/trampoline_64.S | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/arch/x86/realmode/rm/trampoline_64.S +++ b/arch/x86/realmode/rm/trampoline_64.S @@ -37,12 +37,16 @@ .text .code16 =20 -.macro LOAD_REALMODE_ESP +.macro LOCK_AND_LOAD_REALMODE_ESP lock_pa=3D0 /* * Make sure only one CPU fiddles with the realmode stack */ .Llock_rm\@: + .if \lock_pa + lock btsl $0, pa_tr_lock + .else lock btsl $0, tr_lock + .endif jnc 2f pause jmp .Llock_rm\@ @@ -63,7 +67,7 @@ SYM_CODE_START(trampoline_start) mov %ax, %es mov %ax, %ss =20 - LOAD_REALMODE_ESP + LOCK_AND_LOAD_REALMODE_ESP =20 call verify_cpu # Verify the cpu supports long mode testl %eax, %eax # Check for return code @@ -106,7 +110,7 @@ SYM_CODE_START(sev_es_trampoline_start) mov %ax, %es mov %ax, %ss =20 - LOAD_REALMODE_ESP + LOCK_AND_LOAD_REALMODE_ESP =20 jmp .Lswitch_to_protected SYM_CODE_END(sev_es_trampoline_start) @@ -189,7 +193,7 @@ SYM_CODE_START(pa_trampoline_compat) * In compatibility mode. Prep ESP and DX for startup_32, then disable * paging and complete the switch to legacy 32-bit mode. */ - LOAD_REALMODE_ESP + LOCK_AND_LOAD_REALMODE_ESP lock_pa=3D1 movw $__KERNEL_DS, %dx =20 movl $(CR0_STATE & ~X86_CR0_PG), %eax