From nobody Mon Sep 15 04:17:02 2025 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=fail; 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 Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 167387991627926.440037025849165; Mon, 16 Jan 2023 06:38:36 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.478645.741949 (Exim 4.92) (envelope-from ) id 1pHQcX-0002Sf-DT; Mon, 16 Jan 2023 14:37:57 +0000 Received: by outflank-mailman (output) from mailman id 478645.741949; Mon, 16 Jan 2023 14:37:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pHQcX-0002Rt-8S; Mon, 16 Jan 2023 14:37:57 +0000 Received: by outflank-mailman (input) for mailman id 478645; Mon, 16 Jan 2023 14:37:55 +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 1pHQcV-0002Pl-2i for xen-devel@lists.xenproject.org; Mon, 16 Jan 2023 14:37:55 +0000 Received: from casper.infradead.org (casper.infradead.org [2001:8b0:10b:1236::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 5bd6f224-95ab-11ed-91b6-6bf2151ebd3b; Mon, 16 Jan 2023 15:37:53 +0100 (CET) Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1pHQcU-008oZG-So; Mon, 16 Jan 2023 14:37:55 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 56119300C50; Mon, 16 Jan 2023 15:37:39 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 0) id BEB6220D304B0; Mon, 16 Jan 2023 15:37:38 +0100 (CET) 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: 5bd6f224-95ab-11ed-91b6-6bf2151ebd3b DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:References: Subject:Cc:To:From:Date:Message-ID:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:In-Reply-To; bh=eW1eJS20PBPNIc/x7hkOEbhV5Z70C96GEP7VlPQr3GE=; b=bkEUaHzN3DU2Ozeq31w4gh/n2o R6F441bq+sbQaHOybPyF32cPvwYN0zd7oUr9R4K9RCdt8hDgWzWxaj2YBgmp4DkR9+D8F5Gs4dYOt 9lUNiL9h6dmbWadpBSYOt2SznC7hv64myxTtyscypeuWaItFMH/MD2H9N+RHOQ0ha2uXGYbfnTpp+ NghLUZyPGSsWGWKu+nqt7jQ7P4s9CMg2/V9GnkXxMdKljoX9C9dsDu4q8LkBDu52HDGHBkiTsolMw vvwHa2GRba1mlCVFQpftSw0QHpUi6oRrEyKnr2j/V09JyB9VCvK9zjxBViUdKEbhTQhWC7ktrQ+hh hJ6cgCPA==; Message-ID: <20230116143645.888786209@infradead.org> User-Agent: quilt/0.66 Date: Mon, 16 Jan 2023 15:25:39 +0100 From: Peter Zijlstra To: x86@kernel.org, Joan Bruguera Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, Juergen Gross , "Rafael J. Wysocki" , xen-devel , Jan Beulich , Roger Pau Monne , Kees Cook , mark.rutland@arm.com, Andrew Cooper , =?UTF-8?q?J=C3=B6rg=20R=C3=B6del?= , "H. Peter Anvin" Subject: [PATCH v2 6/7] x86/power: Sprinkle some noinstr References: <20230116142533.905102512@infradead.org> MIME-Version: 1.0 X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1673879918854100003 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Ensure no compiler instrumentation sneaks in while restoring the CPU state. Specifically we can't handle CALL/RET until GS is restored. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/power/cpu.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) --- a/arch/x86/power/cpu.c +++ b/arch/x86/power/cpu.c @@ -192,7 +192,7 @@ static void fix_processor_context(void) * The asm code that gets us here will have restored a usable GDT, although * it will be pointing to the wrong alias. */ -static void notrace __restore_processor_state(struct saved_context *ctxt) +static __always_inline void __restore_processor_state(struct saved_context= *ctxt) { struct cpuinfo_x86 *c; =20 @@ -235,6 +235,13 @@ static void notrace __restore_processor_ loadsegment(fs, __KERNEL_PERCPU); #endif =20 + /* + * Definitely wrong, but at this point we should have at least enough + * to do CALL/RET (consider SKL callthunks) and this avoids having + * to deal with the noinstr explosion for now :/ + */ + instrumentation_begin(); + /* Restore the TSS, RO GDT, LDT, and usermode-relevant MSRs. */ fix_processor_context(); =20 @@ -276,10 +283,12 @@ static void notrace __restore_processor_ * because some of the MSRs are "emulated" in microcode. */ msr_restore_context(ctxt); + + instrumentation_end(); } =20 /* Needed by apm.c */ -void notrace restore_processor_state(void) +void noinstr restore_processor_state(void) { __restore_processor_state(&saved_context); }