From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668789; cv=none; d=zohomail.com; s=zohoarc; b=R6ubG501uV4fNscPzyuRV6hn6vGrZ4q9N4hAX7o0dbi32z32y0+laZcG6/c52+hTFBBYwfLdI7ObhCftN7Zc4cuHtBPA8HdDybtfzQUIMhwgksBqMFjabihkQhVWfi/1NVTxtyt6OPQ1yPsShRVLKy5Rpy8YUqpQLyR2aHqfoks= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668789; h=Content-Transfer-Encoding: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=m41IHhIqcT3QTi5OQH6Wl04uozSE0BREiOIXnwM2WFI=; b=hVc5GYixTO4qDD1SWbvny0CASlT9HAvX8fgscHQn0epTqtQAYxbAD7RZ983IBhQ/2P3BU8N/wYzKzoun8PPHlps4ObP9Yw2AvLOH2oB1Y5OWewWppp96asMNPAvzQH1ndCMLXjTiC0HljTnRIiUt+yVRAgWJdt0nkyymfX/rL8o= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 16946687894671018.5633746264425; Wed, 13 Sep 2023 22:19:49 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601774.937977 (Exim 4.92) (envelope-from ) id 1qgel7-0002Gx-F8; Thu, 14 Sep 2023 05:19:21 +0000 Received: by outflank-mailman (output) from mailman id 601774.937977; Thu, 14 Sep 2023 05:19:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel7-0002Gm-Bn; Thu, 14 Sep 2023 05:19:21 +0000 Received: by outflank-mailman (input) for mailman id 601774; Thu, 14 Sep 2023 05:19:19 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel5-0001XI-Nv for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:19 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3e1b3943-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:15 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:29 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:28 -0700 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: 3e1b3943-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668755; x=1726204755; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=5bEJT87B98JS6iQ6LlrNVmLBQuK2BkIiNY3V5ZdVNuo=; b=TZcMfJVVKikul2XGgBirfZ38qdcLXNewEzDWWvl32buFHbfZvHMSAzB3 Oty0PQLPI8K1npLJQB29J2r7L3G3JlxB9m1QeR8uLEZqCN5hISqB5Gsgp jBNQDwvt6HtEzqeHezx3vURXDU0lxVCFrwlFgJaZcvU/hGazGogI5wOPa wYG9YrNmzwFERtNxRu96L/hdzUb5uAZs12ZYvyI9NHABonjkVVzaa+zyI mIRi0i3m65bJoxBqpTPeV7KJ+Gx4Jt8bDGpUCMzeo43vgOjPdFV8ZmNpN 23Vr/WvYzegkDzp5xv2yShynDs6Ut8xoBwRkVSmie+SWuM4GOtBKn+N4h A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661079" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661079" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488736" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488736" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 01/38] x86/cpufeatures: Add the cpu feature bit for WRMSRNS Date: Wed, 13 Sep 2023 21:47:28 -0700 Message-Id: <20230914044805.301390-2-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668790865100001 Content-Type: text/plain; charset="utf-8" WRMSRNS is an instruction that behaves exactly like WRMSR, with the only difference being that it is not a serializing instruction by default. Under certain conditions, WRMSRNS may replace WRMSR to improve performance. Add the CPU feature bit for WRMSRNS. Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/cpufeatures.h | 1 + tools/arch/x86/include/asm/cpufeatures.h | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpuf= eatures.h index 58cb9495e40f..330876d34b68 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -322,6 +322,7 @@ #define X86_FEATURE_FSRS (12*32+11) /* "" Fast short REP STOSB */ #define X86_FEATURE_FSRC (12*32+12) /* "" Fast short REP {CMPSB,SCASB} */ #define X86_FEATURE_LKGS (12*32+18) /* "" Load "kernel" (userspace) GS */ +#define X86_FEATURE_WRMSRNS (12*32+19) /* "" Non-Serializing Write to Mod= el Specific Register instruction */ #define X86_FEATURE_AMX_FP16 (12*32+21) /* "" AMX fp16 Support */ #define X86_FEATURE_AVX_IFMA (12*32+23) /* "" Support for VPMAD= D52[H,L]UQ */ #define X86_FEATURE_LAM (12*32+26) /* Linear Address Masking */ diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/incl= ude/asm/cpufeatures.h index 798e60b5454b..1b9d86ba5bc2 100644 --- a/tools/arch/x86/include/asm/cpufeatures.h +++ b/tools/arch/x86/include/asm/cpufeatures.h @@ -318,6 +318,7 @@ #define X86_FEATURE_FSRS (12*32+11) /* "" Fast short REP STOSB */ #define X86_FEATURE_FSRC (12*32+12) /* "" Fast short REP {CMPSB,SCASB} */ #define X86_FEATURE_LKGS (12*32+18) /* "" Load "kernel" (userspace) GS */ +#define X86_FEATURE_WRMSRNS (12*32+19) /* "" Non-Serializing Write to Mod= el Specific Register instruction */ #define X86_FEATURE_AMX_FP16 (12*32+21) /* "" AMX fp16 Support */ #define X86_FEATURE_AVX_IFMA (12*32+23) /* "" Support for VPMAD= D52[H,L]UQ */ #define X86_FEATURE_LAM (12*32+26) /* Linear Address Masking */ --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668796; cv=none; d=zohomail.com; s=zohoarc; b=HYbtTWdQrdxqjeH0crY6NHd409Y/HMe/b1Lnu80KI9lQ+gD2LRVpDYBnrPtTKteLyimHjfPJKYd2jCDNgN1aEas9SKYH0GhADWGuB/OfUN85DyMoO0zwv25/cK0EnQnAZH4UiHz6491OtN7YuUHgnoDMbrc8QrUNBpZhlzOeaY8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668796; h=Content-Transfer-Encoding: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=K35JdKi40xmFJgm7eFRtjHX2c2tFTmzli8iveDXSdgM=; b=LT3hktojWTWYpb9qXpDXtjpCQwP5eRxePA11OdnTrFgGc8fq8X8r0CkBbHOqsHEHfggPEtFPD/SteAixRZ9g4rMWbmYTf6aQXHj1kID63+pKw9XvZLM0BNDXq5xsjQtn8AvX8eBfkY34Qg8j2162DT0t2GV28rXWG67Tthqg0M0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668796284252.19050290690507; Wed, 13 Sep 2023 22:19:56 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601772.937953 (Exim 4.92) (envelope-from ) id 1qgel4-0001ZP-Ul; Thu, 14 Sep 2023 05:19:18 +0000 Received: by outflank-mailman (output) from mailman id 601772.937953; Thu, 14 Sep 2023 05:19:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel4-0001Yj-PH; Thu, 14 Sep 2023 05:19:18 +0000 Received: by outflank-mailman (input) for mailman id 601772; Thu, 14 Sep 2023 05:19:17 +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 1qgel3-0001X7-5c for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:17 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 3f7bdddf-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:16 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:30 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:29 -0700 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: 3f7bdddf-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668756; x=1726204756; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kr0CN67v2SsYJemD+2TL2DrONkvf6IluzdZd2yzKUPQ=; b=ezwGlEpHYeeZ/0Idm88wug8+t++G2vPBEpedG3NQapaU3ygxRmoqwxOJ 75w29q7zPmCj8hE6n1W3T3ZOhAnXs9noar78zRvbBgcuclheWQBIylIOv bNEtLEr5ssNllwGHvb8IYNu+OwucG56m8oJTv0AKgPEK9GxPZeVwhRkmT cmKvCzGPHeIMTDvhgfjW31azofYaEHeLEhCatEWF6+z/CsCmT/bgNIeD1 m+GcN1K3lPjiDynCch986JkHJiae5wUKCyFTFJBl2nOpfDUZSkDSWzYYs w+ztFmo7gZMpBuYNhwy8F6wIyhijnWuRu0QQhom21tgFGWGDO1yRrucTv Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661091" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661091" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488739" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488739" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 02/38] x86/opcode: Add the WRMSRNS instruction to the x86 opcode map Date: Wed, 13 Sep 2023 21:47:29 -0700 Message-Id: <20230914044805.301390-3-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668797477100006 Content-Type: text/plain; charset="utf-8" Add the opcode used by WRMSRNS, which is the non-serializing version of WRMSR and may replace it to improve performance, to the x86 opcode map. Tested-by: Shan Kang Signed-off-by: Xin Li Acked-by: Masami Hiramatsu (Google) --- arch/x86/lib/x86-opcode-map.txt | 2 +- tools/arch/x86/lib/x86-opcode-map.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.= txt index 5168ee0360b2..1efe1d9bf5ce 100644 --- a/arch/x86/lib/x86-opcode-map.txt +++ b/arch/x86/lib/x86-opcode-map.txt @@ -1051,7 +1051,7 @@ GrpTable: Grp6 EndTable =20 GrpTable: Grp7 -0: SGDT Ms | VMCALL (001),(11B) | VMLAUNCH (010),(11B) | VMRESUME (011),(1= 1B) | VMXOFF (100),(11B) | PCONFIG (101),(11B) | ENCLV (000),(11B) +0: SGDT Ms | VMCALL (001),(11B) | VMLAUNCH (010),(11B) | VMRESUME (011),(1= 1B) | VMXOFF (100),(11B) | PCONFIG (101),(11B) | ENCLV (000),(11B) | WRMSRN= S (110),(11B) 1: SIDT Ms | MONITOR (000),(11B) | MWAIT (001),(11B) | CLAC (010),(11B) | = STAC (011),(11B) | ENCLS (111),(11B) 2: LGDT Ms | XGETBV (000),(11B) | XSETBV (001),(11B) | VMFUNC (100),(11B) = | XEND (101)(11B) | XTEST (110)(11B) | ENCLU (111),(11B) 3: LIDT Ms diff --git a/tools/arch/x86/lib/x86-opcode-map.txt b/tools/arch/x86/lib/x86= -opcode-map.txt index 5168ee0360b2..1efe1d9bf5ce 100644 --- a/tools/arch/x86/lib/x86-opcode-map.txt +++ b/tools/arch/x86/lib/x86-opcode-map.txt @@ -1051,7 +1051,7 @@ GrpTable: Grp6 EndTable =20 GrpTable: Grp7 -0: SGDT Ms | VMCALL (001),(11B) | VMLAUNCH (010),(11B) | VMRESUME (011),(1= 1B) | VMXOFF (100),(11B) | PCONFIG (101),(11B) | ENCLV (000),(11B) +0: SGDT Ms | VMCALL (001),(11B) | VMLAUNCH (010),(11B) | VMRESUME (011),(1= 1B) | VMXOFF (100),(11B) | PCONFIG (101),(11B) | ENCLV (000),(11B) | WRMSRN= S (110),(11B) 1: SIDT Ms | MONITOR (000),(11B) | MWAIT (001),(11B) | CLAC (010),(11B) | = STAC (011),(11B) | ENCLS (111),(11B) 2: LGDT Ms | XGETBV (000),(11B) | XSETBV (001),(11B) | VMFUNC (100),(11B) = | XEND (101)(11B) | XTEST (110)(11B) | ENCLU (111),(11B) 3: LIDT Ms --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668793; cv=none; d=zohomail.com; s=zohoarc; b=HjL6HR0W778QmYj1OSDvieSvwA/dYvya8/AouS3RdlYGOaIK5i49Q5Oxa3AfPjNPS22EDYBNnwk4jxQK2gLgdbcLmWkiEV/Z6gj9HiL2sHMax+mJDPFQY0AzSVDPmnOWu1ru88snvnqRNqF5ycbbotl1eo+9nU4HnXxbyqftYpA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668793; h=Content-Transfer-Encoding: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=xG97vMcGypvclr6yOfUWfM/r9FH+1JlNHHDd3KQor8o=; b=G8JQJTO7sho2/yUbKx5rK5//jZOLZa0IuWTjmvnnI3zAFe8EnPiciCaRpkoVB+rgL3euWc+U6hFHgJbB4WLpjSqYN88df8zDKX+k2ef7cjp2jpvXspeqo+x0PxqTo13pbh0n3lT0JwuwN0ON86nplfsRHFjtfxwTKN5JCA1y61c= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668793201342.75412329899325; Wed, 13 Sep 2023 22:19:53 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601776.937990 (Exim 4.92) (envelope-from ) id 1qgel8-0002Sd-Aa; Thu, 14 Sep 2023 05:19:22 +0000 Received: by outflank-mailman (output) from mailman id 601776.937990; Thu, 14 Sep 2023 05:19:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel8-0002Rd-2q; Thu, 14 Sep 2023 05:19:22 +0000 Received: by outflank-mailman (input) for mailman id 601776; Thu, 14 Sep 2023 05:19:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel5-0001XI-Uu for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:19 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3f0a52cb-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:16 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:30 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:30 -0700 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: 3f0a52cb-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668756; x=1726204756; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9qsPaAmdkqHl0KD85EKfAfnheAb+UY4gBzEbjksg7Tw=; b=nRUHIN0Mlmrz2tja9fiX4yuhSrC5RBbkI1D7fprYxzF71NHxt4nHitE9 bY3otDvfT6egW1MvqpVPVRJz6BV6b10X6zxBJdEaMCZLF3GKQYLRAXi7k +edHcA9DB0+xfp8tQLWEjDEgZpbC/OFrXPfGEpoCyZGSE62npLGfrrNbH Hsui4Ska3mEAzYsn9C0S8yi9yCwqZ+lULF11VGu7j0RMMn4GSk0eGShCI TxEvkPO/uw3WVQLXGSpNE8ooSa/bZCfVv3DevBDfVptutU33OgV58J5gS 71rEUA0orW1RqO1lJKSxCh7bgW1QdOQ0eySOPjcTdnAN9Ogene1lkbsdB A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661106" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661106" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488743" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488743" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 03/38] x86/msr: Add the WRMSRNS instruction support Date: Wed, 13 Sep 2023 21:47:30 -0700 Message-Id: <20230914044805.301390-4-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668793549100001 Content-Type: text/plain; charset="utf-8" Add an always inline API __wrmsrns() to embed the WRMSRNS instruction into the code. Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/msr.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h index 65ec1965cd28..c284ff9ebe67 100644 --- a/arch/x86/include/asm/msr.h +++ b/arch/x86/include/asm/msr.h @@ -97,6 +97,19 @@ static __always_inline void __wrmsr(unsigned int msr, u3= 2 low, u32 high) : : "c" (msr), "a"(low), "d" (high) : "memory"); } =20 +/* + * WRMSRNS behaves exactly like WRMSR with the only difference being + * that it is not a serializing instruction by default. + */ +static __always_inline void __wrmsrns(u32 msr, u32 low, u32 high) +{ + /* Instruction opcode for WRMSRNS; supported in binutils >=3D 2.40. */ + asm volatile("1: .byte 0x0f,0x01,0xc6\n" + "2:\n" + _ASM_EXTABLE_TYPE(1b, 2b, EX_TYPE_WRMSR) + : : "c" (msr), "a"(low), "d" (high)); +} + #define native_rdmsr(msr, val1, val2) \ do { \ u64 __val =3D __rdmsr((msr)); \ @@ -297,6 +310,11 @@ do { \ =20 #endif /* !CONFIG_PARAVIRT_XXL */ =20 +static __always_inline void wrmsrns(u32 msr, u64 val) +{ + __wrmsrns(msr, val, val >> 32); +} + /* * 64-bit version of wrmsr_safe(): */ --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668793; cv=none; d=zohomail.com; s=zohoarc; b=XIYFovdApbnre7SfrDRoz55XzoW+IBHny/44RaIi0WioKiWtYcd0t2S3IZsKZypIR7as/66BUkjREKH3H2C7ghm+u5xX7ueiGjBIo5Ljg9lYNgc0l+UoEZc/KV08mEX7tMyNbikiikmeQW1BNLPuvNNw3S0j/cDv9TBcwEarZSY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668793; h=Content-Transfer-Encoding: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=s9p5/bhEmV4HuYa5lrj06u/eHfTReVL706hyBnFBpQ4=; b=F+ZEoasmjdc3MKaQLlS5aSDPCax0KiucR+CLGCK9FLjUqAtBGputexuM7MTNQH4ZsrYIb5feIavaqLnDtu2Filnkv5lz0q82mDXUDH8W3QtWRqILeVWI0B4kXcA23WHeD4/3MR3VkWMA9XjggX4u2p3v7Pafzz5dhjbjWNbUPW4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668793275613.7283473306703; Wed, 13 Sep 2023 22:19:53 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601777.937998 (Exim 4.92) (envelope-from ) id 1qgel8-0002cG-R8; Thu, 14 Sep 2023 05:19:22 +0000 Received: by outflank-mailman (output) from mailman id 601777.937998; Thu, 14 Sep 2023 05:19:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel8-0002aT-Ho; Thu, 14 Sep 2023 05:19:22 +0000 Received: by outflank-mailman (input) for mailman id 601777; Thu, 14 Sep 2023 05:19:20 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel6-0001XI-DV for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:20 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 40f3d8c9-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:18 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:31 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:30 -0700 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: 40f3d8c9-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668758; x=1726204758; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=5CJMqB3+DFFPkJgP2JbGGqYZrsstVDR6C7ywuBVlQe8=; b=UDGPezT2r1lItN9QmHWJFF8+q7GloYICmG61JL4rHuFMkaLFs64hHeLs c9kfIruKb3oX/7Wlpqq8eeMp3rNqQiLmYh7KX8D8O/vaxXR7bXLmIexnl 43Dj9YGMb5luqJdppXG3vrbhtK6FmTV5WQY6RDvjACnH4scXLa79NzTIq q76DCj3BHQ3KCDg5aPWhq6ebIrSQ/JlzWZ05gNC1z0Ya+opZ+87vD0qcL fTVo8bNPGcu9fgjPRbp93iN8jBlmu/zT0yMABxIrEy6ubPylUEh8/rArQ RfA/SLgw5+6J5jDZ8xtw/F3C09m3GJ9XpWvZV9RSmRzW8Cb8Gryyo3Gs6 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661118" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661118" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488746" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488746" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 04/38] x86/entry: Remove idtentry_sysvec from entry_{32,64}.S Date: Wed, 13 Sep 2023 21:47:31 -0700 Message-Id: <20230914044805.301390-5-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668795330100005 Content-Type: text/plain; charset="utf-8" idtentry_sysvec is really just DECLARE_IDTENTRY defined in , no need to define it separately. Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/entry/entry_32.S | 4 ---- arch/x86/entry/entry_64.S | 8 -------- arch/x86/include/asm/idtentry.h | 2 +- 3 files changed, 1 insertion(+), 13 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 6e6af42e044a..e0f22ad8ff7e 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -649,10 +649,6 @@ SYM_CODE_START_LOCAL(asm_\cfunc) SYM_CODE_END(asm_\cfunc) .endm =20 -.macro idtentry_sysvec vector cfunc - idtentry \vector asm_\cfunc \cfunc has_error_code=3D0 -.endm - /* * Include the defines which emit the idt entries which are shared * shared between 32 and 64 bit and emit the __irqentry_text_* markers diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 43606de22511..9cdb61ea91de 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -432,14 +432,6 @@ SYM_CODE_END(\asmsym) idtentry \vector asm_\cfunc \cfunc has_error_code=3D1 .endm =20 -/* - * System vectors which invoke their handlers directly and are not - * going through the regular common device interrupt handling code. - */ -.macro idtentry_sysvec vector cfunc - idtentry \vector asm_\cfunc \cfunc has_error_code=3D0 -.endm - /** * idtentry_mce_db - Macro to generate entry stubs for #MC and #DB * @vector: Vector number diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentr= y.h index 05fd175cec7d..cfca68f6cb84 100644 --- a/arch/x86/include/asm/idtentry.h +++ b/arch/x86/include/asm/idtentry.h @@ -447,7 +447,7 @@ __visible noinstr void func(struct pt_regs *regs, \ =20 /* System vector entries */ #define DECLARE_IDTENTRY_SYSVEC(vector, func) \ - idtentry_sysvec vector func + DECLARE_IDTENTRY(vector, func) =20 #ifdef CONFIG_X86_64 # define DECLARE_IDTENTRY_MCE(vector, func) \ --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668794; cv=none; d=zohomail.com; s=zohoarc; b=leHvrX8QsqF7g0UMZ/lL5oZDbhuKMkB1u4btvz83Gotoqo3kQ0jfDk99y7KRpsuWeGtEaDdPri15ErhJmdC3YFDhaepPQHtKCWXo9DDjTA++JPkG9JXHPFIC7Iv3/tHBufBYzplpntaKx/B67ZhiSO7bKqj0AjrDZjfNst6uxpg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668794; h=Content-Transfer-Encoding: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=3cyS8FchZ3LDc9KTW9sGmbtr7Xt/VOHEFQpJJHWI1LA=; b=gu7e7IGBeQElpE23ngOiMPTCyyhzTJQrYVEVSRr9spZLTRUv/vh4Mbu8SJDHuW61i8XWvrksDFyHAESzHqu6LHeaQg2ycT3gkBloomdHfpncaERuG79odOxVjzAeFelZrqjXcMSwK8uEThjXSAyHaTwHy03A5XhfNz1RQmHmAlY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668794049397.0246058103322; Wed, 13 Sep 2023 22:19:54 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601773.937968 (Exim 4.92) (envelope-from ) id 1qgel6-00021X-7D; Thu, 14 Sep 2023 05:19:20 +0000 Received: by outflank-mailman (output) from mailman id 601773.937968; Thu, 14 Sep 2023 05:19:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel6-00021P-49; Thu, 14 Sep 2023 05:19:20 +0000 Received: by outflank-mailman (input) for mailman id 601773; Thu, 14 Sep 2023 05:19:18 +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 1qgel4-0001X7-Kk for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:18 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 402bf4fb-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:17 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:31 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:31 -0700 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: 402bf4fb-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668757; x=1726204757; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=COrE9eAXE6OPNE8ZIH2tugeOeIPIGx3BreJKJ34Ny6U=; b=XJnVF7pK/1D1/F11K/DhyaqIqOX+v6Cy/efHwpBrDOuGno+9UFirvLcK FgELKSYyT2gBokuBiMbEd+YF837kbMqk8RuqoEDNyuDzL0GkIncX3PTRo Xvqfa4p/ZE8WfR5wOdSKI7wWvc56aO1UjNWVAetsX62T/bMn8k/dcV9GR tK1GtO0agqknPR2/ZlfOeguEgQT5BUarIhfvT64HOeK9pbz8BRySQcZFh tXdw3egD9Krlzt632HfeDFLMZupMwb9gNhWlEGwi7EY9zbSqGDVj7X4X/ jVpwAz4SmsqRfDkdQeqpEtf1SAWAWs7GXC+oHqxq5+38RyJYjVGFRGDPe A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661130" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661130" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488749" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488749" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 05/38] x86/trapnr: Add event type macros to Date: Wed, 13 Sep 2023 21:47:32 -0700 Message-Id: <20230914044805.301390-6-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668794536100003 Content-Type: text/plain; charset="utf-8" Intel VT-x classifies events into eight different types, which is inherited by FRED for event identification. As such, event type becomes a common x86 concept, and should be defined in a common x86 header. Add event type macros to , and use it in . Suggested-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/trapnr.h | 12 ++++++++++++ arch/x86/include/asm/vmx.h | 17 +++++++++-------- 2 files changed, 21 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/trapnr.h b/arch/x86/include/asm/trapnr.h index f5d2325aa0b7..ab7e4c9d666f 100644 --- a/arch/x86/include/asm/trapnr.h +++ b/arch/x86/include/asm/trapnr.h @@ -2,6 +2,18 @@ #ifndef _ASM_X86_TRAPNR_H #define _ASM_X86_TRAPNR_H =20 +/* + * Event type codes used by both FRED and Intel VT-x + */ +#define EVENT_TYPE_EXTINT 0 // External interrupt +#define EVENT_TYPE_RESERVED 1 +#define EVENT_TYPE_NMI 2 // NMI +#define EVENT_TYPE_HWEXC 3 // Hardware originated traps, exceptions +#define EVENT_TYPE_SWINT 4 // INT n +#define EVENT_TYPE_PRIV_SWEXC 5 // INT1 +#define EVENT_TYPE_SWEXC 6 // INT0, INT3 +#define EVENT_TYPE_OTHER 7 // FRED SYSCALL/SYSENTER, VT-x MTF + /* Interrupts/Exceptions */ =20 #define X86_TRAP_DE 0 /* Divide-by-zero */ diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h index 0e73616b82f3..c84acfefcd31 100644 --- a/arch/x86/include/asm/vmx.h +++ b/arch/x86/include/asm/vmx.h @@ -17,6 +17,7 @@ #include =20 #include +#include #include =20 #define VMCS_CONTROL_BIT(x) BIT(VMX_FEATURE_##x & 0x1f) @@ -374,14 +375,14 @@ enum vmcs_field { #define VECTORING_INFO_DELIVER_CODE_MASK INTR_INFO_DELIVER_CODE_MASK #define VECTORING_INFO_VALID_MASK INTR_INFO_VALID_MASK =20 -#define INTR_TYPE_EXT_INTR (0 << 8) /* external interrupt */ -#define INTR_TYPE_RESERVED (1 << 8) /* reserved */ -#define INTR_TYPE_NMI_INTR (2 << 8) /* NMI */ -#define INTR_TYPE_HARD_EXCEPTION (3 << 8) /* processor exception */ -#define INTR_TYPE_SOFT_INTR (4 << 8) /* software interrupt */ -#define INTR_TYPE_PRIV_SW_EXCEPTION (5 << 8) /* ICE breakpoint - undocumen= ted */ -#define INTR_TYPE_SOFT_EXCEPTION (6 << 8) /* software exception */ -#define INTR_TYPE_OTHER_EVENT (7 << 8) /* other event */ +#define INTR_TYPE_EXT_INTR (EVENT_TYPE_EXTINT << 8) /* external interrupt= */ +#define INTR_TYPE_RESERVED (EVENT_TYPE_RESERVED << 8) /* reserved */ +#define INTR_TYPE_NMI_INTR (EVENT_TYPE_NMI << 8) /* NMI */ +#define INTR_TYPE_HARD_EXCEPTION (EVENT_TYPE_HWEXC << 8) /* processor exc= eption */ +#define INTR_TYPE_SOFT_INTR (EVENT_TYPE_SWINT << 8) /* software interrup= t */ +#define INTR_TYPE_PRIV_SW_EXCEPTION (EVENT_TYPE_PRIV_SWEXC << 8) /* ICE br= eakpoint - undocumented */ +#define INTR_TYPE_SOFT_EXCEPTION (EVENT_TYPE_SWEXC << 8) /* software exce= ption */ +#define INTR_TYPE_OTHER_EVENT (EVENT_TYPE_OTHER << 8) /* other event */ =20 /* GUEST_INTERRUPTIBILITY_INFO flags. */ #define GUEST_INTR_STATE_STI 0x00000001 --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668790; cv=none; d=zohomail.com; s=zohoarc; b=PqPO1ekF01UyiT59YEpBdFnQSUbWAeWNlMxhP3j8dMzgv34OPifhDt6NKxEQb511g2s8e46eti8Dw9g8tiPzlVff0DHkDqr8Aj213Lfj5LxRU+3RDoET5dlu9+bM0BAezdvl/3+0Gl2Jf3hb65NSKbwO6weOchi8GdV0NGlS8eY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668790; h=Content-Type:Content-Transfer-Encoding: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=zvw8/IPZQmjZB2OK/wTPQpB6D4w6hzDyR8S3ZsxCQB8=; b=DB8DPvbZ6yfDEul78cDTmVo1KE/z6Kgyny35wSnQm5d+c+s9tF8Qx58NqyWZho9vQ1CUyxtzlVsBZSY5mqAAtXIU5cAgzQ4mp1/7x9RTnjxCcaQ6GBGmSL3YBkOHTa3t5WM+vIYYKrhUXhZ5tyOzhTwVS+IwojgRExlVmuZj+BU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668790647932.2435995275825; Wed, 13 Sep 2023 22:19:50 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601778.938007 (Exim 4.92) (envelope-from ) id 1qgel9-0002rf-MJ; Thu, 14 Sep 2023 05:19:23 +0000 Received: by outflank-mailman (output) from mailman id 601778.938007; Thu, 14 Sep 2023 05:19:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel9-0002qf-BM; Thu, 14 Sep 2023 05:19:23 +0000 Received: by outflank-mailman (input) for mailman id 601778; Thu, 14 Sep 2023 05:19:21 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel7-0001XI-Bk for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:21 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 412e55ae-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:18 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:32 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:31 -0700 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: 412e55ae-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668759; x=1726204759; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=CMTJxT2//f8H29ZvTGYte/VGxyI608K6t1MzstL2q6M=; b=bsXjXXIl6HM7QQMcjDNYMv8MBc9Ht0DMvrIX/oGFu0hN65CazXwQ8Lvi dqU2+SpGXDL3WjS/RMPnT3YgfM+YKUN7cRTsm0j0YkAALGF5VbMoaeT9G eRGf5X0Uj1FVhOiSHZZBPjjgZ16tlgqUPKO3GhklMK5gwq/LkzgpW0f0Q fbNAXUvRLsczDPk3Z3C0Q7GIohTVjTfk8zWFRtiXcOXDAKCqdO1/mBH2I 212aTeLUuLevqL7x11rgMM4IQyK4olWJQMcDAIjwENWyulRXDPJJz5GhH 0XQ9Mvt+szIBmtXrusIBLxKmupkWzLAKNSVnC7IZMzFOLCUPAJ/ciYguD g==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661144" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661144" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488752" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488752" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 06/38] Documentation/x86/64: Add a documentation for FRED Date: Wed, 13 Sep 2023 21:47:33 -0700 Message-Id: <20230914044805.301390-7-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668791295100003 Briefly introduce FRED, and its advantages compared to IDT. Signed-off-by: Xin Li --- Documentation/arch/x86/x86_64/fred.rst | 98 +++++++++++++++++++++++++ Documentation/arch/x86/x86_64/index.rst | 1 + 2 files changed, 99 insertions(+) create mode 100644 Documentation/arch/x86/x86_64/fred.rst diff --git a/Documentation/arch/x86/x86_64/fred.rst b/Documentation/arch/x8= 6/x86_64/fred.rst new file mode 100644 index 000000000000..a4ebb95f92c8 --- /dev/null +++ b/Documentation/arch/x86/x86_64/fred.rst @@ -0,0 +1,98 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Flexible Return and Event Delivery (FRED) +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Overview +=3D=3D=3D=3D=3D=3D=3D=3D + +The FRED architecture defines simple new transitions that change +privilege level (ring transitions). The FRED architecture was +designed with the following goals: + +1) Improve overall performance and response time by replacing event + delivery through the interrupt descriptor table (IDT event + delivery) and event return by the IRET instruction with lower + latency transitions. + +2) Improve software robustness by ensuring that event delivery + establishes the full supervisor context and that event return + establishes the full user context. + +The new transitions defined by the FRED architecture are FRED event +delivery and, for returning from events, two FRED return instructions. +FRED event delivery can effect a transition from ring 3 to ring 0, but +it is used also to deliver events incident to ring 0. One FRED +instruction (ERETU) effects a return from ring 0 to ring 3, while the +other (ERETS) returns while remaining in ring 0. Collectively, FRED +event delivery and the FRED return instructions are FRED transitions. + +In addition to these transitions, the FRED architecture defines a new +instruction (LKGS) for managing the state of the GS segment register. +The LKGS instruction can be used by 64-bit operating systems that do +not use the new FRED transitions. + +Furthermore, the FRED architecture is easy to extend for future CPU +architectures. + +Software based event dispatching +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D + +FRED operates differently from IDT in terms of event handling. Instead +of directly dispatching an event to its handler based on the event +vector, FRED requires the software to dispatch an event to its handler +based on both the event's type and vector. Therefore, an event dispatch +framework must be implemented to facilitate the event-to-handler +dispatch process. The FRED event dispatch framework takes control +once an event is delivered, and employs a two-level dispatch. + +The first level dispatching is event type based, and the second level +dispatching is event vector based. + +Full supervisor/user context +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D + +FRED event delivery atomically save and restore full supervisor/user +context upon event delivery and return. Thus it avoids the problem of +transient states due to %cr2 and/or %dr6, and it is no longer needed +to handle all the ugly corner cases caused by half baked entry states. + +FRED allows explicit unblock of NMI with new event return instructions +ERETS/ERETU, avoiding the mess caused by IRET which unconditionally +unblocks NMI, e.g., when an exception happens during NMI handling. + +FRED always restores the full value of %rsp, thus ESPFIX is no longer +needed when FRED is enabled. + +LKGS +=3D=3D=3D=3D + +LKGS behaves like the MOV to GS instruction except that it loads the +base address into the IA32_KERNEL_GS_BASE MSR instead of the GS +segment=E2=80=99s descriptor cache. With LKGS, it ends up with avoiding +mucking with kernel GS, i.e., an operating system can always operate +with its own GS base address. + +Because FRED event delivery from ring 3 swaps the value of the GS base +address and that of the IA32_KERNEL_GS_BASE MSR, and ERETU swaps the +value of the GS base address and that of the IA32_KERNEL_GS_BASE MSR, +plus the introduction of LKGS instruction, the SWAPGS instruction is +no longer needed when FRED is enabled, thus is disallowed (#UD). + +Stack levels +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +4 stack levels 0~3 are introduced to replace the nonreentrant IST for +event handling, and each stack level should be configured to use a +dedicated stack. + +The current stack level could be unchanged or go higher upon FRED +event delivery. If unchanged, the CPU keeps using the current event +stack. If higher, the CPU switches to a new event stack specified by +the MSR of the new stack level, i.e., MSR_IA32_FRED_RSP{1,2,3}. + +Only execution of a FRED return instruction ERET{U,S}, could lower +the current stack level, causing the CPU to switch back to the stack +it was on before a previous event delivery that promoted the stack +level. diff --git a/Documentation/arch/x86/x86_64/index.rst b/Documentation/arch/x= 86/x86_64/index.rst index a56070fc8e77..ad15e9bd623f 100644 --- a/Documentation/arch/x86/x86_64/index.rst +++ b/Documentation/arch/x86/x86_64/index.rst @@ -15,3 +15,4 @@ x86_64 Support cpu-hotplug-spec machinecheck fsgs + fred --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668798; cv=none; d=zohomail.com; s=zohoarc; b=ToUPjo9Z+YQHYMXdifSNa8NI13mQof7hWuDQwrSQ+NMNWTtLR3OT4h+mW+JwI9jWq0uOsYpav7mnC0lkYYAMDBx3TuOwbL2nGw09lu0bb4SuhDcPfBY9A/L7fZifxZlPSYGl+hop2nsrpXdgjGVhnPcDydzGd9dvj1YsY5gAe/Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668798; h=Content-Transfer-Encoding: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=/B1LngaNXknRWWigGNki48mnmhji71aTYbz5CyYK/KE=; b=H8PF0cdYJASccQHx3zPYnz1dlr5QEbkFRxgghYVxH4fhEDv7Fknlar6GYjabdN62xvJ1CwI6Co0N3L59yiFbZACy0+kbOaJKrEX1RQvJpgc/RUdTBZOo394M27BoRg+ksZ+hAPksBqDXl0SuclLfLZ2PiSsIAbUN2yENJjlNsg0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668798839626.8682612713811; Wed, 13 Sep 2023 22:19:58 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601775.937982 (Exim 4.92) (envelope-from ) id 1qgel7-0002LA-QV; Thu, 14 Sep 2023 05:19:21 +0000 Received: by outflank-mailman (output) from mailman id 601775.937982; Thu, 14 Sep 2023 05:19:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel7-0002Je-Lq; Thu, 14 Sep 2023 05:19:21 +0000 Received: by outflank-mailman (input) for mailman id 601775; Thu, 14 Sep 2023 05:19:19 +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 1qgel5-0001X7-O3 for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:19 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4137d9eb-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:18 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:33 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:32 -0700 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: 4137d9eb-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668759; x=1726204759; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=AT3+uEfHqtt3VE+RUnzzRXk1GicJbCzWRed9aBLhDUA=; b=XPDghk5I4x97LdKu8z0HkNRPqkzJW8WqcRAyRfsxao+XO+59X+sr3fpn eH/zQ+ESAVsgubQysZhibsnyosmFFRo/baPgtGUCinaahrlITDHbsIWRB sc61yyWB7PcFaE8/dDRRfy2Lmwa3BgsoQLUclSdOIw8XpyHEuEx8y+Xvr yqbUI53ymZgs1WouLLg9RpT09aj+MvTLKefA5kwpY9lO3anY0f/FcGXk0 iHtzdzxEQ2MUydi8k9GpeqVBeLxW9ZmbyWUuBkdO3qAa7+eUy7J71eM1A OECAzgdo0lL5ymNpSuHngVC3pTz6XPJN9ZF2DkRCGFbpf4VRqwQNGXF8b w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661156" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661156" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488756" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488756" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 07/38] x86/fred: Add Kconfig option for FRED (CONFIG_X86_FRED) Date: Wed, 13 Sep 2023 21:47:34 -0700 Message-Id: <20230914044805.301390-8-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668799505100013 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Add the configuration option CONFIG_X86_FRED to enable FRED. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/Kconfig | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 3b3594f96330..cae126417427 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -496,6 +496,15 @@ config X86_CPU_RESCTRL =20 Say N if unsure. =20 +config X86_FRED + bool "Flexible Return and Event Delivery" + depends on X86_64 + help + When enabled, try to use Flexible Return and Event Delivery + instead of the legacy SYSCALL/SYSENTER/IDT architecture for + ring transitions and exception/interrupt handling if the + system supports. + if X86_32 config X86_BIGSMP bool "Support for big SMP systems with more than 8 CPUs" --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668795; cv=none; d=zohomail.com; s=zohoarc; b=mr0ksU1tkpQpfJuq/Tqld1HZhcH5pzL2nrH7BNf6ZAd9lIYwAAcTEvPnK1fQcflfLbvSt7Ij/X1LL2ekg+fgRE7MMQ1SOoZgu13LVbsfQtz2kPvVL3SUUNAZ90ddnKAYiSn5sGm58m18WKliCY0e5g4qiNfyA51pL5/D55uwuRw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668795; h=Content-Type:Content-Transfer-Encoding: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=jELwGxJww6ZbR4pG0r3HAqZaJS9l8fYLYLYRpujkGaY=; b=kUbsiJmYS2OKUp14Fw1LQrGYFb0u6Ke/yd9Vwr1cjyQ81ivuUtJrflIhqYyKO73cJmKqq18+cWeveJIrmV+Mc81hfZfkOPAHkrV4QUvJq7fQ/VfzTZwr4hWFPNoW5F1B7i3rrg60jhxyO3pEP791EcKqhHeuEzy6aSxPuEHDcCM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668795171547.2599297601602; Wed, 13 Sep 2023 22:19:55 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601779.938016 (Exim 4.92) (envelope-from ) id 1qgelA-00032N-Cp; Thu, 14 Sep 2023 05:19:24 +0000 Received: by outflank-mailman (output) from mailman id 601779.938016; Thu, 14 Sep 2023 05:19:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel9-0002zW-UC; Thu, 14 Sep 2023 05:19:23 +0000 Received: by outflank-mailman (input) for mailman id 601779; Thu, 14 Sep 2023 05:19:21 +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 1qgel7-0001X7-KW for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:21 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4236845a-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:20 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:33 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:32 -0700 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: 4236845a-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668760; x=1726204760; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ZlGESG1ZjbxHp/2vGEpu7uzY2F9a0taEPQgxug8c1Qc=; b=lVm8C0kjG19XQ21YANxgl1yba2VmVOljO2N9aYvr04Y0warlFRAn2Rtp W/7eFOW8VSLWNFF19PJe7aSXwNwns2/owhCs28+4QvYKdObSqfNsp1VTL d2NQIOjIFRFrFPs4/P63nBl1p1iauBCXACqAbqHpooTqQGWbja97LApJR s/oBLyRoACfvrWP7C3/FyzW0jeu2hZ1fOpky/VmG2izrYMqjcRqjYCpzD jRQ0IRtsOvN5y6KKqf84aZPiM41nRsxOK3UkQheMk9XPjQbnyMNwObYPG W+wwFEezglsVoCuLtXTQxeTcBo6BIENiNmVL/d5YQvFTvgYgLlyJC8UEq Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661168" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661168" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488760" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488760" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 08/38] x86/cpufeatures: Add the cpu feature bit for FRED Date: Wed, 13 Sep 2023 21:47:35 -0700 Message-Id: <20230914044805.301390-9-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668797451100002 From: "H. Peter Anvin (Intel)" Any FRED CPU will always have the following features as its baseline: 1) LKGS, load attributes of the GS segment but the base address into the IA32_KERNEL_GS_BASE MSR instead of the GS segment=E2=80=99s descri= ptor cache. 2) WRMSRNS, non-serializing WRMSR for faster MSR writes. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/kernel/cpu/cpuid-deps.c | 2 ++ tools/arch/x86/include/asm/cpufeatures.h | 1 + 3 files changed, 4 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpuf= eatures.h index 330876d34b68..57ae93dc1e52 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -321,6 +321,7 @@ #define X86_FEATURE_FZRM (12*32+10) /* "" Fast zero-length REP MOVSB */ #define X86_FEATURE_FSRS (12*32+11) /* "" Fast short REP STOSB */ #define X86_FEATURE_FSRC (12*32+12) /* "" Fast short REP {CMPSB,SCASB} */ +#define X86_FEATURE_FRED (12*32+17) /* Flexible Return and Event Delivery= */ #define X86_FEATURE_LKGS (12*32+18) /* "" Load "kernel" (userspace) GS */ #define X86_FEATURE_WRMSRNS (12*32+19) /* "" Non-Serializing Write to Mod= el Specific Register instruction */ #define X86_FEATURE_AMX_FP16 (12*32+21) /* "" AMX fp16 Support */ diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-d= eps.c index e462c1d3800a..b7174209d855 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -82,6 +82,8 @@ static const struct cpuid_dep cpuid_deps[] =3D { { X86_FEATURE_XFD, X86_FEATURE_XGETBV1 }, { X86_FEATURE_AMX_TILE, X86_FEATURE_XFD }, { X86_FEATURE_SHSTK, X86_FEATURE_XSAVES }, + { X86_FEATURE_FRED, X86_FEATURE_LKGS }, + { X86_FEATURE_FRED, X86_FEATURE_WRMSRNS }, {} }; =20 diff --git a/tools/arch/x86/include/asm/cpufeatures.h b/tools/arch/x86/incl= ude/asm/cpufeatures.h index 1b9d86ba5bc2..18bab7987d7f 100644 --- a/tools/arch/x86/include/asm/cpufeatures.h +++ b/tools/arch/x86/include/asm/cpufeatures.h @@ -317,6 +317,7 @@ #define X86_FEATURE_FZRM (12*32+10) /* "" Fast zero-length REP MOVSB */ #define X86_FEATURE_FSRS (12*32+11) /* "" Fast short REP STOSB */ #define X86_FEATURE_FSRC (12*32+12) /* "" Fast short REP {CMPSB,SCASB} */ +#define X86_FEATURE_FRED (12*32+17) /* Flexible Return and Event Delivery= */ #define X86_FEATURE_LKGS (12*32+18) /* "" Load "kernel" (userspace) GS */ #define X86_FEATURE_WRMSRNS (12*32+19) /* "" Non-Serializing Write to Mod= el Specific Register instruction */ #define X86_FEATURE_AMX_FP16 (12*32+21) /* "" AMX fp16 Support */ --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668797; cv=none; d=zohomail.com; s=zohoarc; b=lMPr8Lr4cPXVem9ia/1dRS9AsYH8yQChJo0bo7SSaNSZotRQFZqjiM9URkVAatgsVXjslnGB6srgIlomrwKMR7YstK0ViQmO0kivOjH8kfQSouiOJMjNnQM0zk6Z7tG5vi+Jw8h7WY1rdWVL1tVyOKI7uRWDCe/nDYLJf8/yLgI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668797; h=Content-Transfer-Encoding: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=hldy5itB64KpVIVf3aI5He/B+WColc4eEIVchtuDWBc=; b=nzO2qLeE8dkSngkau5uNxpuOQpE9YdUtMzQ/xjzehCmXk0pGBtE82h/ao0yUNQ/G6cFm2iiWHISw018lHsrOP38FzsozmBGxfP9wtWtna4HUkTTfL3Lj/S8+G27ogP7wPYx/T5XvEvvANjZEyWUe+JdT9CM7ibuhcHxdPgwycb4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668797264158.87415777674698; Wed, 13 Sep 2023 22:19:57 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601781.938032 (Exim 4.92) (envelope-from ) id 1qgelB-0003Qc-O8; Thu, 14 Sep 2023 05:19:25 +0000 Received: by outflank-mailman (output) from mailman id 601781.938032; Thu, 14 Sep 2023 05:19:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelB-0003NK-4c; Thu, 14 Sep 2023 05:19:25 +0000 Received: by outflank-mailman (input) for mailman id 601781; Thu, 14 Sep 2023 05:19:22 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel8-0001XI-MN for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:22 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4251e417-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:20 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:34 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:33 -0700 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: 4251e417-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668760; x=1726204760; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=lOSfyYhj6fFAdH4YWvO21Rsoh1uWrkdsP+wGjxpQoYw=; b=e0E+ypmtQ3F1lqdO6RrClcVI4VMrFjkMuXR7Fi6AbXX9Ny5XfeZqffQQ nNuo3H6vl5O8OwZNrK8TV/JZDiMeG0f6udxyDsio7SlGPwmhSbXQahOV/ NdYQvK3F6XVWPhjwb98VIw4NDsEk+zz8c3V9QiQJFH38FTxaowhe/Seoi yxzJ8p3w5bbmBdBxaMuHrM7GNGB81oMHKkr9b8sZj0EOhX+1nD8ZQTa7T K59/zl0C1VdqtzE5KW/RlJXr1r+q5gPIa1qSKVjApb+C53m2dUl4DzU3m au6LXbh5ujoLVd5yV6b2mCfyTJuZaAFc/t/56XzdTDFHc/P71m7Q+sJNV w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661186" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661186" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488764" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488764" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 09/38] x86/fred: Disable FRED support if CONFIG_X86_FRED is disabled Date: Wed, 13 Sep 2023 21:47:36 -0700 Message-Id: <20230914044805.301390-10-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668798687100011 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Add CONFIG_X86_FRED to to make cpu_feature_enabled() work correctly with FRED. Originally-by: Megha Dey Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/disabled-features.h | 8 +++++++- tools/arch/x86/include/asm/disabled-features.h | 8 +++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/as= m/disabled-features.h index 702d93fdd10e..3cde57cb5093 100644 --- a/arch/x86/include/asm/disabled-features.h +++ b/arch/x86/include/asm/disabled-features.h @@ -117,6 +117,12 @@ #define DISABLE_IBT (1 << (X86_FEATURE_IBT & 31)) #endif =20 +#ifdef CONFIG_X86_FRED +# define DISABLE_FRED 0 +#else +# define DISABLE_FRED (1 << (X86_FEATURE_FRED & 31)) +#endif + /* * Make sure to add features to the correct mask */ @@ -134,7 +140,7 @@ #define DISABLED_MASK11 (DISABLE_RETPOLINE|DISABLE_RETHUNK|DISABLE_UNRET| \ DISABLE_CALL_DEPTH_TRACKING|DISABLE_USER_SHSTK) #define DISABLED_MASK12 (DISABLE_LAM) -#define DISABLED_MASK13 0 +#define DISABLED_MASK13 (DISABLE_FRED) #define DISABLED_MASK14 0 #define DISABLED_MASK15 0 #define DISABLED_MASK16 (DISABLE_PKU|DISABLE_OSPKE|DISABLE_LA57|DISABLE_UM= IP| \ diff --git a/tools/arch/x86/include/asm/disabled-features.h b/tools/arch/x8= 6/include/asm/disabled-features.h index fafe9be7a6f4..d540ecdd8812 100644 --- a/tools/arch/x86/include/asm/disabled-features.h +++ b/tools/arch/x86/include/asm/disabled-features.h @@ -105,6 +105,12 @@ # define DISABLE_TDX_GUEST (1 << (X86_FEATURE_TDX_GUEST & 31)) #endif =20 +#ifdef CONFIG_X86_FRED +# define DISABLE_FRED 0 +#else +# define DISABLE_FRED (1 << (X86_FEATURE_FRED & 31)) +#endif + /* * Make sure to add features to the correct mask */ @@ -122,7 +128,7 @@ #define DISABLED_MASK11 (DISABLE_RETPOLINE|DISABLE_RETHUNK|DISABLE_UNRET| \ DISABLE_CALL_DEPTH_TRACKING) #define DISABLED_MASK12 (DISABLE_LAM) -#define DISABLED_MASK13 0 +#define DISABLED_MASK13 (DISABLE_FRED) #define DISABLED_MASK14 0 #define DISABLED_MASK15 0 #define DISABLED_MASK16 (DISABLE_PKU|DISABLE_OSPKE|DISABLE_LA57|DISABLE_UM= IP| \ --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668789; cv=none; d=zohomail.com; s=zohoarc; b=dl8tsGuSEfXrWEf1fQIRIpJu2xPRXtkJICDHesHEiZDMSBIIR7nCq1RqaJv4muZUirMLz1Z7BSMMmW7398pItagERFxznMc942sq1Wr2Yb/b/jcdkhtEHG1IQ0ZcIMMHMYpvi33JebDT9xQpIH0MnPCavQhD5l66ZTUL/VXCP7I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668789; h=Content-Transfer-Encoding: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=es63jL03aDgHjL+D0NM8cs+YRbvWSLlmlyG6aQLMBYc=; b=izC0Iv62+MdowwJDd0bj+BrNNaCU+JcUWVQLv2vXx3fiOGwFe2B3yXfkY269EpKhjd3ymueDy8JKEnXPobQo9zRwO5/ok/cCZJNyoA29laN2EvfjJq18kHQ0fU+vB7oJ3VvXInhpIVB6dw3k+AONNcIWVakzZE6GYOOMnEBAMuI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668789830267.8735347573571; Wed, 13 Sep 2023 22:19:49 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601782.938040 (Exim 4.92) (envelope-from ) id 1qgelC-0003gl-LE; Thu, 14 Sep 2023 05:19:26 +0000 Received: by outflank-mailman (output) from mailman id 601782.938040; Thu, 14 Sep 2023 05:19:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelC-0003bG-6s; Thu, 14 Sep 2023 05:19:26 +0000 Received: by outflank-mailman (input) for mailman id 601782; Thu, 14 Sep 2023 05:19:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgel9-0001XI-By for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:23 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 4296e55e-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:21 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:34 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:34 -0700 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: 4296e55e-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668761; x=1726204761; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kFEO+uu6A5ft6HNZsGdUlo7JkWRDUia/sG5iL2BNrkQ=; b=b4rKuNUl8LwkD03YKrGx/d+ZtCDLf56FpkWw21hv/Cj8yVaxcxhxi5KA qtbiNaindmvtYuxIaB/d/bBsBLlYGmtkLmx95K6ggHKWYjb39SOzbkrFc rcZ4PYT8jxxtYRTCC+wkShHE9iin50nsBt7FlMC3c8IoucDxKJ0dQ63nO Sit7x9a3EfksyPef5Jj30vmJcMC6ApMm6IerYrR2aT7V4AC0pjFAUHG+m uMwNBvQvZV1VzlfkSPv7XUojKjCt3/DD/JfD8sSRE3y4DBWZfiZZHEkzh lgyVOmdxmF3LmISv+4141oY8TLoDhQHdzBEU7LCcNK7JfVQSPTLMxcgw4 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661196" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661196" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488767" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488767" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 10/38] x86/fred: Disable FRED by default in its early stage Date: Wed, 13 Sep 2023 21:47:37 -0700 Message-Id: <20230914044805.301390-11-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668791441100007 Content-Type: text/plain; charset="utf-8" To enable FRED, a new kernel command line option "fred" needs to be added. Tested-by: Shan Kang Signed-off-by: Xin Li --- Documentation/admin-guide/kernel-parameters.txt | 3 +++ arch/x86/kernel/cpu/common.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentatio= n/admin-guide/kernel-parameters.txt index 0a1731a0f0ef..42def5cc7552 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1525,6 +1525,9 @@ Warning: use of this parameter will taint the kernel and may cause unknown problems. =20 + fred [X86-64] + Enable flexible return and event delivery + ftrace=3D[tracer] [FTRACE] will set and start the specified tracer as early as possible in order to facilitate early diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 382d4e6b848d..317b4877e9c7 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1486,6 +1486,9 @@ static void __init cpu_parse_early_param(void) char *argptr =3D arg, *opt; int arglen, taint =3D 0; =20 + if (!cmdline_find_option_bool(boot_command_line, "fred")) + setup_clear_cpu_cap(X86_FEATURE_FRED); + #ifdef CONFIG_X86_32 if (cmdline_find_option_bool(boot_command_line, "no387")) #ifdef CONFIG_MATH_EMULATION --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668791; cv=none; d=zohomail.com; s=zohoarc; b=d5aOIfIGKF8RHO7ZV0bKLqVSMQb2AX1NCnSbV9HBlY6I1eDCS4cSyQDSQ/bYIFzP8NAtttKZWDvcjAFdLwIes6ciFBDXhGFgCMnyVewVERbekbr+cemL+VWWD6KWIhFtzTakOo3/FQYxaXuRuRLDSBrSO1K3S8WwZekwBsa2vkw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668791; h=Content-Transfer-Encoding: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=E6068ho+QcZBGYoTFydsOWHWjNX/l66/vvmNH2/4f34=; b=LqK2rBa32DrTcOah7Bwl+Uvie7trUtnoqeT4M6ZidiR/XsfFbheUDX/eTTU+g7/vC9hzpt8Q3g09YFFEFQzQoru6hZgPJ5jflNEoItgLpRfsTLHIWckKOQwFc/q/WWpUPOgLAowLE/hgwBW53zCt/O5AKTpcqRzdobIVHb7jo0I= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 169466879109792.75417297312572; Wed, 13 Sep 2023 22:19:51 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601780.938021 (Exim 4.92) (envelope-from ) id 1qgelA-0003A7-Qu; Thu, 14 Sep 2023 05:19:24 +0000 Received: by outflank-mailman (output) from mailman id 601780.938021; Thu, 14 Sep 2023 05:19:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelA-00038v-CA; Thu, 14 Sep 2023 05:19:24 +0000 Received: by outflank-mailman (input) for mailman id 601780; Thu, 14 Sep 2023 05:19:22 +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 1qgel8-0001X7-PI for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:22 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 43018c21-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:22 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:35 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:34 -0700 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: 43018c21-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668762; x=1726204762; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=i5VPM7WJy8QX3AfDJPn+y86GzsjxiQoeNBcvUeRwUoQ=; b=B4OPDD7fYTdf8TQCmhnUXfcw9yoQE1iCgeeN9ZkDoj8NgMoa3fuyeWdT 9GGTYLT7QCgXQzK+PPi5t+4d/p+glop8VrjASSrCToH2T5zdwQQrop5VD LqMnzPYHXAheDItCGYwKmcleXyE1X3OPIpJzqFv9/57unUh4ykGoLsd+y R/BDDcFzDCV7NQHbtFSIfn98PyT9Ld/xBZlSWO4USjfQ4kY7epGrMlJaT KtmdG6UUrBRurvA2qXqn6BVH1aqss2UQZeltMqmSoOZ74ezVGfa+K4gzO +DCohTPO88rByUIvqTRK5KDmx9ZXjrNL6LfhTNsTu9gRfUoACF/DP7Iti A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661209" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661209" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488771" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488771" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 11/38] x86/opcode: Add ERET[US] instructions to the x86 opcode map Date: Wed, 13 Sep 2023 21:47:38 -0700 Message-Id: <20230914044805.301390-12-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668791330100005 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" ERETU returns from an event handler while making a transition to ring 3, and ERETS returns from an event handler while staying in ring 0. Add instruction opcodes used by ERET[US] to the x86 opcode map; opcode numbers are per FRED spec v5.0. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li Reviewed-by: Masami Hiramatsu (Google) --- arch/x86/lib/x86-opcode-map.txt | 2 +- tools/arch/x86/lib/x86-opcode-map.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/lib/x86-opcode-map.txt b/arch/x86/lib/x86-opcode-map.= txt index 1efe1d9bf5ce..12af572201a2 100644 --- a/arch/x86/lib/x86-opcode-map.txt +++ b/arch/x86/lib/x86-opcode-map.txt @@ -1052,7 +1052,7 @@ EndTable =20 GrpTable: Grp7 0: SGDT Ms | VMCALL (001),(11B) | VMLAUNCH (010),(11B) | VMRESUME (011),(1= 1B) | VMXOFF (100),(11B) | PCONFIG (101),(11B) | ENCLV (000),(11B) | WRMSRN= S (110),(11B) -1: SIDT Ms | MONITOR (000),(11B) | MWAIT (001),(11B) | CLAC (010),(11B) | = STAC (011),(11B) | ENCLS (111),(11B) +1: SIDT Ms | MONITOR (000),(11B) | MWAIT (001),(11B) | CLAC (010),(11B) | = STAC (011),(11B) | ENCLS (111),(11B) | ERETU (F3),(010),(11B) | ERETS (F2),= (010),(11B) 2: LGDT Ms | XGETBV (000),(11B) | XSETBV (001),(11B) | VMFUNC (100),(11B) = | XEND (101)(11B) | XTEST (110)(11B) | ENCLU (111),(11B) 3: LIDT Ms 4: SMSW Mw/Rv diff --git a/tools/arch/x86/lib/x86-opcode-map.txt b/tools/arch/x86/lib/x86= -opcode-map.txt index 1efe1d9bf5ce..12af572201a2 100644 --- a/tools/arch/x86/lib/x86-opcode-map.txt +++ b/tools/arch/x86/lib/x86-opcode-map.txt @@ -1052,7 +1052,7 @@ EndTable =20 GrpTable: Grp7 0: SGDT Ms | VMCALL (001),(11B) | VMLAUNCH (010),(11B) | VMRESUME (011),(1= 1B) | VMXOFF (100),(11B) | PCONFIG (101),(11B) | ENCLV (000),(11B) | WRMSRN= S (110),(11B) -1: SIDT Ms | MONITOR (000),(11B) | MWAIT (001),(11B) | CLAC (010),(11B) | = STAC (011),(11B) | ENCLS (111),(11B) +1: SIDT Ms | MONITOR (000),(11B) | MWAIT (001),(11B) | CLAC (010),(11B) | = STAC (011),(11B) | ENCLS (111),(11B) | ERETU (F3),(010),(11B) | ERETS (F2),= (010),(11B) 2: LGDT Ms | XGETBV (000),(11B) | XSETBV (001),(11B) | VMFUNC (100),(11B) = | XEND (101)(11B) | XTEST (110)(11B) | ENCLU (111),(11B) 3: LIDT Ms 4: SMSW Mw/Rv --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668795; cv=none; d=zohomail.com; s=zohoarc; b=Mw006qyZPDGGRei+KhyaWyVtYPbtFDSnAl+s2D+2hA8WcvJM/7VC62+ZxD8Goimqzd6W3oS3VK2X2EnY17QlWMIt6DUapxVyz/vJ+cn5/Eu9a4Aj33XSwDuv01Ak12xNPAQ7EjgiNO6Tur1rXe9keZnN9Y/jFnqBTjYW3ZV0N+I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668795; h=Content-Transfer-Encoding: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=DlIxZmkW/yRBHvqwTfBLZbZdyuc8pX1WBRxpyakVO6w=; b=mdrr8Tq+VzELosZx0xSc7nelzif16mPPlbUuJLKClbNfy/XAEz9O9dvbS3Tpj73TXFufEI+Dt/y8wbLSYD/SffJO3cYeM7HMv0P9nTOzM9ZPcW7uPUpE+QYeUbyrnK+CJQgPCyHMteS6PfWRwy7Luvg1Mwgp2/ZG5LjtMZoGrdE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668795979538.2394747453217; Wed, 13 Sep 2023 22:19:55 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601783.938054 (Exim 4.92) (envelope-from ) id 1qgelE-0004A8-M4; Thu, 14 Sep 2023 05:19:28 +0000 Received: by outflank-mailman (output) from mailman id 601783.938054; Thu, 14 Sep 2023 05:19:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelD-00043n-NE; Thu, 14 Sep 2023 05:19:27 +0000 Received: by outflank-mailman (input) for mailman id 601783; Thu, 14 Sep 2023 05:19:24 +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 1qgelA-0001X7-0D for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:24 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 43b7f0d6-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:23 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:35 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:35 -0700 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: 43b7f0d6-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668763; x=1726204763; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=nnaiSfOR32UqURagnGQyKATdoHKyxN7QZzCa/h9+/jY=; b=XW0OzOYaTTwWtqzThAXpp1+riA5eIkYtqSZL2zf5L5HVEg0uGjtUUanv peieq0Nkrk3Cpm114ck85YED3a0wxaJnTWXkOJP5qdMC6YbDtvsaymeMB XSYNev/bZona2kFDKvXfUAr7XSo2vPngtP0mY2yBpJtHQ8vFKbcqdja4e uNmnxodKTIhDajtH4GwVwGprTgBYhIYwLnAp0mZUm3KzKjwQiA4D60hB4 fCbxDnoYvbcmQKlbnGH8Idk2M4mNR3kp4vQzHbNspp/Amg2ljmRLnlpnR zbJ/94YCSamNYVUv1DXuTSQ9rfcHRcIDS1dm3q2nQIe9BF3I7vPXTLG28 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661222" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661222" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488774" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488774" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 12/38] x86/objtool: Teach objtool about ERET[US] Date: Wed, 13 Sep 2023 21:47:39 -0700 Message-Id: <20230914044805.301390-13-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668797483100007 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Update the objtool decoder to know about the ERET[US] instructions (type INSN_CONTEXT_SWITCH). Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- tools/objtool/arch/x86/decode.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decod= e.c index c0f25d00181e..6999f478c155 100644 --- a/tools/objtool/arch/x86/decode.c +++ b/tools/objtool/arch/x86/decode.c @@ -509,11 +509,20 @@ int arch_decode_instruction(struct objtool_file *file= , const struct section *sec =20 if (op2 =3D=3D 0x01) { =20 - if (modrm =3D=3D 0xca) - insn->type =3D INSN_CLAC; - else if (modrm =3D=3D 0xcb) - insn->type =3D INSN_STAC; - + switch (insn_last_prefix_id(&ins)) { + case INAT_PFX_REPE: + case INAT_PFX_REPNE: + if (modrm =3D=3D 0xca) + /* eretu/erets */ + insn->type =3D INSN_CONTEXT_SWITCH; + break; + default: + if (modrm =3D=3D 0xca) + insn->type =3D INSN_CLAC; + else if (modrm =3D=3D 0xcb) + insn->type =3D INSN_STAC; + break; + } } else if (op2 >=3D 0x80 && op2 <=3D 0x8f) { =20 insn->type =3D INSN_JUMP_CONDITIONAL; --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668794; cv=none; d=zohomail.com; s=zohoarc; b=H3HrAP01FVAHQNNJ3hY5+2n0Z0XydZLJ8wvdy4ll9BDgbXAswTFDb8xN/n25pxLqsorMGDgKrc+yDipakHuU8a5kO1fnqCwi4fisL2dmEtyHoA8BvwolgetWdWD1OThQRzYuy0/xlr0wtYFEdqbxItu7NG173W9oemtWJ0TWuGw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668794; h=Content-Transfer-Encoding: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=bStmCdnZPaaUjC37hwMcN7Ic7X8gyE+ppLnV1fTo4eE=; b=jrRuzC9sc2vAgPzDtHHkkbXwnA1+1uI4yRgjQK0T1C8DLf43IFHpVPBInrY2ukh+DbX0BpmuBvLDJgL4NSdyrt7JmJw/yuVgyI8oZrKMF9et9dn/zd/hGjYYJAIwncvWM+RoVe1Y8vMB4ia36q4f5tH/ijJ2hzKVH4eBI39qjNQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 16946687945941021.3462012538826; Wed, 13 Sep 2023 22:19:54 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601784.938060 (Exim 4.92) (envelope-from ) id 1qgelF-0004Lb-B7; Thu, 14 Sep 2023 05:19:29 +0000 Received: by outflank-mailman (output) from mailman id 601784.938060; Thu, 14 Sep 2023 05:19: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 1qgelE-0004Iz-Pw; Thu, 14 Sep 2023 05:19:28 +0000 Received: by outflank-mailman (input) for mailman id 601784; Thu, 14 Sep 2023 05:19:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelA-0001XI-UY for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:24 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 43a7082c-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:23 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:36 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:35 -0700 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: 43a7082c-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668763; x=1726204763; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=UbhaPnTvbyw+zMdUXnvbzwhVl0YY5km3u8wmvpbx2GQ=; b=P2hZf9HdRBJ93sdm5iQnMw+FjjHmZeIt5wRS5CkzN6tgzgnumcQUNB0W +d/AD/0HJBYRZ2zGlsSnQlsaQSCb8NlJtTY5xUFHkzbZ/GCf2vhT7Ye7a NWp2oQO81hzn63uZcxvaHrpnyKgpgpexs9qzkVGyaWbDtu234pX/za7US cmSkgAUFdk1vAh4PjFEpwgurV/EirUBguX2WK+SEtmW3qqgSk3M7wtgnH AXFqYa1aQDcO8J4GXHBsKtPfOWH/JO0y9y/pqxs58124rYJEo02aJvuoR 3v1+JrOgxRG6uKvx9c+CuATc9hWQSTuzVutSjRNsJu59CeXEZuaN2eP54 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661234" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661234" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488777" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488777" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 13/38] x86/cpu: Add X86_CR4_FRED macro Date: Wed, 13 Sep 2023 21:47:40 -0700 Message-Id: <20230914044805.301390-14-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668795373100007 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Add X86_CR4_FRED macro for the FRED bit in %cr4. This bit must not be changed after initialization, so add it to the pinned CR4 bits. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v9: * Avoid a type cast by defining X86_CR4_FRED as 0 on 32-bit (Thomas Gleixner). --- arch/x86/include/uapi/asm/processor-flags.h | 7 +++++++ arch/x86/kernel/cpu/common.c | 5 ++--- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/uapi/asm/processor-flags.h b/arch/x86/include= /uapi/asm/processor-flags.h index d898432947ff..f1a4adc78272 100644 --- a/arch/x86/include/uapi/asm/processor-flags.h +++ b/arch/x86/include/uapi/asm/processor-flags.h @@ -139,6 +139,13 @@ #define X86_CR4_LAM_SUP_BIT 28 /* LAM for supervisor pointers */ #define X86_CR4_LAM_SUP _BITUL(X86_CR4_LAM_SUP_BIT) =20 +#ifdef __x86_64__ +#define X86_CR4_FRED_BIT 32 /* enable FRED kernel entry */ +#define X86_CR4_FRED _BITUL(X86_CR4_FRED_BIT) +#else +#define X86_CR4_FRED (0) +#endif + /* * x86-64 Task Priority Register, CR8 */ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 317b4877e9c7..42511209469b 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -400,9 +400,8 @@ static __always_inline void setup_umip(struct cpuinfo_x= 86 *c) } =20 /* These bits should not change their value after CPU init is finished. */ -static const unsigned long cr4_pinned_mask =3D - X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP | - X86_CR4_FSGSBASE | X86_CR4_CET; +static const unsigned long cr4_pinned_mask =3D X86_CR4_SMEP | X86_CR4_SMAP= | X86_CR4_UMIP | + X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED; static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning); static unsigned long cr4_pinned_bits __ro_after_init; =20 --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668796; cv=none; d=zohomail.com; s=zohoarc; b=cgZlJvM3zeQfVIzPwGZ256uCszpvm6sbyGPtxlI+pX4qVesS/AdCU4Y+VcDa08iLCBYaNMjNPexaGv+OXtFXAlS8PSas4eH606ytYAj9mPv6KdPiljfwxUbVw/NPRJSSkU+5voBp1/8H7RIB4dLqrsX06BvIO6kxTeQLYWUzM5w= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668796; h=Content-Transfer-Encoding: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=BPfl1YsJp6mdRFSIcizmR5WOJdO8vpltvBHwdD+7oVg=; b=NXfRQ/AiLWDCwBM4jPTaW8rBDrLcGqB8gOBbm+BZ5dRr0Cuns5oX8ztNKabqyHSsPSDySFWhsiAWCuIHNhkvPwDrqZSRi/SyZibcSS2CHvJ1f9pl4r/nluvqpxdN4o6fiMPKuxam0/aKAkS1wWl5aINEhJ59FPy/nY7HAfXqBsw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668796728118.96692029590349; Wed, 13 Sep 2023 22:19:56 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601785.938068 (Exim 4.92) (envelope-from ) id 1qgelG-0004bp-Es; Thu, 14 Sep 2023 05:19:30 +0000 Received: by outflank-mailman (output) from mailman id 601785.938068; Thu, 14 Sep 2023 05:19:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelF-0004XH-SH; Thu, 14 Sep 2023 05:19:29 +0000 Received: by outflank-mailman (input) for mailman id 601785; Thu, 14 Sep 2023 05:19:25 +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 1qgelB-0001X7-6j for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:25 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4469d4c0-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:24 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:36 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:36 -0700 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: 4469d4c0-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668764; x=1726204764; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=N6kp9TZ7kHqzLVZW55gD2++Tnq9nIUbsXQRU192FiwQ=; b=mO65nC0zgJh09dTKzl99X2xPfXgxksF+0PDrjxrpmO29In7FO97j62aI 9OEIAswLQdM2t+kOjDzqv8V83iG7nXr2AWABK4fjCHAw0XWmrIt5d4YHi 96+NHbheaHYOs30IUnAazNttwYzLR+ZDOw53SCeAFtr7W1zcSMRU80i0E 2j0lrHDfvGOKzSpIqJjyU+uvEQBnQBefhHHFY0CR2iDhBDjeSp2Bbw16W YUKNlHMbGmKBawv3w/+KwxXVBPJmxKwE+4/RsT5HKqgrQYX+ElBDcjw2R 4eYKv7MlrlRKOCsgiv8iLL4nROTQ5bhSenyuI9X3Ge77cTLTtpoWmEGOF w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661246" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661246" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488780" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488780" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 14/38] x86/cpu: Add MSR numbers for FRED configuration Date: Wed, 13 Sep 2023 21:47:41 -0700 Message-Id: <20230914044805.301390-15-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668797441100001 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Add MSR numbers for the FRED configuration registers per FRED spec 5.0. Originally-by: Megha Dey Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/msr-index.h | 13 ++++++++++++- tools/arch/x86/include/asm/msr-index.h | 13 ++++++++++++- 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-in= dex.h index 1d111350197f..972d15404420 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -36,8 +36,19 @@ #define EFER_FFXSR (1<<_EFER_FFXSR) #define EFER_AUTOIBRS (1<<_EFER_AUTOIBRS) =20 -/* Intel MSRs. Some also available on other CPUs */ +/* FRED MSRs */ +#define MSR_IA32_FRED_RSP0 0x1cc /* Level 0 stack pointer */ +#define MSR_IA32_FRED_RSP1 0x1cd /* Level 1 stack pointer */ +#define MSR_IA32_FRED_RSP2 0x1ce /* Level 2 stack pointer */ +#define MSR_IA32_FRED_RSP3 0x1cf /* Level 3 stack pointer */ +#define MSR_IA32_FRED_STKLVLS 0x1d0 /* Exception stack levels */ +#define MSR_IA32_FRED_SSP0 MSR_IA32_PL0_SSP /* Level 0 shadow stack pointe= r */ +#define MSR_IA32_FRED_SSP1 0x1d1 /* Level 1 shadow stack pointer */ +#define MSR_IA32_FRED_SSP2 0x1d2 /* Level 2 shadow stack pointer */ +#define MSR_IA32_FRED_SSP3 0x1d3 /* Level 3 shadow stack pointer */ +#define MSR_IA32_FRED_CONFIG 0x1d4 /* Entrypoint and interrupt stack lev= el */ =20 +/* Intel MSRs. Some also available on other CPUs */ #define MSR_TEST_CTRL 0x00000033 #define MSR_TEST_CTRL_SPLIT_LOCK_DETECT_BIT 29 #define MSR_TEST_CTRL_SPLIT_LOCK_DETECT BIT(MSR_TEST_CTRL_SPLIT_LOCK_DETE= CT_BIT) diff --git a/tools/arch/x86/include/asm/msr-index.h b/tools/arch/x86/includ= e/asm/msr-index.h index a00a53e15ab7..fc75e3ca47d9 100644 --- a/tools/arch/x86/include/asm/msr-index.h +++ b/tools/arch/x86/include/asm/msr-index.h @@ -36,8 +36,19 @@ #define EFER_FFXSR (1<<_EFER_FFXSR) #define EFER_AUTOIBRS (1<<_EFER_AUTOIBRS) =20 -/* Intel MSRs. Some also available on other CPUs */ +/* FRED MSRs */ +#define MSR_IA32_FRED_RSP0 0x1cc /* Level 0 stack pointer */ +#define MSR_IA32_FRED_RSP1 0x1cd /* Level 1 stack pointer */ +#define MSR_IA32_FRED_RSP2 0x1ce /* Level 2 stack pointer */ +#define MSR_IA32_FRED_RSP3 0x1cf /* Level 3 stack pointer */ +#define MSR_IA32_FRED_STKLVLS 0x1d0 /* Exception stack levels */ +#define MSR_IA32_FRED_SSP0 MSR_IA32_PL0_SSP /* Level 0 shadow stack pointe= r */ +#define MSR_IA32_FRED_SSP1 0x1d1 /* Level 1 shadow stack pointer */ +#define MSR_IA32_FRED_SSP2 0x1d2 /* Level 2 shadow stack pointer */ +#define MSR_IA32_FRED_SSP3 0x1d3 /* Level 3 shadow stack pointer */ +#define MSR_IA32_FRED_CONFIG 0x1d4 /* Entrypoint and interrupt stack lev= el */ =20 +/* Intel MSRs. Some also available on other CPUs */ #define MSR_TEST_CTRL 0x00000033 #define MSR_TEST_CTRL_SPLIT_LOCK_DETECT_BIT 29 #define MSR_TEST_CTRL_SPLIT_LOCK_DETECT BIT(MSR_TEST_CTRL_SPLIT_LOCK_DETE= CT_BIT) --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668800; cv=none; d=zohomail.com; s=zohoarc; b=mAqWVOS4iTBafW7qjmSuMZzACMBYDCyYU1+tyRoa0jMQBB+KydT1G1pVNe4DU7TxiKgNDsvznnRHTAes7q5FfoASwW5AndrgHRLKwV4s7Fgf8OsBrH3oV6MixltXwnTXo0qpk5L4pOwOVN3J6tIvW2hBSQbLa9DPn5OlE5T2EW8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668800; h=Content-Transfer-Encoding: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=+n40/kQPhvTGAcwlRybRl5eY5CAH6lucrDF6/k2t5nk=; b=ImALZMW1Cgm38M2ZSUZqBveIvI+BY2+LPeyQZVZEzxlgZnjewflkCl2NrV3TouY/AoUh+VkBXimbPKk6ww6LSClFVSXsFEerLk7LI6lqA8CRUUoBB8R2CuNuhlAgBEaTx4hbjTMfjUS8KxeNLgTevPwYOqCm55XDXcXbeS/p8ag= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668800396343.96551804693354; Wed, 13 Sep 2023 22:20:00 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601786.938078 (Exim 4.92) (envelope-from ) id 1qgelH-0004rS-DN; Thu, 14 Sep 2023 05:19:31 +0000 Received: by outflank-mailman (output) from mailman id 601786.938078; Thu, 14 Sep 2023 05:19:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelG-0004mf-Ry; Thu, 14 Sep 2023 05:19:30 +0000 Received: by outflank-mailman (input) for mailman id 601786; Thu, 14 Sep 2023 05:19:25 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelB-0001XI-Hc for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:25 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 43eb30c1-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:23 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:37 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:36 -0700 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: 43eb30c1-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668763; x=1726204763; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=yFOHuHE47yU8Pv3f7vyK1KueQKaw2/ZJmrjuiwmDzLE=; b=HqrPmQwy4sRhqAbFo3G610gZeBtUJFY4MMXsl/KHWR7hPtT/5HRpJ5Qs 2b0qDZ0vGhjBhY3qAA33P3bMHswQKBahKfR77n//C0Mce4xWd+5J54VAZ ioGcBTTwjQ5RmupBVHgA701h5RFZefBo+A2AdSooS2NtJ41JSP+CrIvLD J772AGUbG+3El/wUkMPSznDEOJVPWTZIqPfooOXPMuKrd+bfHE/ncLMY4 Fsn7vsJJJtFCrGYr6fbxnxSxNoAOQ6+4wCQyrzcvWheps04Xvp9GgsiVz /Rr5WgETTpsDkga5EDJHzQs3aILP69Lu9LCqOmnxYvCqCCUpy5vA6bNVl Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661261" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661261" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488784" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488784" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 15/38] x86/ptrace: Cleanup the definition of the pt_regs structure Date: Wed, 13 Sep 2023 21:47:42 -0700 Message-Id: <20230914044805.301390-16-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668801538100017 Content-Type: text/plain; charset="utf-8" struct pt_regs is hard to read because the member or section related comments are not aligned with the members. The 'cs' and 'ss' members of pt_regs are type of 'unsigned long' while in reality they are only 16-bit wide. This works so far as the remaining space is unused, but FRED will use the remaining bits for other purposes. To prepare for FRED: - Cleanup the formatting - Convert 'cs' and 'ss' to u16 and embed them into an union with a u64 - Fixup the related printk() format strings Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Thomas Gleixner Signed-off-by: Xin Li --- arch/x86/entry/vsyscall/vsyscall_64.c | 2 +- arch/x86/include/asm/ptrace.h | 44 +++++++++++++++++++-------- arch/x86/kernel/process_64.c | 2 +- 3 files changed, 33 insertions(+), 15 deletions(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscal= l/vsyscall_64.c index e0ca8120aea8..a3c0df11d0e6 100644 --- a/arch/x86/entry/vsyscall/vsyscall_64.c +++ b/arch/x86/entry/vsyscall/vsyscall_64.c @@ -76,7 +76,7 @@ static void warn_bad_vsyscall(const char *level, struct p= t_regs *regs, if (!show_unhandled_signals) return; =20 - printk_ratelimited("%s%s[%d] %s ip:%lx cs:%lx sp:%lx ax:%lx si:%lx di:%lx= \n", + printk_ratelimited("%s%s[%d] %s ip:%lx cs:%x sp:%lx ax:%lx si:%lx di:%lx\= n", level, current->comm, task_pid_nr(current), message, regs->ip, regs->cs, regs->sp, regs->ax, regs->si, regs->di); diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h index f4db78b09c8f..f08ea073edd6 100644 --- a/arch/x86/include/asm/ptrace.h +++ b/arch/x86/include/asm/ptrace.h @@ -57,17 +57,19 @@ struct pt_regs { #else /* __i386__ */ =20 struct pt_regs { -/* - * C ABI says these regs are callee-preserved. They aren't saved on kernel= entry - * unless syscall needs a complete, fully filled "struct pt_regs". - */ + /* + * C ABI says these regs are callee-preserved. They aren't saved on + * kernel entry unless syscall needs a complete, fully filled + * "struct pt_regs". + */ unsigned long r15; unsigned long r14; unsigned long r13; unsigned long r12; unsigned long bp; unsigned long bx; -/* These regs are callee-clobbered. Always saved on kernel entry. */ + + /* These regs are callee-clobbered. Always saved on kernel entry. */ unsigned long r11; unsigned long r10; unsigned long r9; @@ -77,18 +79,34 @@ struct pt_regs { unsigned long dx; unsigned long si; unsigned long di; -/* - * On syscall entry, this is syscall#. On CPU exception, this is error cod= e. - * On hw interrupt, it's IRQ number: - */ + + /* + * orig_ax is used on entry for: + * - the syscall number (syscall, sysenter, int80) + * - error_code stored by the CPU on traps and exceptions + * - the interrupt number for device interrupts + */ unsigned long orig_ax; -/* Return frame for iretq */ + + /* The IRETQ return frame starts here */ unsigned long ip; - unsigned long cs; + + union { + u64 csx; // The full 64-bit data slot containing CS + u16 cs; // CS selector + }; + unsigned long flags; unsigned long sp; - unsigned long ss; -/* top of stack page */ + + union { + u64 ssx; // The full 64-bit data slot containing SS + u16 ss; // SS selector + }; + + /* + * Top of stack on IDT systems. + */ }; =20 #endif /* !__i386__ */ diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 33b268747bb7..0f78b58021bb 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -117,7 +117,7 @@ void __show_regs(struct pt_regs *regs, enum show_regs_m= ode mode, =20 printk("%sFS: %016lx(%04x) GS:%016lx(%04x) knlGS:%016lx\n", log_lvl, fs, fsindex, gs, gsindex, shadowgs); - printk("%sCS: %04lx DS: %04x ES: %04x CR0: %016lx\n", + printk("%sCS: %04x DS: %04x ES: %04x CR0: %016lx\n", log_lvl, regs->cs, ds, es, cr0); printk("%sCR2: %016lx CR3: %016lx CR4: %016lx\n", log_lvl, cr2, cr3, cr4); --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668805; cv=none; d=zohomail.com; s=zohoarc; b=d4uamaCeX1pFU8SFlPpJfXQNzuyDzvQA/F0uycp78LEatu2b03jxeQrqtpnr0P5nasKNUZhvDLkTeoLN2rOY1pMCP+tE8Fv8yKWig0wG/D/rwWXqD83Mo6hRujjHVlwj21i678VisGK3HN7lkaiwpYADLr7jzcHoV/xQOQyTlHo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668805; h=Content-Transfer-Encoding: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=FxmStkGLNnuwG0AQWi/XhVwCYMNsXt+IF63Cv/SCxo8=; b=Cixl78jTDA7NrRJoTJ8vSsO17nAz1oH5+AfiYms8Sk7bGJV/UaAZdtIgdeDCzBnUJwy3Xt+akTDo2W+6B6TK9Ra7O5UP20/9TW9HqEZ1zfhrAATD8zbD+BI85Dm/UleZMvXUxfOF6Qghql0XW1Hiw0whuaF2bysOt/OWMI/MjQc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668805949827.0594884608511; Wed, 13 Sep 2023 22:20:05 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601789.938106 (Exim 4.92) (envelope-from ) id 1qgelM-0005jZ-2R; Thu, 14 Sep 2023 05:19:36 +0000 Received: by outflank-mailman (output) from mailman id 601789.938106; Thu, 14 Sep 2023 05:19:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelK-0005h7-ON; Thu, 14 Sep 2023 05:19:34 +0000 Received: by outflank-mailman (input) for mailman id 601789; Thu, 14 Sep 2023 05:19:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelD-0001XI-8g for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:27 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 44fcae3b-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:25 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:37 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:37 -0700 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: 44fcae3b-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668765; x=1726204765; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/vulkjS/nAxN+RJ3C7R6J4h15cqNiAED/GUC9x16vUQ=; b=D9OJXBoKlsHohHCFu9YUQWG6kQWRyzWGLC0xF9u5Jo5W1SgjJCeEQNaV +8/tnxmt81vAOJvRQgbabqAJk4gCRXlwdQJeIvF2M/02KhNBdmhG1rmh+ eBTquW5h6niFyJSZBdUL9DINoE7hXiTqnK/YbOcDSz7ca7UXPs3AlORmp 7cWd9szGLdG/hBSPc52PJ2D6957PDFqafNI2GaycC6avTXWK2P34e5+Gp H65QPppGj4DC2uwnTErQySlSqtfz2f46CkqXe5pT+PCoofxSu47q0hwmS wFdfLt6wzQhxvY9wpq9FUvBTvykZpgs4Vjg33D9EkumDTcEdXe2cp26SC A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661274" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661274" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488787" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488787" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 16/38] x86/ptrace: Add FRED additional information to the pt_regs structure Date: Wed, 13 Sep 2023 21:47:43 -0700 Message-Id: <20230914044805.301390-17-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668807620100003 Content-Type: text/plain; charset="utf-8" FRED defines additional information in the upper 48 bits of cs/ss fields. Therefore add the information definitions into the pt_regs structure. Specially introduce a new structure fred_ss to denote the FRED flags above SS selector, which avoids FRED_SSX_ macros and makes the code simpler and easier to read. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Thomas Gleixner Signed-off-by: Xin Li --- Changes since v9: * Introduce a new structure fred_ss to denote the FRED flags above SS selector, which avoids FRED_SSX_ macros and makes the code simpler and easier to read (Thomas Gleixner). * Use type u64 to define FRED bit fields instead of type unsigned int (Thomas Gleixner). Changes since v8: * Reflect stack frame definition changes from FRED spec 3.0 to 5.0. * Use __packed instead of __attribute__((__packed__)) (Borislav Petkov). * Put all comments above the members, like the rest of the file does (Borislav Petkov). Changes since v3: * Rename csl/ssl of the pt_regs structure to csx/ssx (x for extended) (Andrew Cooper). --- arch/x86/include/asm/ptrace.h | 51 +++++++++++++++++++++++++++++++---- 1 file changed, 46 insertions(+), 5 deletions(-) diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h index f08ea073edd6..5786c8ca5f4c 100644 --- a/arch/x86/include/asm/ptrace.h +++ b/arch/x86/include/asm/ptrace.h @@ -56,6 +56,25 @@ struct pt_regs { =20 #else /* __i386__ */ =20 +struct fred_ss { + u64 ss : 16, // SS selector + sti : 1, // STI state + swevent : 1, // Set if syscall, sysenter or INT n + nmi : 1, // Event is NMI type + : 13, + vector : 8, // Event vector + : 8, + type : 4, // Event type + : 4, + enclave : 1, // Event was incident to enclave execution + lm : 1, // CPU was in long mode + nested : 1, // Nested exception during FRED delivery + // not set for #DF + : 1, + insnlen : 4; // The length of the instruction causing the event + // Only set for INT0, INT1, INT3, INT n, SYSCALL +}; // and SYSENTER. 0 otherwise. + struct pt_regs { /* * C ABI says these regs are callee-preserved. They aren't saved on @@ -85,6 +104,12 @@ struct pt_regs { * - the syscall number (syscall, sysenter, int80) * - error_code stored by the CPU on traps and exceptions * - the interrupt number for device interrupts + * + * A FRED stack frame starts here: + * 1) It _always_ includes an error code; + * + * 2) The return frame for ERET[US] starts here, but + * the content of orig_ax is ignored. */ unsigned long orig_ax; =20 @@ -92,20 +117,36 @@ struct pt_regs { unsigned long ip; =20 union { - u64 csx; // The full 64-bit data slot containing CS - u16 cs; // CS selector + u64 csx; // The full data for FRED + /* + * The 'cs' member should be defined as a 16-bit bit-field + * along with the 'sl' and 'wfe' members, which however + * breaks compiling REG_OFFSET_NAME(cs), because compilers + * disallow calculating the address of a bit-field. + * + * Therefore 'cs" is defined as an individual member with + * type u16. + */ + u16 cs; // CS selector + u64 : 16, + sl : 2, // Stack level at event time + wfe : 1, // IBT is in WAIT_FOR_BRANCH_STATE + : 45; }; =20 unsigned long flags; unsigned long sp; =20 union { - u64 ssx; // The full 64-bit data slot containing SS - u16 ss; // SS selector + u64 ssx; // The full data for FRED + u16 ss; // SS selector + struct fred_ss fred_ss; // The fred extension }; =20 /* - * Top of stack on IDT systems. + * Top of stack on IDT systems, while FRED systems have extra fields + * defined above for storing exception related information, e.g. CR2 or + * DR6. */ }; =20 --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668799; cv=none; d=zohomail.com; s=zohoarc; b=a+OacnYJvAfvx2uv0ph106gueBhPzYFYUZeKET9oNyTD67jPedXQPHvO3a3836bGRaU4eqKxJK7PQemz27+Mrqx+EFkP8R0p21TfEb+s0v+Vi1CgJloAy3w4u9YttIplG6yRGeNfp9AP5iYI0jfp6ifO3TjJMtfOdFHm5I7FmeQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668799; h=Content-Transfer-Encoding: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=KHGdYssn2/S0nhcvv+MuhXtfyk6bSylHaLWAZxxlieQ=; b=ONX2E1z7SN5X7paeyTVSKT1CQJuZFPzU6P8ydtd48B+KsoWmvOsDum6PG/HwaKyLxpAedw19vJHovSLkEGomcrLl6AU6P8Mpsf2kLbj72BTC6Zj8SG7/13g6JwPny7XNTheZCTv4SKckykcur5prUJNy+HqTrIhLQ/UAztZ3b40= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668799493206.9297190750134; Wed, 13 Sep 2023 22:19:59 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601787.938089 (Exim 4.92) (envelope-from ) id 1qgelJ-0005DR-3k; Thu, 14 Sep 2023 05:19:33 +0000 Received: by outflank-mailman (output) from mailman id 601787.938089; Thu, 14 Sep 2023 05:19:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelI-00058N-5k; Thu, 14 Sep 2023 05:19:32 +0000 Received: by outflank-mailman (input) for mailman id 601787; Thu, 14 Sep 2023 05:19:26 +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 1qgelC-0001X7-CQ for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:26 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 4525bba6-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:25 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:38 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:37 -0700 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: 4525bba6-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668765; x=1726204765; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SbR2wCTkousO/IPIjdDUqT7zLHmXpw3IGG9LN/Z2MXU=; b=hopPJo6kH5nNTlpxiF3a6jU00bXhTHALSuzGGnYyl5YLM9vd4FAmYLY7 hb3QTOIUBMF3DKJ3uqKLHcQ3ZHXcoqROzK9rJjDobrvYHYV0xZa6slaLc EpyaOtMzE/2Zm0BPVuo2/c850JSspt4tHRsoa1Rptusp1NPJjW05npDmC 62uSOy8K79HKKqmuVcdJByVkHy77M3E0zEZY+dvpWjglBCUX/gFT0BIyn O3BIz0Xr43o1sIXb7AtpLZidNOMwh5bCt2T9fWZTAZzo2azJ8zgjjJ3OJ cXOgTrS5gaqVqoYKLTyPxfIrZETpq933Tsvxuby9g2BtyujWMnJoQbFwG A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661287" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661287" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488790" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488790" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 17/38] x86/fred: Add a new header file for FRED definitions Date: Wed, 13 Sep 2023 21:47:44 -0700 Message-Id: <20230914044805.301390-18-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668801759100019 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Add a header file for FRED prototypes and definitions. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v6: * Replace pt_regs csx flags prefix FRED_CSL_ with FRED_CSX_. --- arch/x86/include/asm/fred.h | 68 +++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 arch/x86/include/asm/fred.h diff --git a/arch/x86/include/asm/fred.h b/arch/x86/include/asm/fred.h new file mode 100644 index 000000000000..f514fdb5a39f --- /dev/null +++ b/arch/x86/include/asm/fred.h @@ -0,0 +1,68 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Macros for Flexible Return and Event Delivery (FRED) + */ + +#ifndef ASM_X86_FRED_H +#define ASM_X86_FRED_H + +#include + +#include + +/* + * FRED event return instruction opcodes for ERET{S,U}; supported in + * binutils >=3D 2.41. + */ +#define ERETS _ASM_BYTES(0xf2,0x0f,0x01,0xca) +#define ERETU _ASM_BYTES(0xf3,0x0f,0x01,0xca) + +/* + * RSP is aligned to a 64-byte boundary before used to push a new stack fr= ame + */ +#define FRED_STACK_FRAME_RSP_MASK _AT(unsigned long, (~0x3f)) + +/* + * Used for the return address for call emulation during code patching, + * and measured in 64-byte cache lines. + */ +#define FRED_CONFIG_REDZONE_AMOUNT 1 +#define FRED_CONFIG_REDZONE (_AT(unsigned long, FRED_CONFIG_REDZONE_AMOUN= T) << 6) +#define FRED_CONFIG_INT_STKLVL(l) (_AT(unsigned long, l) << 9) +#define FRED_CONFIG_ENTRYPOINT(p) _AT(unsigned long, (p)) + +#ifndef __ASSEMBLY__ + +#ifdef CONFIG_X86_FRED +#include + +#include + +struct fred_info { + /* Event data: CR2, DR6, ... */ + unsigned long edata; + unsigned long resv; +}; + +/* Full format of the FRED stack frame */ +struct fred_frame { + struct pt_regs regs; + struct fred_info info; +}; + +static __always_inline struct fred_info *fred_info(struct pt_regs *regs) +{ + return &container_of(regs, struct fred_frame, regs)->info; +} + +static __always_inline unsigned long fred_event_data(struct pt_regs *regs) +{ + return fred_info(regs)->edata; +} + +#else /* CONFIG_X86_FRED */ +static __always_inline unsigned long fred_event_data(struct pt_regs *regs)= { return 0; } +#endif /* CONFIG_X86_FRED */ +#endif /* !__ASSEMBLY__ */ + +#endif /* ASM_X86_FRED_H */ --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668805; cv=none; d=zohomail.com; s=zohoarc; b=Ky7Y15KjHUBrcDPAs6liTl/PuTsgDSDohv7adm7oSoe01taYJZCw+848dDMOjUyizeXp812XyUFm6ulNkUvlELeDRphnfKR0bUyXZKkR859wWPNBfI9vC7iARbXvXtxK0TiDR79ke8qZExOcn4oZ08d/zlsTO6ozWdEu0xzHcvE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668805; h=Content-Transfer-Encoding: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=gAZY9xniyTfPliDTpYR37+Md0HYYnva4EgAEJyvKmmU=; b=O9jOdpmKssZyQIkdkdfac2Mea+5blx6ft2yOQZEw+yYyTMqH6crutYc/waGFiwiuNZi14AEbkxTdHbF9SHn2ay/x2w9NzjOOfFJcsMKhq4yD47jFkCu4cFCZJJWe4hG8Kidt62iYxjorSgPE2Y7RsF0Me2CPlJX6AdkCS7yBZiU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668805422530.3503722233685; Wed, 13 Sep 2023 22:20:05 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601790.938114 (Exim 4.92) (envelope-from ) id 1qgelO-0006MV-77; Thu, 14 Sep 2023 05:19:38 +0000 Received: by outflank-mailman (output) from mailman id 601790.938114; Thu, 14 Sep 2023 05:19:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelN-0006Dz-Fm; Thu, 14 Sep 2023 05:19:37 +0000 Received: by outflank-mailman (input) for mailman id 601790; Thu, 14 Sep 2023 05:19:28 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelD-0001XI-Pa for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:27 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 455699f5-52be-11ee-9b0d-b553b5be7939; Thu, 14 Sep 2023 07:19:25 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:38 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:38 -0700 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: 455699f5-52be-11ee-9b0d-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668766; x=1726204766; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=f4gesqgoemAM7gLIVW0tfHuShJv23oH28+TguMOULZ8=; b=BSplR6hjGD9hQ5K/ymN787jSWRqWTYIWUAXMZsK9JmGiGoqJXoGGLqde /w9WYjHMgDON4UVFWaFPT2UmiUzj1+SnVTZCG9uFVhsaziJCOry//mqdR pZtmPNZFz+IkNdgo6ZWaKRyRTmgge8gUuNHLj0TE51IJ9nmb4e13wH1k6 xn+vHv43PBhRDfJyPCmtQB1h2Bcs8egu/qgZxnQHUEs4baeCAKy1D7chJ Q7aeDLoXZn/hjvXytzM8NmnpsPuZpIqcQuvKN9S3UyfyNKfQOy5XBuhuE N+ugtTukiEMAMQUI8ZtcHBeR6ACAec7rmM31cR9ArIVeUbvublmlfSqC1 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661301" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661301" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488793" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488793" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 18/38] x86/fred: Reserve space for the FRED stack frame Date: Wed, 13 Sep 2023 21:47:45 -0700 Message-Id: <20230914044805.301390-19-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668805941100001 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" When using FRED, reserve space at the top of the stack frame, just like i386 does. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/thread_info.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/thread_info.h b/arch/x86/include/asm/thre= ad_info.h index d63b02940747..12da7dfd5ef1 100644 --- a/arch/x86/include/asm/thread_info.h +++ b/arch/x86/include/asm/thread_info.h @@ -31,7 +31,9 @@ * In vm86 mode, the hardware frame is much longer still, so add 16 * bytes to make room for the real-mode segments. * - * x86_64 has a fixed-length stack frame. + * x86-64 has a fixed-length stack frame, but it depends on whether + * or not FRED is enabled. Future versions of FRED might make this + * dynamic, but for now it is always 2 words longer. */ #ifdef CONFIG_X86_32 # ifdef CONFIG_VM86 @@ -39,8 +41,12 @@ # else # define TOP_OF_KERNEL_STACK_PADDING 8 # endif -#else -# define TOP_OF_KERNEL_STACK_PADDING 0 +#else /* x86-64 */ +# ifdef CONFIG_X86_FRED +# define TOP_OF_KERNEL_STACK_PADDING (2 * 8) +# else +# define TOP_OF_KERNEL_STACK_PADDING 0 +# endif #endif =20 /* --=20 2.34.1 From nobody Sun May 19 02:38:10 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 header.i=@intel.com; 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=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1694668796; cv=none; d=zohomail.com; s=zohoarc; b=W9eqFKNiyAmGura4Tgtn1+4X8OGfk2/Hy6dhxfno24tZAU9/ObSpGdze6+OJcHfoNFAUIXBaoeAb/X2cd6KqY6/dvfcRr+g3LTBvBe1KprUWgnUgC1dg70spkPwX1JFG0uIM5xJFyqrKljWjOUwFcZJQ511Nb4unTx5PnouLMG4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1694668796; h=Content-Transfer-Encoding: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=oRqk/sQnL3ES7VmPQpA31WEpUqe3NnkXYaJMISYry5Y=; b=lxC6rfGkKqsEAQ0yh3vSvmIMlewA7Ft51RB6UEhPA7IzPyqDBY1NYoqxGPVyZFVJr1SnypnY4roFOScTIum4YV9/PnAoq/mJUUxxLDptnD/QfWwvvVrTLSN6d5soO5MOy7AVOpk+IVqRj8QyQyQSNfIGFj4cWReT17HZ7Em4t/I= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=@intel.com; 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 1694668796838179.94982095108628; Wed, 13 Sep 2023 22:19:56 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.601788.938093 (Exim 4.92) (envelope-from ) id 1qgelK-0005Su-AN; Thu, 14 Sep 2023 05:19:34 +0000 Received: by outflank-mailman (output) from mailman id 601788.938093; Thu, 14 Sep 2023 05:19:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qgelJ-0005NU-FG; Thu, 14 Sep 2023 05:19:33 +0000 Received: by outflank-mailman (input) for mailman id 601788; Thu, 14 Sep 2023 05:19: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 1qgelD-0001X7-Fr for xen-devel@lists.xenproject.org; Thu, 14 Sep 2023 05:19:27 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 45d62fb2-52be-11ee-8787-cb3800f73035; Thu, 14 Sep 2023 07:19:26 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:39 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:38 -0700 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: 45d62fb2-52be-11ee-8787-cb3800f73035 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668766; x=1726204766; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=U5v5FfPZcbv+kEeu4BDXYc9n8fkslqM+14uJJDiLwkk=; b=OjHMgYbI7VwzupYtsKNN6kaCpQd8FrHI8F3YYFk4VN5twPj3uKoKyMoB a4Z4ZDpm3WIFRnYleKRudi7NHXh72KfLfLqYQrsvbXkCk4vneIyeuOown s5WCHJoaJ/f5mFIAX40OhyUVZFpSsAnZ+LPWD6nyP+cBGiuqPi6G1Wx4n d1ROkYZB7G4K5ZFjDl3u3bMb5VLoG1V4QEBWLfCmCJaKYS7TB1PjHI8FE mB5NtbgkJKje/m5LYmaHiY2368nobsRaD6wkZ25jaMY4DiojviYWHSrsm tpefDOfP7KvDrnioeIkK+nIP0fW8tAt0+HgIM+JGah/dm4nqz+UZCx3sy A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661314" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661314" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488796" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488796" From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 19/38] x86/fred: Update MSR_IA32_FRED_RSP0 during task switch Date: Wed, 13 Sep 2023 21:47:46 -0700 Message-Id: <20230914044805.301390-20-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1694668797464100003 Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" MSR_IA32_FRED_RSP0 is used during ring 3 event delivery, and needs to be updated to point to the top of next task stack during task switch. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/include/asm/switch_to.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch= _to.h index f42dbf17f52b..c3bd0c0758c9 100644 --- a/arch/x86/include/asm/switch_to.h +++ b/arch/x86/include/asm/switch_to.h @@ -70,9 +70,13 @@ static inline void update_task_stack(struct task_struct = *task) #ifdef CONFIG_X86_32 this_cpu_write(cpu_tss_rw.x86_tss.sp1, task->thread.sp0); #else - /* Xen PV enters the kernel on the thread stack. */ - if (cpu_feature_enabled(X86_FEATURE_XENPV)) + if (cpu_feature_enabled(X86_FEATURE_FRED)) { + /* WRMSRNS is a baseline feature for FRED. */ + wrmsrns(MSR_IA32_FRED_RSP0, (unsigned long)task_stack_page(task) + THREA= D_SIZE); + } else if (cpu_feature_enabled(X86_FEATURE_XENPV)) { + /* Xen PV enters the kernel on the thread stack. */ load_sp0(task_top_of_stack(task)); + } #endif } =20 --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 145BAEDE981 for ; Thu, 14 Sep 2023 05:20:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234903AbjINFUM (ORCPT ); Thu, 14 Sep 2023 01:20:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235127AbjINFT3 (ORCPT ); Thu, 14 Sep 2023 01:19:29 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB0651FD7; Wed, 13 Sep 2023 22:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668761; x=1726204761; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HaNFd9+f6o42v45n40NutGcoZldX+CMRVlEU3cDygtg=; b=b/KkDC9q4trXFNRaJLchtnYNd9hcBpyEjADsJWDcYkkPis40w1ENC/1a XnMb1EJ8+Fc9X490ASKGYTvNTTuvxFzM4mvsQDH8MPR0TUAf59Te5nsrK 7kGMlrrqg68aW4XU1dO2YzOFbhdRe5YqsQz0H2dtvS17NsMVhLSLh2SzP 53v855whjdgIx2PH8UGN5X5xsIRMiDnjLgbk5pAgk7+Q4bUx/vXBwWqGw HOoOFpsTnA4t8nJmJpE5P34Gig+5JPI5PyWxebQWgQTNh/gDYdr3mxNt+ NaTllILIqYsaCY3rBrXLddJQRukMC3F4AA/R0Nk508UHb0d5lOWPkRAaO g==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661326" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661326" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488799" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488799" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:39 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 20/38] x86/fred: Disallow the swapgs instruction when FRED is enabled Date: Wed, 13 Sep 2023 21:47:47 -0700 Message-Id: <20230914044805.301390-21-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "H. Peter Anvin (Intel)" SWAPGS is no longer needed thus NOT allowed with FRED because FRED transitions ensure that an operating system can _always_ operate with its own GS base address: - For events that occur in ring 3, FRED event delivery swaps the GS base address with the IA32_KERNEL_GS_BASE MSR. - ERETU (the FRED transition that returns to ring 3) also swaps the GS base address with the IA32_KERNEL_GS_BASE MSR. And the operating system can still setup the GS segment for a user thread without the need of loading a user thread GS with: - Using LKGS, available with FRED, to modify other attributes of the GS segment without compromising its ability always to operate with its own GS base address. - Accessing the GS segment base address for a user thread as before using RDMSR or WRMSR on the IA32_KERNEL_GS_BASE MSR. Note, LKGS loads the GS base address into the IA32_KERNEL_GS_BASE MSR instead of the GS segment=E2=80=99s descriptor cache. As such, the operating system never changes its runtime GS base address. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v8: * Explain why writing directly to the IA32_KERNEL_GS_BASE MSR is doing the right thing (Thomas Gleixner). --- arch/x86/kernel/process_64.c | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 0f78b58021bb..4f87f5987ae8 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -166,7 +166,29 @@ static noinstr unsigned long __rdgsbase_inactive(void) =20 lockdep_assert_irqs_disabled(); =20 - if (!cpu_feature_enabled(X86_FEATURE_XENPV)) { + /* + * SWAPGS is no longer needed thus NOT allowed with FRED because + * FRED transitions ensure that an operating system can _always_ + * operate with its own GS base address: + * - For events that occur in ring 3, FRED event delivery swaps + * the GS base address with the IA32_KERNEL_GS_BASE MSR. + * - ERETU (the FRED transition that returns to ring 3) also swaps + * the GS base address with the IA32_KERNEL_GS_BASE MSR. + * + * And the operating system can still setup the GS segment for a + * user thread without the need of loading a user thread GS with: + * - Using LKGS, available with FRED, to modify other attributes + * of the GS segment without compromising its ability always to + * operate with its own GS base address. + * - Accessing the GS segment base address for a user thread as + * before using RDMSR or WRMSR on the IA32_KERNEL_GS_BASE MSR. + * + * Note, LKGS loads the GS base address into the IA32_KERNEL_GS_BASE + * MSR instead of the GS segment=E2=80=99s descriptor cache. As such, the + * operating system never changes its runtime GS base address. + */ + if (!cpu_feature_enabled(X86_FEATURE_FRED) && + !cpu_feature_enabled(X86_FEATURE_XENPV)) { native_swapgs(); gsbase =3D rdgsbase(); native_swapgs(); @@ -191,7 +213,8 @@ static noinstr void __wrgsbase_inactive(unsigned long g= sbase) { lockdep_assert_irqs_disabled(); =20 - if (!cpu_feature_enabled(X86_FEATURE_XENPV)) { + if (!cpu_feature_enabled(X86_FEATURE_FRED) && + !cpu_feature_enabled(X86_FEATURE_XENPV)) { native_swapgs(); wrgsbase(gsbase); native_swapgs(); --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 DE078EDE981 for ; Thu, 14 Sep 2023 05:20:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235639AbjINFUJ (ORCPT ); Thu, 14 Sep 2023 01:20:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235124AbjINFT3 (ORCPT ); Thu, 14 Sep 2023 01:19:29 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF25E1BD4; Wed, 13 Sep 2023 22:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668761; x=1726204761; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=daicXFK30tmpTUp95RTD2ZQAe5K9xY8zuW1WSEbSaqA=; b=c91nZfFofOZKNdKrmUhQGL3nbvAwZhFXJyaEsMh+EWgPagnwj67J7ibY AmDAhHQG5z+A5fZxH6K6e89v7f3v62GSgMsjwN4vrOoIFdKrTaE3sTROY g6ncn/XW0XPwrolGq8g3y/2qCSaZLgV68/tjYeAHzaxhjqwkKHq+hH1tf GdopUPAphxt+gLtd5p6NIII77ZJHAz9DRqCaagaqCp9UOdyfooS6m/UHU Hhq6ev4aSvWBYPJn3k2/lEwAdBOHGR9SQxIwSGMU4vE0EsCVr/b8DgdSh LyYc5J+4G8Pe8XMcudmF838Ycq8Uz/Haeed/n9HqxjS3roqG5H1T1Egxu Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661341" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661341" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488802" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488802" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:39 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 21/38] x86/fred: No ESPFIX needed when FRED is enabled Date: Wed, 13 Sep 2023 21:47:48 -0700 Message-Id: <20230914044805.301390-22-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Because FRED always restores the full value of %rsp, ESPFIX is no longer needed when it's enabled. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kernel/espfix_64.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/kernel/espfix_64.c b/arch/x86/kernel/espfix_64.c index 16f9814c9be0..6726e0473d0b 100644 --- a/arch/x86/kernel/espfix_64.c +++ b/arch/x86/kernel/espfix_64.c @@ -106,6 +106,10 @@ void __init init_espfix_bsp(void) pgd_t *pgd; p4d_t *p4d; =20 + /* FRED systems always restore the full value of %rsp */ + if (cpu_feature_enabled(X86_FEATURE_FRED)) + return; + /* Install the espfix pud into the kernel page directory */ pgd =3D &init_top_pgt[pgd_index(ESPFIX_BASE_ADDR)]; p4d =3D p4d_alloc(&init_mm, pgd, ESPFIX_BASE_ADDR); @@ -129,6 +133,10 @@ void init_espfix_ap(int cpu) void *stack_page; pteval_t ptemask; =20 + /* FRED systems always restore the full value of %rsp */ + if (cpu_feature_enabled(X86_FEATURE_FRED)) + return; + /* We only have to do this once... */ if (likely(per_cpu(espfix_stack, cpu))) return; /* Already initialized */ --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 6B15CEDE980 for ; Thu, 14 Sep 2023 05:20:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235682AbjINFUP (ORCPT ); Thu, 14 Sep 2023 01:20:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235144AbjINFT3 (ORCPT ); Thu, 14 Sep 2023 01:19:29 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C28591FDC; Wed, 13 Sep 2023 22:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668762; x=1726204762; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=m7R91mzhAyMwuxf88uvtu3V1UGcA6vznqDxNdL57F/c=; b=dDcQJUjJrPEaEE6iYwnAL4W+3ZiDIqKPvQ80QJvHyunisaaptRhg7MCW XZRBi9uAnGvZEAFpZMRKwcA5hFVqhWOAx5rg3kgtqRhB+QVIo438n7O19 pvieavFEU4bIepgwFDoWANfM9Eor1UeDIjfPBNk9WbEF6KexYkZyB5BRS Mtvvi0O7GCQZVrseJ7KHxo28SKLR1p92rce7YYwGvLzKaR82fTqI8L3/7 fvGxFZPyUZa0+6f5OtOR/8o6zVo/7IMx0Esp3QPO/iZgpUbpMLq8vxanS vHcHVerWIyuQ2Ga8GwfullB3Tnb3DiC9iwjWynyeMt8eVC2yz1Ya2pgKD A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661356" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661356" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488805" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488805" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:40 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 22/38] x86/fred: Allow single-step trap and NMI when starting a new task Date: Wed, 13 Sep 2023 21:47:49 -0700 Message-Id: <20230914044805.301390-23-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Entering a new task is logically speaking a return from a system call (exec, fork, clone, etc.). As such, if ptrace enables single stepping a single step exception should be allowed to trigger immediately upon entering user space. This is not optional. NMI should *never* be disabled in user space. As such, this is an optional, opportunistic way to catch errors. Allow single-step trap and NMI when starting a new task, thus once the new task enters user space, single-step trap and NMI are both enabled immediately. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v8: * Use high-order 48 bits above the lowest 16 bit SS only when FRED is enabled (Thomas Gleixner). --- arch/x86/kernel/process_64.c | 38 ++++++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 4f87f5987ae8..c075591b7b46 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -56,6 +56,7 @@ #include #include #include +#include #ifdef CONFIG_IA32_EMULATION /* Not included via unistd.h */ #include @@ -528,7 +529,7 @@ void x86_gsbase_write_task(struct task_struct *task, un= signed long gsbase) static void start_thread_common(struct pt_regs *regs, unsigned long new_ip, unsigned long new_sp, - unsigned int _cs, unsigned int _ss, unsigned int _ds) + u16 _cs, u16 _ss, u16 _ds) { WARN_ON_ONCE(regs !=3D current_pt_regs()); =20 @@ -545,11 +546,36 @@ start_thread_common(struct pt_regs *regs, unsigned lo= ng new_ip, loadsegment(ds, _ds); load_gs_index(0); =20 - regs->ip =3D new_ip; - regs->sp =3D new_sp; - regs->cs =3D _cs; - regs->ss =3D _ss; - regs->flags =3D X86_EFLAGS_IF; + regs->ip =3D new_ip; + regs->sp =3D new_sp; + regs->csx =3D _cs; + regs->ssx =3D _ss; + /* + * Allow single-step trap and NMI when starting a new task, thus + * once the new task enters user space, single-step trap and NMI + * are both enabled immediately. + * + * Entering a new task is logically speaking a return from a + * system call (exec, fork, clone, etc.). As such, if ptrace + * enables single stepping a single step exception should be + * allowed to trigger immediately upon entering user space. + * This is not optional. + * + * NMI should *never* be disabled in user space. As such, this + * is an optional, opportunistic way to catch errors. + * + * Paranoia: High-order 48 bits above the lowest 16 bit SS are + * discarded by the legacy IRET instruction on all Intel, AMD, + * and Cyrix/Centaur/VIA CPUs, thus can be set unconditionally, + * even when FRED is not enabled. But we choose the safer side + * to use these bits only when FRED is enabled. + */ + if (cpu_feature_enabled(X86_FEATURE_FRED)) { + regs->fred_ss.swevent =3D true; + regs->fred_ss.nmi =3D true; + } + + regs->flags =3D X86_EFLAGS_IF | X86_EFLAGS_FIXED; } =20 void --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 A779DEDE980 for ; Thu, 14 Sep 2023 05:20:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235429AbjINFUY (ORCPT ); Thu, 14 Sep 2023 01:20:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235154AbjINFTa (ORCPT ); Thu, 14 Sep 2023 01:19:30 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F2661FDE; Wed, 13 Sep 2023 22:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668762; x=1726204762; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vZ6vels66+tC8YRpSCj8dEsAAUPLXovJkO1WpIp9s0Y=; b=K69NdO6K32mKD65wvuc7+o8TLuc8W//zfepoDPWD37CLmifV9V7SkCqh W56/I8Li0lj6K9ty0OXjvqwKEc4yI6erTwc3ld/MuEOlFA7VFww3MTJZW w8C/bqW8jkhS9yxzaxxsi3jpDDV+/98+Qk8ZEk4skUK/1IsRyNHek0b2E /NP4L05K1bnTVwcKZ73LzrIGaobRxr7B/tyFzpYvSck/ypUsti4ABe6XB XvaJd6V3qmMn4gM4Kt9zHiUwJ/L+iFWOFCl611f3s6st3tbfoJ7Fg5/Is sf0BOARuZqIX5/op/dQjSsDFvCai0D1J3DYd248CNWbdmZtSIBjhF4IKD w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661368" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661368" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488808" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488808" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:40 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 23/38] x86/fred: Make exc_page_fault() work for FRED Date: Wed, 13 Sep 2023 21:47:50 -0700 Message-Id: <20230914044805.301390-24-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" On a FRED system, the faulting address (CR2) is passed on the stack, to avoid the problem of transient state. Thus we get the page fault address from the stack instead of CR2. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Thomas Gleixner Signed-off-by: Xin Li --- arch/x86/mm/fault.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index ab778eac1952..7675bc067153 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -34,6 +34,7 @@ #include /* kvm_handle_async_pf */ #include /* fixup_vdso_exception() */ #include +#include =20 #define CREATE_TRACE_POINTS #include @@ -1516,8 +1517,10 @@ handle_page_fault(struct pt_regs *regs, unsigned lon= g error_code, =20 DEFINE_IDTENTRY_RAW_ERRORCODE(exc_page_fault) { - unsigned long address =3D read_cr2(); irqentry_state_t state; + unsigned long address; + + address =3D cpu_feature_enabled(X86_FEATURE_FRED) ? fred_event_data(regs)= : read_cr2(); =20 prefetchw(¤t->mm->mmap_lock); =20 --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 07B93EDE980 for ; Thu, 14 Sep 2023 05:20:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234983AbjINFU2 (ORCPT ); Thu, 14 Sep 2023 01:20:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235007AbjINFTa (ORCPT ); Thu, 14 Sep 2023 01:19:30 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F4E41BD1; Wed, 13 Sep 2023 22:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668762; x=1726204762; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=aB9X6AvBbEVqHF8pDqD66jUIoaqA7x/kswu7ifFPwEo=; b=n2WPsv/bZonbd+oj5tdpiH3zN24oTxtI7e8E+NegpRxn9lIMyaZ9hc3x Y3e8w823cYCq3AR3VTQo6ZDu2Oso3Pwv+Oi7Ktrp+mvFp2MhVANtYE2+N KbxxrJeqjRHa1Mt4EoYwgjxnNV5Z8+cVHRGXPt9jIFqchM054ehmrZNnz xR4f6tDAXphwQSisB6WdmuGN4YLWwcOcGlttlk0TPw40pjivVwBy3dKPE OV4VOF/viOwQi+8zV1jOFmgwX0MLkLos6+zU0oxRy4kxfTJ1M8Eoo3q5V RwuI7odLl9IoWhuKWgXafYBzqtLxvancpoYgnZYKqkKKIfAWnzagimjuE g==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661381" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661381" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488811" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488811" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:41 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 24/38] x86/idtentry: Incorporate definitions/declarations of the FRED entries Date: Wed, 13 Sep 2023 21:47:51 -0700 Message-Id: <20230914044805.301390-25-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" FRED and IDT can share most of the definitions and declarations so that in the majority of cases the actual handler implementation is the same. The differences are the exceptions where FRED stores exception related information on the stack and the sysvec implementations as FRED can handle irqentry/exit() in the dispatcher instead of having it in each handler. Also add stub defines for vectors which are not used due to Kconfig decisions to spare the ifdeffery in the actual FRED dispatch code. Tested-by: Shan Kang Signed-off-by: Thomas Gleixner Signed-off-by: Xin Li --- Changes since v9: * Except NMI/#DB/#MCE, FRED really should share the exception handlers with IDT (Thomas Gleixner). Changes since v8: * Put IDTENTRY changes in a separate patch (Thomas Gleixner). --- arch/x86/include/asm/idtentry.h | 71 +++++++++++++++++++++++++++++---- 1 file changed, 63 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentr= y.h index cfca68f6cb84..4f26ee9b8b74 100644 --- a/arch/x86/include/asm/idtentry.h +++ b/arch/x86/include/asm/idtentry.h @@ -13,15 +13,18 @@ =20 #include =20 +typedef void (*idtentry_t)(struct pt_regs *regs); + /** * DECLARE_IDTENTRY - Declare functions for simple IDT entry points * No error code pushed by hardware * @vector: Vector number (ignored for C) * @func: Function name of the entry point * - * Declares three functions: + * Declares four functions: * - The ASM entry point: asm_##func * - The XEN PV trap entry point: xen_##func (maybe unused) + * - The C handler called from the FRED event dispatcher (maybe unused) * - The C handler called from the ASM entry point * * Note: This is the C variant of DECLARE_IDTENTRY(). As the name says it @@ -31,6 +34,7 @@ #define DECLARE_IDTENTRY(vector, func) \ asmlinkage void asm_##func(void); \ asmlinkage void xen_asm_##func(void); \ + void fred_##func(struct pt_regs *regs); \ __visible void func(struct pt_regs *regs) =20 /** @@ -137,6 +141,17 @@ static __always_inline void __##func(struct pt_regs *r= egs, \ #define DEFINE_IDTENTRY_RAW(func) \ __visible noinstr void func(struct pt_regs *regs) =20 +/** + * DEFINE_FREDENTRY_RAW - Emit code for raw FRED entry points + * @func: Function name of the entry point + * + * @func is called from the FRED event dispatcher with interrupts disabled. + * + * See @DEFINE_IDTENTRY_RAW for further details. + */ +#define DEFINE_FREDENTRY_RAW(func) \ +noinstr void fred_##func(struct pt_regs *regs) + /** * DECLARE_IDTENTRY_RAW_ERRORCODE - Declare functions for raw IDT entry po= ints * Error code pushed by hardware @@ -233,17 +248,27 @@ static noinline void __##func(struct pt_regs *regs, u= 32 vector) #define DEFINE_IDTENTRY_SYSVEC(func) \ static void __##func(struct pt_regs *regs); \ \ +static __always_inline void instr_##func(struct pt_regs *regs) \ +{ \ + kvm_set_cpu_l1tf_flush_l1d(); \ + run_sysvec_on_irqstack_cond(__##func, regs); \ +} \ + \ __visible noinstr void func(struct pt_regs *regs) \ { \ irqentry_state_t state =3D irqentry_enter(regs); \ \ instrumentation_begin(); \ - kvm_set_cpu_l1tf_flush_l1d(); \ - run_sysvec_on_irqstack_cond(__##func, regs); \ + instr_##func (regs); \ instrumentation_end(); \ irqentry_exit(regs, state); \ } \ \ +void fred_##func(struct pt_regs *regs) \ +{ \ + instr_##func (regs); \ +} \ + \ static noinline void __##func(struct pt_regs *regs) =20 /** @@ -260,19 +285,29 @@ static noinline void __##func(struct pt_regs *regs) #define DEFINE_IDTENTRY_SYSVEC_SIMPLE(func) \ static __always_inline void __##func(struct pt_regs *regs); \ \ -__visible noinstr void func(struct pt_regs *regs) \ +static __always_inline void instr_##func(struct pt_regs *regs) \ { \ - irqentry_state_t state =3D irqentry_enter(regs); \ - \ - instrumentation_begin(); \ __irq_enter_raw(); \ kvm_set_cpu_l1tf_flush_l1d(); \ __##func (regs); \ __irq_exit_raw(); \ +} \ + \ +__visible noinstr void func(struct pt_regs *regs) \ +{ \ + irqentry_state_t state =3D irqentry_enter(regs); \ + \ + instrumentation_begin(); \ + instr_##func (regs); \ instrumentation_end(); \ irqentry_exit(regs, state); \ } \ \ +void fred_##func(struct pt_regs *regs) \ +{ \ + instr_##func (regs); \ +} \ + \ static __always_inline void __##func(struct pt_regs *regs) =20 /** @@ -410,15 +445,18 @@ __visible noinstr void func(struct pt_regs *regs, \ /* C-Code mapping */ #define DECLARE_IDTENTRY_NMI DECLARE_IDTENTRY_RAW #define DEFINE_IDTENTRY_NMI DEFINE_IDTENTRY_RAW +#define DEFINE_FREDENTRY_NMI DEFINE_FREDENTRY_RAW =20 #ifdef CONFIG_X86_64 #define DECLARE_IDTENTRY_MCE DECLARE_IDTENTRY_IST #define DEFINE_IDTENTRY_MCE DEFINE_IDTENTRY_IST #define DEFINE_IDTENTRY_MCE_USER DEFINE_IDTENTRY_NOIST +#define DEFINE_FREDENTRY_MCE DEFINE_FREDENTRY_RAW =20 #define DECLARE_IDTENTRY_DEBUG DECLARE_IDTENTRY_IST #define DEFINE_IDTENTRY_DEBUG DEFINE_IDTENTRY_IST #define DEFINE_IDTENTRY_DEBUG_USER DEFINE_IDTENTRY_NOIST +#define DEFINE_FREDENTRY_DEBUG DEFINE_FREDENTRY_RAW #endif =20 #else /* !__ASSEMBLY__ */ @@ -651,23 +689,36 @@ DECLARE_IDTENTRY(RESCHEDULE_VECTOR, sysvec_reschedu= le_ipi); DECLARE_IDTENTRY_SYSVEC(REBOOT_VECTOR, sysvec_reboot); DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_SINGLE_VECTOR, sysvec_call_function_= single); DECLARE_IDTENTRY_SYSVEC(CALL_FUNCTION_VECTOR, sysvec_call_function); +#else +# define fred_sysvec_reschedule_ipi NULL +# define fred_sysvec_reboot NULL +# define fred_sysvec_call_function_single NULL +# define fred_sysvec_call_function NULL #endif =20 #ifdef CONFIG_X86_LOCAL_APIC # ifdef CONFIG_X86_MCE_THRESHOLD DECLARE_IDTENTRY_SYSVEC(THRESHOLD_APIC_VECTOR, sysvec_threshold); +# else +# define fred_sysvec_threshold NULL # endif =20 # ifdef CONFIG_X86_MCE_AMD DECLARE_IDTENTRY_SYSVEC(DEFERRED_ERROR_VECTOR, sysvec_deferred_error); +# else +# define fred_sysvec_deferred_error NULL # endif =20 # ifdef CONFIG_X86_THERMAL_VECTOR DECLARE_IDTENTRY_SYSVEC(THERMAL_APIC_VECTOR, sysvec_thermal); +# else +# define fred_sysvec_thermal NULL # endif =20 # ifdef CONFIG_IRQ_WORK DECLARE_IDTENTRY_SYSVEC(IRQ_WORK_VECTOR, sysvec_irq_work); +# else +# define fred_sysvec_irq_work NULL # endif #endif =20 @@ -675,12 +726,16 @@ DECLARE_IDTENTRY_SYSVEC(IRQ_WORK_VECTOR, sysvec_irq_= work); DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_VECTOR, sysvec_kvm_posted_intr_ipi); DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_WAKEUP_VECTOR, sysvec_kvm_posted_intr_= wakeup_ipi); DECLARE_IDTENTRY_SYSVEC(POSTED_INTR_NESTED_VECTOR, sysvec_kvm_posted_intr_= nested_ipi); +#else +# define fred_sysvec_kvm_posted_intr_ipi NULL +# define fred_sysvec_kvm_posted_intr_wakeup_ipi NULL +# define fred_sysvec_kvm_posted_intr_nested_ipi NULL #endif =20 #if IS_ENABLED(CONFIG_HYPERV) DECLARE_IDTENTRY_SYSVEC(HYPERVISOR_CALLBACK_VECTOR, sysvec_hyperv_callback= ); DECLARE_IDTENTRY_SYSVEC(HYPERV_REENLIGHTENMENT_VECTOR, sysvec_hyperv_reenl= ightenment); -DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR, sysvec_hyperv_stimer0); +DECLARE_IDTENTRY_SYSVEC(HYPERV_STIMER0_VECTOR, sysvec_hyperv_stimer0); #endif =20 #if IS_ENABLED(CONFIG_ACRN_GUEST) --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 19DD2EDE984 for ; Thu, 14 Sep 2023 05:20:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235276AbjINFUg (ORCPT ); Thu, 14 Sep 2023 01:20:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235104AbjINFTp (ORCPT ); Thu, 14 Sep 2023 01:19:45 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EAB81FEF; Wed, 13 Sep 2023 22:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668763; x=1726204763; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WI4PNmnQNqWbUIJ+xrhdRHV/OU0QAbzmppTdHG3/yfg=; b=V9E4zvsnYYAIbtrWW3j6tn9Z5xfUWrHW6BAvD0mlJBQKAO6gkVmhyHd7 x7AXjzC1rW0lMFghYIjrSZdfUuNoDhHFJucV33SSyQ/+G8Z9m/MOFcbHh MJcZMwqGaD9ILWmvUd5jLTsTxfVX0uGNeYb5YiQWtFvF25J96M9MpQD7i 9jZg3rEftqsMmiferujswLHvqY4AYBE8CKapdcWaUSUjx0z57B/rVKNUS fpvP77iMOdTOv3/LgYo2CHWVdlRAmfsbQQOVNaxiIlpy02gs4X9PnF44r N/6vZvLttKXMAzKPRjwiZNm+kNYqCi3Nf412HZuy4pTa/TFW6RHtAlXlQ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661394" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661394" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488814" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488814" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:41 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 25/38] x86/fred: Add a debug fault entry stub for FRED Date: Wed, 13 Sep 2023 21:47:52 -0700 Message-Id: <20230914044805.301390-26-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" When occurred on different ring level, i.e., from user or kernel context, #DB needs to be handled on different stack: User #DB on current task stack, while kernel #DB on a dedicated stack. This is exactly how FRED event delivery invokes an exception handler: ring 3 event on level 0 stack, i.e., current task stack; ring 0 event on the #DB dedicated stack specified in the IA32_FRED_STKLVLS MSR. So unlike IDT, the FRED debug exception entry stub doesn't do stack switch. On a FRED system, the debug trap status information (DR6) is passed on the stack, to avoid the problem of transient state. Furthermore, FRED transitions avoid a lot of ugly corner cases the handling of which can, and should be, skipped. The FRED debug trap status information saved on the stack differs from DR6 in both stickiness and polarity; it is exactly in the format which debug_read_clear_dr6() returns for the IDT entry points. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v9: * Disable #DB to avoid endless recursion and stack overflow when a watchpoint/breakpoint is set in the code path which is executed by #DB handler (Thomas Gleixner). Changes since v1: * call irqentry_nmi_{enter,exit}() in both IDT and FRED debug fault kernel handler (Peter Zijlstra). --- arch/x86/kernel/traps.c | 43 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 38 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index c876f1d36a81..848c85208a57 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -50,6 +50,7 @@ #include #include #include +#include #include #include #include @@ -934,8 +935,7 @@ static bool notify_debug(struct pt_regs *regs, unsigned= long *dr6) return false; } =20 -static __always_inline void exc_debug_kernel(struct pt_regs *regs, - unsigned long dr6) +static noinstr void exc_debug_kernel(struct pt_regs *regs, unsigned long d= r6) { /* * Disable breakpoints during exception handling; recursive exceptions @@ -947,6 +947,11 @@ static __always_inline void exc_debug_kernel(struct pt= _regs *regs, * * Entry text is excluded for HW_BP_X and cpu_entry_area, which * includes the entry stack is excluded for everything. + * + * For FRED, nested #DB should just work fine. But when a watchpoint or + * breakpoint is set in the code path which is executed by #DB handler, + * it results in an endless recursion and stack overflow. Thus we stay + * with the IDT approach, i.e., save DR7 and disable #DB. */ unsigned long dr7 =3D local_db_save(); irqentry_state_t irq_state =3D irqentry_nmi_enter(regs); @@ -976,7 +981,8 @@ static __always_inline void exc_debug_kernel(struct pt_= regs *regs, * Catch SYSENTER with TF set and clear DR_STEP. If this hit a * watchpoint at the same time then that will still be handled. */ - if ((dr6 & DR_STEP) && is_sysenter_singlestep(regs)) + if (!cpu_feature_enabled(X86_FEATURE_FRED) && + (dr6 & DR_STEP) && is_sysenter_singlestep(regs)) dr6 &=3D ~DR_STEP; =20 /* @@ -1008,8 +1014,7 @@ static __always_inline void exc_debug_kernel(struct p= t_regs *regs, local_db_restore(dr7); } =20 -static __always_inline void exc_debug_user(struct pt_regs *regs, - unsigned long dr6) +static noinstr void exc_debug_user(struct pt_regs *regs, unsigned long dr6) { bool icebp; =20 @@ -1093,6 +1098,34 @@ DEFINE_IDTENTRY_DEBUG_USER(exc_debug) { exc_debug_user(regs, debug_read_clear_dr6()); } + +#ifdef CONFIG_X86_FRED +/* + * When occurred on different ring level, i.e., from user or kernel + * context, #DB needs to be handled on different stack: User #DB on + * current task stack, while kernel #DB on a dedicated stack. + * + * This is exactly how FRED event delivery invokes an exception + * handler: ring 3 event on level 0 stack, i.e., current task stack; + * ring 0 event on the #DB dedicated stack specified in the + * IA32_FRED_STKLVLS MSR. So unlike IDT, the FRED debug exception + * entry stub doesn't do stack switch. + */ +DEFINE_FREDENTRY_DEBUG(exc_debug) +{ + /* + * FRED #DB stores DR6 on the stack in the format which + * debug_read_clear_dr6() returns for the IDT entry points. + */ + unsigned long dr6 =3D fred_event_data(regs); + + if (user_mode(regs)) + exc_debug_user(regs, dr6); + else + exc_debug_kernel(regs, dr6); +} +#endif /* CONFIG_X86_FRED */ + #else /* 32 bit does not have separate entry points. */ DEFINE_IDTENTRY_RAW(exc_debug) --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 26015EDE980 for ; Thu, 14 Sep 2023 05:20:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235698AbjINFUS (ORCPT ); Thu, 14 Sep 2023 01:20:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235164AbjINFTa (ORCPT ); Thu, 14 Sep 2023 01:19:30 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C9D01BD9; Wed, 13 Sep 2023 22:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668762; x=1726204762; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FcZc1QeKj2isPTwOBVaGNTy+si5WeOaciLFU4yv7EQo=; b=jIncnZMVrIxcwet3pbSY+w+8fYvnN+RdF4lUowsl/oXQDZuU+8ssGNGe 97GTfAOF7Cjr6HxaJ73az9OLXKmMcdxGzANL7FLHEPLGoXOXmZMF3DNOs BYYQ0Ij5CvhNQ8Qw04nATKdmgXkNbd2Qlw/5cerzm6WsXW8vl4Rci25nt 2fn/fRT0knxHPUTw+iy0v4lwJPWuozezZagPZsbuqaoCf9D9cx0UubXxB 5atw500QOMAtwU0NFdxRbsKJuw+znOm4sCy0yoatf8xVBrZCS2fbmiEWk tucqwrhgAEF0zVk4xhw5P2yDPXzs7mkg7dohjxdOORO0uYbXRWG8G5dbw g==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661407" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661407" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488817" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488817" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:42 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 26/38] x86/fred: Add a NMI entry stub for FRED Date: Wed, 13 Sep 2023 21:47:53 -0700 Message-Id: <20230914044805.301390-27-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" On a FRED system, NMIs nest both with themselves and faults, transient information is saved into the stack frame, and NMI unblocking only happens when the stack frame indicates that so should happen. Thus, the NMI entry stub for FRED is really quite small... Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kernel/nmi.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c index a0c551846b35..58843fdf5cd0 100644 --- a/arch/x86/kernel/nmi.c +++ b/arch/x86/kernel/nmi.c @@ -34,6 +34,7 @@ #include #include #include +#include =20 #define CREATE_TRACE_POINTS #include @@ -643,6 +644,33 @@ void nmi_backtrace_stall_check(const struct cpumask *b= tp) =20 #endif =20 +#ifdef CONFIG_X86_FRED +/* + * With FRED, CR2/DR6 is pushed to #PF/#DB stack frame during FRED + * event delivery, i.e., there is no problem of transient states. + * And NMI unblocking only happens when the stack frame indicates + * that so should happen. + * + * Thus, the NMI entry stub for FRED is really straightforward and + * as simple as most exception handlers. As such, #DB is allowed + * during NMI handling. + */ +DEFINE_FREDENTRY_NMI(exc_nmi) +{ + irqentry_state_t irq_state; + + if (IS_ENABLED(CONFIG_SMP) && arch_cpu_is_offline(smp_processor_id())) + return; + + irq_state =3D irqentry_nmi_enter(regs); + + inc_irq_stat(__nmi_count); + default_do_nmi(regs); + + irqentry_nmi_exit(regs, irq_state); +} +#endif + void stop_nmi(void) { ignore_nmis++; --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 C6C92EDE981 for ; Thu, 14 Sep 2023 05:20:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235367AbjINFUb (ORCPT ); Thu, 14 Sep 2023 01:20:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235353AbjINFTp (ORCPT ); Thu, 14 Sep 2023 01:19:45 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9EBB61FF0; Wed, 13 Sep 2023 22:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668763; x=1726204763; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bNtEfhEic2/4eI6U3F6LZD3GtdQN7TZ08d/4AOd+L9I=; b=Qpf19+RaO/+rNSUYgEK7ndADjr3LeHPs76DLwBipJExN6G1CQrM8P+m3 nwC0BWdGNC0d+Z51WvlTlTSr6va2ap5B5QsuwyRKgGnb1PoeGuco/jCgc lYVTCj4+nr8bEWaDYYWYMqQTx19SwSwwiu4offfYDea4RRG/bGKOi6nPw jpw49Yu5EUg+9JaSU/TTCZ9YOZmE/0YQ5MAdAtYE700XEclWxPe7pBWkX b/xZLe85BM692YVUNBcFnuq6Y3otYNTEo3Lw25lOapfhyYDHi0t7nWp92 14H45rVITSYZJyR9HlpUo2mju6wCfObZZOXvmzkE3wQxGvlzGcjJ96Bq4 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661419" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661419" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488820" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488820" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:42 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 27/38] x86/fred: Add a machine check entry stub for FRED Date: Wed, 13 Sep 2023 21:47:54 -0700 Message-Id: <20230914044805.301390-28-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Like #DB, when occurred on different ring level, i.e., from user or kernel context, #MCE needs to be handled on different stack: User #MCE on current task stack, while kernel #MCE on a dedicated stack. This is exactly how FRED event delivery invokes an exception handler: ring 3 event on level 0 stack, i.e., current task stack; ring 0 event on the #MCE dedicated stack specified in the IA32_FRED_STKLVLS MSR. So unlike IDT, the FRED machine check entry stub doesn't do stack switch. Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v5: * Disallow #DB inside #MCE for robustness sake (Peter Zijlstra). --- arch/x86/kernel/cpu/mce/core.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c index 6f35f724cc14..da0a4a102afe 100644 --- a/arch/x86/kernel/cpu/mce/core.c +++ b/arch/x86/kernel/cpu/mce/core.c @@ -52,6 +52,7 @@ #include #include #include +#include =20 #include "internal.h" =20 @@ -2144,6 +2145,31 @@ DEFINE_IDTENTRY_MCE_USER(exc_machine_check) exc_machine_check_user(regs); local_db_restore(dr7); } + +#ifdef CONFIG_X86_FRED +/* + * When occurred on different ring level, i.e., from user or kernel + * context, #MCE needs to be handled on different stack: User #MCE + * on current task stack, while kernel #MCE on a dedicated stack. + * + * This is exactly how FRED event delivery invokes an exception + * handler: ring 3 event on level 0 stack, i.e., current task stack; + * ring 0 event on the #MCE dedicated stack specified in the + * IA32_FRED_STKLVLS MSR. So unlike IDT, the FRED machine check entry + * stub doesn't do stack switch. + */ +DEFINE_FREDENTRY_MCE(exc_machine_check) +{ + unsigned long dr7; + + dr7 =3D local_db_save(); + if (user_mode(regs)) + exc_machine_check_user(regs); + else + exc_machine_check_kernel(regs); + local_db_restore(dr7); +} +#endif #else /* 32bit unified entry point */ DEFINE_IDTENTRY_RAW(exc_machine_check) --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 18542EDE983 for ; Thu, 14 Sep 2023 05:20:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235820AbjINFUi (ORCPT ); Thu, 14 Sep 2023 01:20:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235365AbjINFTq (ORCPT ); Thu, 14 Sep 2023 01:19:46 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E9621FEE; Wed, 13 Sep 2023 22:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668763; x=1726204763; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=zzvxos+z5xHa+gR1tK1Kt1AOyIHMJNb/6Ch1a3vXOAg=; b=ljEwGAc2M4UWkdzMn6jbUtPqqhOcdUTnPhCiquPIt6yoOmxG4r+nzH0F 4Z3mPCM5k2TSvQtjIKokm/GeUOKMijRzi4K9JCMaAYDlj8FG6Fi811aJJ e3F0p5x2dPbkfZfiw7xg7Yr9to/rHPxxGBmzgiX3iu377FnHNkXBQJPmu zk44E6IQNc7LcrK+DygWyj2oZVX9nvumPAyDTT1RD4MQAQ8CG1zQbnk72 7MyEwwT4RJomC8idDhRuGUmVmhKjDBZGVoSjcW4cSMwUBb+4yTVSCLbty 35zq3EVe59FjeohK9zMOp3vcYCsWOjp7gAKvwzy0FA5QrAuRvOAlCPE8L w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661433" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661433" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488823" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488823" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:43 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 28/38] x86/fred: FRED entry/exit and dispatch code Date: Wed, 13 Sep 2023 21:47:55 -0700 Message-Id: <20230914044805.301390-29-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" The code to actually handle kernel and event entry/exit using FRED. It is split up into two files thus: - entry_64_fred.S contains the actual entrypoints and exit code, and saves and restores registers. - entry_fred.c contains the two-level event dispatch code for FRED. The first-level dispatch is on the event type, and the second-level is on the event vector. Originally-by: Megha Dey Signed-off-by: H. Peter Anvin (Intel) Co-developed-by: Xin Li Tested-by: Shan Kang Signed-off-by: Thomas Gleixner Signed-off-by: Xin Li --- Changes since v9: * Don't use jump tables, indirect jumps are expensive (Thomas Gleixner). * Except NMI/#DB/#MCE, FRED really can share the exception handlers with IDT (Thomas Gleixner). * Avoid the sysvec_* idt_entry muck, do it at a central place, reuse code instead of blindly copying it, which breaks the performance optimized sysvec entries like reschedule_ipi (Thomas Gleixner). * Add asm_ prefix to FRED asm entry points (Thomas Gleixner). Changes since v8: * Don't do syscall early out in fred_entry_from_user() before there are proper performance numbers and justifications (Thomas Gleixner). * Add the control exception handler to the FRED exception handler table (Thomas Gleixner). * Add ENDBR to the FRED_ENTER asm macro. * Reflect the FRED spec 5.0 change that ERETS and ERETU add 8 to %rsp before popping the return context from the stack. Changes since v1: * Initialize a FRED exception handler to fred_bad_event() instead of NULL if no FRED handler defined for an exception vector (Peter Zijlstra). * Push calling irqentry_{enter,exit}() and instrumentation_{begin,end}() down into individual FRED exception handlers, instead of in the dispatch framework (Peter Zijlstra). --- arch/x86/entry/Makefile | 5 +- arch/x86/entry/entry_64_fred.S | 52 ++++++ arch/x86/entry/entry_fred.c | 230 ++++++++++++++++++++++++++ arch/x86/include/asm/asm-prototypes.h | 1 + arch/x86/include/asm/fred.h | 6 + 5 files changed, 293 insertions(+), 1 deletion(-) create mode 100644 arch/x86/entry/entry_64_fred.S create mode 100644 arch/x86/entry/entry_fred.c diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile index ca2fe186994b..c93e7f5c2a06 100644 --- a/arch/x86/entry/Makefile +++ b/arch/x86/entry/Makefile @@ -18,6 +18,9 @@ obj-y +=3D vdso/ obj-y +=3D vsyscall/ =20 obj-$(CONFIG_PREEMPTION) +=3D thunk_$(BITS).o +CFLAGS_entry_fred.o +=3D -fno-stack-protector +CFLAGS_REMOVE_entry_fred.o +=3D -pg $(CC_FLAGS_FTRACE) +obj-$(CONFIG_X86_FRED) +=3D entry_64_fred.o entry_fred.o + obj-$(CONFIG_IA32_EMULATION) +=3D entry_64_compat.o syscall_32.o obj-$(CONFIG_X86_X32_ABI) +=3D syscall_x32.o - diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S new file mode 100644 index 000000000000..37a1dd5e8ace --- /dev/null +++ b/arch/x86/entry/entry_64_fred.S @@ -0,0 +1,52 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * The actual FRED entry points. + */ + +#include + +#include "calling.h" + + .code64 + .section .noinstr.text, "ax" + +.macro FRED_ENTER + UNWIND_HINT_END_OF_STACK + ENDBR + PUSH_AND_CLEAR_REGS + movq %rsp, %rdi /* %rdi -> pt_regs */ +.endm + +.macro FRED_EXIT + UNWIND_HINT_REGS + POP_REGS +.endm + +/* + * The new RIP value that FRED event delivery establishes is + * IA32_FRED_CONFIG & ~FFFH for events that occur in ring 3. + * Thus the FRED ring 3 entry point must be 4K page aligned. + */ + .align 4096 + +SYM_CODE_START_NOALIGN(asm_fred_entrypoint_user) + FRED_ENTER + call fred_entry_from_user + FRED_EXIT + ERETU +SYM_CODE_END(asm_fred_entrypoint_user) + +.fill asm_fred_entrypoint_kernel - ., 1, 0xcc + +/* + * The new RIP value that FRED event delivery establishes is + * (IA32_FRED_CONFIG & ~FFFH) + 256 for events that occur in + * ring 0, i.e., asm_fred_entrypoint_user + 256. + */ + .org asm_fred_entrypoint_user + 256 +SYM_CODE_START_NOALIGN(asm_fred_entrypoint_kernel) + FRED_ENTER + call fred_entry_from_kernel + FRED_EXIT + ERETS +SYM_CODE_END(asm_fred_entrypoint_kernel) diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c new file mode 100644 index 000000000000..dc645f5819a9 --- /dev/null +++ b/arch/x86/entry/entry_fred.c @@ -0,0 +1,230 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * The FRED specific kernel/user entry functions which are invoked from + * assembly code and dispatch to the associated handlers. + */ +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +/* FRED EVENT_TYPE_OTHER vector numbers */ +#define FRED_SYSCALL 1 +#define FRED_SYSENTER 2 + +static noinstr void fred_bad_type(struct pt_regs *regs, unsigned long erro= r_code) +{ + irqentry_state_t irq_state =3D irqentry_nmi_enter(regs); + + instrumentation_begin(); + + /* Panic on events from a high stack level */ + if (regs->sl > 0) { + pr_emerg("PANIC: invalid or fatal FRED event; event type %u " + "vector %u error 0x%lx aux 0x%lx at %04x:%016lx\n", + regs->fred_ss.type, regs->fred_ss.vector, regs->orig_ax, + fred_event_data(regs), regs->cs, regs->ip); + die("invalid or fatal FRED event", regs, regs->orig_ax); + panic("invalid or fatal FRED event"); + } else { + unsigned long flags =3D oops_begin(); + int sig =3D SIGKILL; + + pr_alert("BUG: invalid or fatal FRED event; event type %u " + "vector %u error 0x%lx aux 0x%lx at %04x:%016lx\n", + regs->fred_ss.type, regs->fred_ss.vector, regs->orig_ax, + fred_event_data(regs), regs->cs, regs->ip); + + if (__die("Invalid or fatal FRED event", regs, regs->orig_ax)) + sig =3D 0; + + oops_end(flags, regs, sig); + } + + instrumentation_end(); + irqentry_nmi_exit(regs, irq_state); +} + +static noinstr void fred_intx(struct pt_regs *regs) +{ + switch (regs->fred_ss.vector) { + /* INT0 */ + case X86_TRAP_OF: + exc_overflow(regs); + return; + + /* INT3 */ + case X86_TRAP_BP: + exc_int3(regs); + return; + + /* INT80 */ + case IA32_SYSCALL_VECTOR: + if (likely(IS_ENABLED(CONFIG_IA32_EMULATION))) { + /* Save the syscall number */ + regs->orig_ax =3D regs->ax; + regs->ax =3D -ENOSYS; + do_int80_syscall_32(regs); + return; + } + fallthrough; + + default: + exc_general_protection(regs, 0); + return; + } +} + +static __always_inline void fred_other(struct pt_regs *regs) +{ + /* The compiler can fold these conditions into a single test */ + if (likely(regs->fred_ss.vector =3D=3D FRED_SYSCALL && regs->fred_ss.lm))= { + regs->orig_ax =3D regs->ax; + regs->ax =3D -ENOSYS; + do_syscall_64(regs, regs->orig_ax); + return; + } else if (likely(IS_ENABLED(CONFIG_IA32_EMULATION) && + regs->fred_ss.vector =3D=3D FRED_SYSENTER && + !regs->fred_ss.lm)) { + regs->orig_ax =3D regs->ax; + regs->ax =3D -ENOSYS; + do_fast_syscall_32(regs); + return; + } else { + exc_invalid_op(regs); + return; + } +} + +#define SYSVEC(_vector, _function) [_vector - FIRST_SYSTEM_VECTOR] =3D fre= d_sysvec_##_function + +static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro_after_init =3D { + SYSVEC(ERROR_APIC_VECTOR, error_interrupt), + SYSVEC(SPURIOUS_APIC_VECTOR, spurious_apic_interrupt), + SYSVEC(LOCAL_TIMER_VECTOR, apic_timer_interrupt), + SYSVEC(X86_PLATFORM_IPI_VECTOR, x86_platform_ipi), + + SYSVEC(RESCHEDULE_VECTOR, reschedule_ipi), + SYSVEC(CALL_FUNCTION_SINGLE_VECTOR, call_function_single), + SYSVEC(CALL_FUNCTION_VECTOR, call_function), + SYSVEC(REBOOT_VECTOR, reboot), + + SYSVEC(THRESHOLD_APIC_VECTOR, threshold), + SYSVEC(DEFERRED_ERROR_VECTOR, deferred_error), + SYSVEC(THERMAL_APIC_VECTOR, thermal), + + SYSVEC(IRQ_WORK_VECTOR, irq_work), + + SYSVEC(POSTED_INTR_VECTOR, kvm_posted_intr_ipi), + SYSVEC(POSTED_INTR_WAKEUP_VECTOR, kvm_posted_intr_wakeup_ipi), + SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), +}; + +static noinstr void fred_extint(struct pt_regs *regs) +{ + unsigned int vector =3D regs->fred_ss.vector; + + if (WARN_ON_ONCE(vector < FIRST_EXTERNAL_VECTOR)) + return; + + if (likely(vector >=3D FIRST_SYSTEM_VECTOR)) { + irqentry_state_t state =3D irqentry_enter(regs); + + instrumentation_begin(); + sysvec_table[vector - FIRST_SYSTEM_VECTOR](regs); + instrumentation_end(); + irqentry_exit(regs, state); + } else { + common_interrupt(regs, vector); + } +} + +static noinstr void fred_exception(struct pt_regs *regs, unsigned long err= or_code) +{ + /* Optimize for #PF. That's the only exception which matters performance = wise */ + if (likely(regs->fred_ss.vector =3D=3D X86_TRAP_PF)) { + exc_page_fault(regs, error_code); + return; + } + + switch (regs->fred_ss.vector) { + case X86_TRAP_DE: return exc_divide_error(regs); + case X86_TRAP_DB: return fred_exc_debug(regs); + case X86_TRAP_BP: return exc_int3(regs); + case X86_TRAP_OF: return exc_overflow(regs); + case X86_TRAP_BR: return exc_bounds(regs); + case X86_TRAP_UD: return exc_invalid_op(regs); + case X86_TRAP_NM: return exc_device_not_available(regs); + case X86_TRAP_DF: return exc_double_fault(regs, error_code); + case X86_TRAP_TS: return exc_invalid_tss(regs, error_code); + case X86_TRAP_NP: return exc_segment_not_present(regs, error_code); + case X86_TRAP_SS: return exc_stack_segment(regs, error_code); + case X86_TRAP_GP: return exc_general_protection(regs, error_code); + case X86_TRAP_MF: return exc_coprocessor_error(regs); + case X86_TRAP_AC: return exc_alignment_check(regs, error_code); + case X86_TRAP_XF: return exc_simd_coprocessor_error(regs); + +#ifdef CONFIG_X86_MCE + case X86_TRAP_MC: return fred_exc_machine_check(regs); +#endif +#ifdef CONFIG_INTEL_TDX_GUEST + case X86_TRAP_VE: return exc_virtualization_exception(regs); +#endif +#ifdef CONFIG_X86_KERNEL_IBT + case X86_TRAP_CP: return exc_control_protection(regs, error_code); +#endif + default: return fred_bad_type(regs, error_code); + } +} + +__visible noinstr void fred_entry_from_user(struct pt_regs *regs) +{ + unsigned long error_code =3D regs->orig_ax; + + /* Invalidate orig_ax so that syscall_get_nr() works correctly */ + regs->orig_ax =3D -1; + + switch (regs->fred_ss.type) { + case EVENT_TYPE_EXTINT: + return fred_extint(regs); + case EVENT_TYPE_NMI: + return fred_exc_nmi(regs); + case EVENT_TYPE_SWINT: + return fred_intx(regs); + case EVENT_TYPE_HWEXC: + case EVENT_TYPE_SWEXC: + case EVENT_TYPE_PRIV_SWEXC: + return fred_exception(regs, error_code); + case EVENT_TYPE_OTHER: + return fred_other(regs); + default: + return fred_bad_type(regs, error_code); + } +} + +__visible noinstr void fred_entry_from_kernel(struct pt_regs *regs) +{ + unsigned long error_code =3D regs->orig_ax; + + /* Invalidate orig_ax so that syscall_get_nr() works correctly */ + regs->orig_ax =3D -1; + + switch (regs->fred_ss.type) { + case EVENT_TYPE_EXTINT: + return fred_extint(regs); + case EVENT_TYPE_NMI: + return fred_exc_nmi(regs); + case EVENT_TYPE_HWEXC: + case EVENT_TYPE_SWEXC: + case EVENT_TYPE_PRIV_SWEXC: + return fred_exception(regs, error_code); + default: + return fred_bad_type(regs, error_code); + } +} diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/a= sm-prototypes.h index b1a98fa38828..076bf8dee702 100644 --- a/arch/x86/include/asm/asm-prototypes.h +++ b/arch/x86/include/asm/asm-prototypes.h @@ -12,6 +12,7 @@ #include #include #include +#include #include =20 #ifndef CONFIG_X86_CMPXCHG64 diff --git a/arch/x86/include/asm/fred.h b/arch/x86/include/asm/fred.h index f514fdb5a39f..16a64ffecbf8 100644 --- a/arch/x86/include/asm/fred.h +++ b/arch/x86/include/asm/fred.h @@ -60,6 +60,12 @@ static __always_inline unsigned long fred_event_data(str= uct pt_regs *regs) return fred_info(regs)->edata; } =20 +void asm_fred_entrypoint_user(void); +void asm_fred_entrypoint_kernel(void); + +__visible void fred_entry_from_user(struct pt_regs *regs); +__visible void fred_entry_from_kernel(struct pt_regs *regs); + #else /* CONFIG_X86_FRED */ static __always_inline unsigned long fred_event_data(struct pt_regs *regs)= { return 0; } #endif /* CONFIG_X86_FRED */ --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 32A0BEDE981 for ; Thu, 14 Sep 2023 05:20:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235504AbjINFUm (ORCPT ); Thu, 14 Sep 2023 01:20:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235434AbjINFTw (ORCPT ); Thu, 14 Sep 2023 01:19:52 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B3872109; Wed, 13 Sep 2023 22:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668764; x=1726204764; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=+RlrgHiXutSgx6eL8XqhKvBuCjbeEldfualcJOd97C0=; b=A98twLtoGQTQio5fYj1oEK+egyhaWOVw6RV/C1ZY25TVAdbif+V9MKKm +pPFQJiO0ZSUofHGb/C60CNfYFmHwZu95H32fhBsd8XJLrUt3AJe2zZjI dGa0AvYG40K3QKWDEMqyopU88sNlru9CjOKOxis5OvKXxzRjLtxWOoNk1 qKdrNiWPbbbtULLb9bu3TvUTvMAAG6MEUkXzLiZsYxx4X8QHyJ6eKYG+e hqudiyaNzV5nYW+0cug85r2fQ6x/bTT1yMq4q4hxd0X75/8cq8naj0YqW hRxhIhypHLSfqH3fL1AzGYN5jddxqr9Iqpf8z7b1QrhIL7vPQIirRT4u7 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661446" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661446" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488826" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488826" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:44 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 29/38] x86/traps: Add sysvec_install() to install a system interrupt handler Date: Wed, 13 Sep 2023 21:47:56 -0700 Message-Id: <20230914044805.301390-30-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Add sysvec_install() to install a system interrupt handler into the IDT or the FRED system interrupt handler table. Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v8: * Introduce a macro sysvec_install() to derive the asm handler name from a C handler, which simplifies the code and avoids an ugly typecast (Thomas Gleixner). --- arch/x86/entry/entry_fred.c | 14 ++++++++++++++ arch/x86/include/asm/desc.h | 2 -- arch/x86/include/asm/idtentry.h | 15 +++++++++++++++ arch/x86/kernel/cpu/acrn.c | 4 ++-- arch/x86/kernel/cpu/mshyperv.c | 15 +++++++-------- arch/x86/kernel/idt.c | 4 ++-- arch/x86/kernel/kvm.c | 2 +- drivers/xen/events/events_base.c | 2 +- 8 files changed, 42 insertions(+), 16 deletions(-) diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c index dc645f5819a9..2fd3e421e066 100644 --- a/arch/x86/entry/entry_fred.c +++ b/arch/x86/entry/entry_fred.c @@ -126,6 +126,20 @@ static idtentry_t sysvec_table[NR_SYSTEM_VECTORS] __ro= _after_init =3D { SYSVEC(POSTED_INTR_NESTED_VECTOR, kvm_posted_intr_nested_ipi), }; =20 +static bool fred_setup_done __initdata; + +void __init fred_install_sysvec(unsigned int sysvec, idtentry_t handler) +{ + if (WARN_ON_ONCE(sysvec < FIRST_SYSTEM_VECTOR)) + return; + + if (WARN_ON_ONCE(fred_setup_done)) + return; + + if (!WARN_ON_ONCE(sysvec_table[sysvec - FIRST_SYSTEM_VECTOR])) + sysvec_table[sysvec - FIRST_SYSTEM_VECTOR] =3D handler; +} + static noinstr void fred_extint(struct pt_regs *regs) { unsigned int vector =3D regs->fred_ss.vector; diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h index ab97b22ac04a..ec95fe44fa3a 100644 --- a/arch/x86/include/asm/desc.h +++ b/arch/x86/include/asm/desc.h @@ -402,8 +402,6 @@ static inline void set_desc_limit(struct desc_struct *d= esc, unsigned long limit) desc->limit1 =3D (limit >> 16) & 0xf; } =20 -void alloc_intr_gate(unsigned int n, const void *addr); - static inline void init_idt_data(struct idt_data *data, unsigned int n, const void *addr) { diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentr= y.h index 4f26ee9b8b74..650c98160152 100644 --- a/arch/x86/include/asm/idtentry.h +++ b/arch/x86/include/asm/idtentry.h @@ -459,6 +459,21 @@ __visible noinstr void func(struct pt_regs *regs, \ #define DEFINE_FREDENTRY_DEBUG DEFINE_FREDENTRY_RAW #endif =20 +void idt_install_sysvec(unsigned int n, const void *function); + +#ifdef CONFIG_X86_FRED +void fred_install_sysvec(unsigned int vector, const idtentry_t function); +#else +static inline void fred_install_sysvec(unsigned int vector, const idtentry= _t function) { } +#endif + +#define sysvec_install(vector, function) { \ + if (cpu_feature_enabled(X86_FEATURE_FRED)) \ + fred_install_sysvec(vector, function); \ + else \ + idt_install_sysvec(vector, asm_##function); \ +} + #else /* !__ASSEMBLY__ */ =20 /* diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c index bfeb18fad63f..2c5b51aad91a 100644 --- a/arch/x86/kernel/cpu/acrn.c +++ b/arch/x86/kernel/cpu/acrn.c @@ -26,8 +26,8 @@ static u32 __init acrn_detect(void) =20 static void __init acrn_init_platform(void) { - /* Setup the IDT for ACRN hypervisor callback */ - alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, asm_sysvec_acrn_hv_callback); + /* Install system interrupt handler for ACRN hypervisor callback */ + sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_acrn_hv_callback); =20 x86_platform.calibrate_tsc =3D acrn_get_tsc_khz; x86_platform.calibrate_cpu =3D acrn_get_tsc_khz; diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c index e6bba12c759c..3403880c3e09 100644 --- a/arch/x86/kernel/cpu/mshyperv.c +++ b/arch/x86/kernel/cpu/mshyperv.c @@ -536,19 +536,18 @@ static void __init ms_hyperv_init_platform(void) */ x86_platform.apic_post_init =3D hyperv_init; hyperv_setup_mmu_ops(); - /* Setup the IDT for hypervisor callback */ - alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, asm_sysvec_hyperv_callback); =20 - /* Setup the IDT for reenlightenment notifications */ + /* Install system interrupt handler for hypervisor callback */ + sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_hyperv_callback); + + /* Install system interrupt handler for reenlightenment notifications */ if (ms_hyperv.features & HV_ACCESS_REENLIGHTENMENT) { - alloc_intr_gate(HYPERV_REENLIGHTENMENT_VECTOR, - asm_sysvec_hyperv_reenlightenment); + sysvec_install(HYPERV_REENLIGHTENMENT_VECTOR, sysvec_hyperv_reenlightenm= ent); } =20 - /* Setup the IDT for stimer0 */ + /* Install system interrupt handler for stimer0 */ if (ms_hyperv.misc_features & HV_STIMER_DIRECT_MODE_AVAILABLE) { - alloc_intr_gate(HYPERV_STIMER0_VECTOR, - asm_sysvec_hyperv_stimer0); + sysvec_install(HYPERV_STIMER0_VECTOR, sysvec_hyperv_stimer0); } =20 # ifdef CONFIG_SMP diff --git a/arch/x86/kernel/idt.c b/arch/x86/kernel/idt.c index b786d48f5a0f..0db7d92de48a 100644 --- a/arch/x86/kernel/idt.c +++ b/arch/x86/kernel/idt.c @@ -330,7 +330,7 @@ void idt_invalidate(void) load_idt(&idt); } =20 -void __init alloc_intr_gate(unsigned int n, const void *addr) +void __init idt_install_sysvec(unsigned int n, const void *function) { if (WARN_ON(n < FIRST_SYSTEM_VECTOR)) return; @@ -339,5 +339,5 @@ void __init alloc_intr_gate(unsigned int n, const void = *addr) return; =20 if (!WARN_ON(test_and_set_bit(n, system_vectors))) - set_intr_gate(n, addr); + set_intr_gate(n, function); } diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c index b8ab9ee5896c..eabf03813a5c 100644 --- a/arch/x86/kernel/kvm.c +++ b/arch/x86/kernel/kvm.c @@ -829,7 +829,7 @@ static void __init kvm_guest_init(void) =20 if (kvm_para_has_feature(KVM_FEATURE_ASYNC_PF_INT) && kvmapf) { static_branch_enable(&kvm_async_pf_enabled); - alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, asm_sysvec_kvm_asyncpf_inter= rupt); + sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_kvm_asyncpf_interrupt); } =20 #ifdef CONFIG_SMP diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_b= ase.c index 3bdd5b59661d..c54123ca7b1a 100644 --- a/drivers/xen/events/events_base.c +++ b/drivers/xen/events/events_base.c @@ -2243,7 +2243,7 @@ static __init void xen_alloc_callback_vector(void) return; =20 pr_info("Xen HVM callback vector for event delivery is enabled\n"); - alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, asm_sysvec_xen_hvm_callback); + sysvec_install(HYPERVISOR_CALLBACK_VECTOR, sysvec_xen_hvm_callback); } #else void xen_setup_callback_vector(void) {} --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 000FEEDE981 for ; Thu, 14 Sep 2023 05:20:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235846AbjINFUq (ORCPT ); Thu, 14 Sep 2023 01:20:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235447AbjINFTx (ORCPT ); Thu, 14 Sep 2023 01:19:53 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 903682110; Wed, 13 Sep 2023 22:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668764; x=1726204764; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=M6fmRAapBD1o7lcFP0DE6JJOLTPbVa+6x+sO9If/vNA=; b=hlQOIJCIBUTSnhebYrT5AkuQGB95vOGW02WTEZpV8Z+Y4gMYPqdgOb8j 4VbZoDS7SKJEUafGgqYkHKHIj3l7sCk4eIt6+HFoXONYFiNrEqcnwZBzM QtToJPOk79G9ncwLT7fNo+6JUR7ZFk2jNQEN1lsyXk00O+0Go1lT72cag Kem2l49MLVO4s2BLE1ooQydYsVbXJsrkBwyTLMXF5iY9B5Hm/2Tx+9601 XgeAkoCHiKEASfGppgmepnW4FM72HF/CZYNdiVbfo9A4SvF7+NxUJT9J1 IghRtbZazismvWuXwD9WioaXx78GL2HNIvSDCmi75ZgC7jX7yqqiDGA9b A==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661458" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661458" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488829" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488829" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:44 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 30/38] x86/fred: Let ret_from_fork_asm() jmp to asm_fred_exit_user when FRED is enabled Date: Wed, 13 Sep 2023 21:47:57 -0700 Message-Id: <20230914044805.301390-31-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Let ret_from_fork_asm() jmp to asm_fred_exit_user when FRED is enabled, otherwise the existing IDT code is chosen. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/entry/entry_64.S | 6 ++++++ arch/x86/entry/entry_64_fred.S | 1 + 2 files changed, 7 insertions(+) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 9cdb61ea91de..c9e14617dd3f 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -309,7 +309,13 @@ SYM_CODE_START(ret_from_fork_asm) * and unwind should work normally. */ UNWIND_HINT_REGS + +#ifdef CONFIG_X86_FRED + ALTERNATIVE "jmp swapgs_restore_regs_and_return_to_usermode", \ + "jmp asm_fred_exit_user", X86_FEATURE_FRED +#else jmp swapgs_restore_regs_and_return_to_usermode +#endif SYM_CODE_END(ret_from_fork_asm) .popsection =20 diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S index 37a1dd5e8ace..5781c3411b44 100644 --- a/arch/x86/entry/entry_64_fred.S +++ b/arch/x86/entry/entry_64_fred.S @@ -32,6 +32,7 @@ SYM_CODE_START_NOALIGN(asm_fred_entrypoint_user) FRED_ENTER call fred_entry_from_user +SYM_INNER_LABEL(asm_fred_exit_user, SYM_L_GLOBAL) FRED_EXIT ERETU SYM_CODE_END(asm_fred_entrypoint_user) --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 1B4D3EDE980 for ; Thu, 14 Sep 2023 05:20:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234685AbjINFUs (ORCPT ); Thu, 14 Sep 2023 01:20:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235483AbjINFTx (ORCPT ); Thu, 14 Sep 2023 01:19:53 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E36562115; Wed, 13 Sep 2023 22:19:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668765; x=1726204765; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=I/WDYuAd3nxCrdi9nQ03uROwALnkbrNhAERS8D1SLLE=; b=k3jfzxNFxmFHW0jJPS++DydJROgU7oNlWT12qzfJiR58z6y19Pt4rlTv n8YOLvIJF+3nkyVaIP1DWweEE86uFNfPdBRACpTTNMSMQdQgj0zgnsB4u 6b5iFXildzyygTVxfCZC72gVf73HBSqCiHfBnAdWrZeqNZZ+64mhj79eO qxgST0DL5pKhfqbUCyKlvqBldU0VJR+yprzsj6bDmJlk1Sf/AUO3JOKrz l+kJ2F8aG+3ftkYuGKGcuYnE0narwylCC2PHTrk8WnhWNYgfcLQ3cjljT ltF86YWDXqrp6MHYggTQXc8ss4ah9wJ1zRDjxo0pp4xRU+sv6ont3dTcN g==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661470" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661470" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488832" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488832" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:45 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 31/38] x86/fred: Fixup fault on ERETU by jumping to fred_entrypoint_user Date: Wed, 13 Sep 2023 21:47:58 -0700 Message-Id: <20230914044805.301390-32-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" If the stack frame contains an invalid user context (e.g. due to invalid SS, a non-canonical RIP, etc.) the ERETU instruction will trap (#SS or #GP). From a Linux point of view, this really should be considered a user space failure, so use the standard fault fixup mechanism to intercept the fault, fix up the exception frame, and redirect execution to fred_entrypoint_user. The end result is that it appears just as if the hardware had taken the exception immediately after completing the transition to user space. Suggested-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v8: * Reflect the FRED spec 5.0 change that ERETS and ERETU add 8 to %rsp before popping the return context from the stack. Changes since v6: * Add a comment to explain why it is safe to write to the previous FRED sta= ck frame. (Lai Jiangshan). Changes since v5: * Move the NMI bit from an invalid stack frame, which caused ERETU to fault, to the fault handler's stack frame, thus to unblock NMI ASAP if NMI is bl= ocked (Lai Jiangshan). --- arch/x86/entry/entry_64_fred.S | 5 +- arch/x86/include/asm/extable_fixup_types.h | 4 +- arch/x86/mm/extable.c | 79 ++++++++++++++++++++++ 3 files changed, 86 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S index 5781c3411b44..d1c2fc4af8ae 100644 --- a/arch/x86/entry/entry_64_fred.S +++ b/arch/x86/entry/entry_64_fred.S @@ -3,6 +3,7 @@ * The actual FRED entry points. */ =20 +#include #include =20 #include "calling.h" @@ -34,7 +35,9 @@ SYM_CODE_START_NOALIGN(asm_fred_entrypoint_user) call fred_entry_from_user SYM_INNER_LABEL(asm_fred_exit_user, SYM_L_GLOBAL) FRED_EXIT - ERETU +1: ERETU + + _ASM_EXTABLE_TYPE(1b, asm_fred_entrypoint_user, EX_TYPE_ERETU) SYM_CODE_END(asm_fred_entrypoint_user) =20 .fill asm_fred_entrypoint_kernel - ., 1, 0xcc diff --git a/arch/x86/include/asm/extable_fixup_types.h b/arch/x86/include/= asm/extable_fixup_types.h index 991e31cfde94..1585c798a02f 100644 --- a/arch/x86/include/asm/extable_fixup_types.h +++ b/arch/x86/include/asm/extable_fixup_types.h @@ -64,6 +64,8 @@ #define EX_TYPE_UCOPY_LEN4 (EX_TYPE_UCOPY_LEN | EX_DATA_IMM(4)) #define EX_TYPE_UCOPY_LEN8 (EX_TYPE_UCOPY_LEN | EX_DATA_IMM(8)) =20 -#define EX_TYPE_ZEROPAD 20 /* longword load with zeropad on fault */ +#define EX_TYPE_ZEROPAD 20 /* longword load with zeropad on fault */ + +#define EX_TYPE_ERETU 21 =20 #endif diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c index 271dcb2deabc..bc7af7e8587b 100644 --- a/arch/x86/mm/extable.c +++ b/arch/x86/mm/extable.c @@ -6,6 +6,7 @@ #include =20 #include +#include #include #include #include @@ -223,6 +224,80 @@ static bool ex_handler_ucopy_len(const struct exceptio= n_table_entry *fixup, return ex_handler_uaccess(fixup, regs, trapnr, fault_address); } =20 +#ifdef CONFIG_X86_FRED +static bool ex_handler_eretu(const struct exception_table_entry *fixup, + struct pt_regs *regs, unsigned long error_code) +{ + struct pt_regs *uregs =3D (struct pt_regs *) + (regs->sp - offsetof(struct pt_regs, orig_ax)); + unsigned short ss =3D uregs->ss; + unsigned short cs =3D uregs->cs; + + /* + * Move the NMI bit from the invalid stack frame, which caused ERETU + * to fault, to the fault handler's stack frame, thus to unblock NMI + * with the fault handler's ERETS instruction ASAP if NMI is blocked. + */ + regs->fred_ss.nmi =3D uregs->fred_ss.nmi; + + /* + * Sync event information to uregs, i.e., the ERETU return frame, but + * is it safe to write to the ERETU return frame which is just above + * current event stack frame? + * + * The RSP used by FRED to push a stack frame is not the value in %rsp, + * it is calculated from %rsp with the following 2 steps: + * 1) RSP =3D %rsp - (IA32_FRED_CONFIG & 0x1c0) // Reserve N*64 bytes + * 2) RSP =3D RSP & ~0x3f // Align to a 64-byte cache line + * when an event delivery doesn't trigger a stack level change. + * + * Here is an example with N*64 (N=3D1) bytes reserved: + * + * 64-byte cache line =3D=3D> ______________ + * |___Reserved___| + * |__Event_data__| + * |_____SS_______| + * |_____RSP______| + * |_____FLAGS____| + * |_____CS_______| + * |_____IP_______| + * 64-byte cache line =3D=3D> |__Error_code__| <=3D=3D ERETU return frame + * |______________| + * |______________| + * |______________| + * |______________| + * |______________| + * |______________| + * |______________| + * 64-byte cache line =3D=3D> |______________| <=3D=3D RSP after step 1)= and 2) + * |___Reserved___| + * |__Event_data__| + * |_____SS_______| + * |_____RSP______| + * |_____FLAGS____| + * |_____CS_______| + * |_____IP_______| + * 64-byte cache line =3D=3D> |__Error_code__| <=3D=3D ERETS return frame + * + * Thus a new FRED stack frame will always be pushed below a previous + * FRED stack frame ((N*64) bytes may be reserved between), and it is + * safe to write to a previous FRED stack frame as they never overlap. + */ + fred_info(uregs)->edata =3D fred_event_data(regs); + uregs->ssx =3D regs->ssx; + uregs->fred_ss.ss =3D ss; + /* The NMI bit was moved away above */ + uregs->fred_ss.nmi =3D 0; + uregs->csx =3D regs->csx; + uregs->sl =3D 0; + uregs->wfe =3D 0; + uregs->cs =3D cs; + uregs->orig_ax =3D error_code; + + return ex_handler_default(fixup, regs); +} +#endif + int ex_get_fixup_type(unsigned long ip) { const struct exception_table_entry *e =3D search_exception_tables(ip); @@ -300,6 +375,10 @@ int fixup_exception(struct pt_regs *regs, int trapnr, = unsigned long error_code, return ex_handler_ucopy_len(e, regs, trapnr, fault_addr, reg, imm); case EX_TYPE_ZEROPAD: return ex_handler_zeropad(e, regs, fault_addr); +#ifdef CONFIG_X86_FRED + case EX_TYPE_ERETU: + return ex_handler_eretu(e, regs, error_code); +#endif } BUG(); } --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 24C0EEDE986 for ; Thu, 14 Sep 2023 05:20:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235905AbjINFU4 (ORCPT ); Thu, 14 Sep 2023 01:20:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235541AbjINFT4 (ORCPT ); Thu, 14 Sep 2023 01:19:56 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 734BE1BDC; Wed, 13 Sep 2023 22:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668765; x=1726204765; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/UldAmuJEnsflYS2+cyLAQ4E+J1yAKX8pToUnF0eneI=; b=TaqSvYNn4Heg6xWEoZQghBw7imXmV6uvN9jLDbnvrSAS14kGbc0sl49L wzusu0pNQ5pWIKbeqsLuG+wyoL5lTPdtuYXkn+mxtbRAhPHH6aU8F5wdE mp25g8eVOe0QYfKWmARmCrQ35ROiX977LaD8CsY9tZLGsAH/xPpQi/jhP NW94FQP2kM9F6EnKUVvLjHV2KIUVby3DOcjLLy82wyP8cKqiLokW7Bky7 g5hj12MCJIW9o5+yS7WCJ30ptwLJFmq9B7d3UniULqUTs1YZ3yGe1tCVL LUXVzwxOepASpAi4Z72pZOuEHIw2cBQJd8AEKICHCkYjppVjK+A9+40Mj w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661484" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661484" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488835" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488835" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:45 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 32/38] x86/entry/calling: Allow PUSH_AND_CLEAR_REGS being used beyond actual entry code Date: Wed, 13 Sep 2023 21:47:59 -0700 Message-Id: <20230914044805.301390-33-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "Peter Zijlstra (Intel)" PUSH_AND_CLEAR_REGS could be used besides actual entry code; in that case %rbp shouldn't be cleared (otherwise the frame pointer is destroyed) and UNWIND_HINT shouldn't be added. Signed-off-by: Peter Zijlstra (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/entry/calling.h | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h index f6907627172b..eb57c023d5df 100644 --- a/arch/x86/entry/calling.h +++ b/arch/x86/entry/calling.h @@ -65,7 +65,7 @@ For 32-bit we have the following conventions - kernel is = built with * for assembly code: */ =20 -.macro PUSH_REGS rdx=3D%rdx rcx=3D%rcx rax=3D%rax save_ret=3D0 +.macro PUSH_REGS rdx=3D%rdx rcx=3D%rcx rax=3D%rax save_ret=3D0 unwind_hint= =3D1 .if \save_ret pushq %rsi /* pt_regs->si */ movq 8(%rsp), %rsi /* temporarily store the return address in %rsi */ @@ -87,14 +87,17 @@ For 32-bit we have the following conventions - kernel i= s built with pushq %r13 /* pt_regs->r13 */ pushq %r14 /* pt_regs->r14 */ pushq %r15 /* pt_regs->r15 */ + + .if \unwind_hint UNWIND_HINT_REGS + .endif =20 .if \save_ret pushq %rsi /* return address on top of stack */ .endif .endm =20 -.macro CLEAR_REGS +.macro CLEAR_REGS clear_bp=3D1 /* * Sanitize registers of values that a speculation attack might * otherwise want to exploit. The lower registers are likely clobbered @@ -109,7 +112,9 @@ For 32-bit we have the following conventions - kernel i= s built with xorl %r10d, %r10d /* nospec r10 */ xorl %r11d, %r11d /* nospec r11 */ xorl %ebx, %ebx /* nospec rbx */ + .if \clear_bp xorl %ebp, %ebp /* nospec rbp */ + .endif xorl %r12d, %r12d /* nospec r12 */ xorl %r13d, %r13d /* nospec r13 */ xorl %r14d, %r14d /* nospec r14 */ @@ -117,9 +122,9 @@ For 32-bit we have the following conventions - kernel i= s built with =20 .endm =20 -.macro PUSH_AND_CLEAR_REGS rdx=3D%rdx rcx=3D%rcx rax=3D%rax save_ret=3D0 - PUSH_REGS rdx=3D\rdx, rcx=3D\rcx, rax=3D\rax, save_ret=3D\save_ret - CLEAR_REGS +.macro PUSH_AND_CLEAR_REGS rdx=3D%rdx rcx=3D%rcx rax=3D%rax save_ret=3D0 c= lear_bp=3D1 unwind_hint=3D1 + PUSH_REGS rdx=3D\rdx, rcx=3D\rcx, rax=3D\rax, save_ret=3D\save_ret unwind= _hint=3D\unwind_hint + CLEAR_REGS clear_bp=3D\clear_bp .endm =20 .macro POP_REGS pop_rdi=3D1 --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 B7E09EDE981 for ; Thu, 14 Sep 2023 05:21:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235996AbjINFVM (ORCPT ); Thu, 14 Sep 2023 01:21:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234822AbjINFUE (ORCPT ); Thu, 14 Sep 2023 01:20:04 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBA8D2126; Wed, 13 Sep 2023 22:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668766; x=1726204766; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=q3Z+nMXlKl4d8APy8tB7Jrc++CPbfQFwd1zn6dKyIm8=; b=kX8FTNNPxGe2DW8J6jtWlMYwDXLttEPl6shf9BaGIP5EvXFPWFKYXcI5 6JQD69jbzXmv85fXPKFEORY40hYFGG4xWvPgKFGaTxYinyFf4zASMmR+w ZBVOQcKJ/NoRLbk7gwZne1SpjnsKFH5CNGqTCnTjBg7KNYcU1DSgqTmEV rOfHEVayiVbAaFrB3iUVzgoP9nabrQYhHkOtP+dItMRzq/+hnm0xt8Np7 bLHB4sTSn0flq0brJXUBsKX+rghCUI75GBq4tcsCeE5PE/lYZKgoLyBhn uFJr27HszT5Xc01Au34SQftZ6PWDw9p06a8WHv1Ft9+ge9DB2EARtGqjx w==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661497" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661497" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488838" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488838" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:46 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 33/38] x86/entry: Add fred_entry_from_kvm() for VMX to handle IRQ/NMI Date: Wed, 13 Sep 2023 21:48:00 -0700 Message-Id: <20230914044805.301390-34-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" In IRQ/NMI induced VM exits, KVM VMX needs to execute the respective handlers, which requires the software to create a FRED stack frame, and use it to invoke the handlers. Add fred_irq_entry_from_kvm() for this job. Export fred_entry_from_kvm() because VMX can be compiled as a module. Suggested-by: Sean Christopherson Tested-by: Shan Kang Signed-off-by: Thomas Gleixner Signed-off-by: Xin Li --- Changes since v9: * Shove the whole thing into arch/x86/entry/entry_64_fred.S for invoking external_interrupt() and fred_exc_nmi() (Sean Christopherson). * Correct and improve a few comments (Sean Christopherson). * Merge the two IRQ/NMI asm entries into one as it's fine to invoke noinstr code from regular code (Thomas Gleixner). * Setup the long mode and NMI flags in the augmented SS field of FRED stack frame in C instead of asm (Thomas Gleixner). * Add UNWIND_HINT_{SAVE,RESTORE} to get rid of the warning: "objtool: asm_fred_entry_from_kvm+0x0: unreachable instruction" (Peter Zijlstra). Changes since v8: * Add a new macro VMX_DO_FRED_EVENT_IRQOFF for FRED instead of refactoring VMX_DO_EVENT_IRQOFF (Sean Christopherson). * Do NOT use a trampoline, just LEA+PUSH the return RIP, PUSH the error code, and jump to the FRED kernel entry point for NMI or call external_interrupt() for IRQs (Sean Christopherson). * Call external_interrupt() only when FRED is enabled, and convert the non-FRED handling to external_interrupt() after FRED lands (Sean Christopherson). --- arch/x86/entry/entry_64_fred.S | 73 ++++++++++++++++++++++++++++++++++ arch/x86/entry/entry_fred.c | 14 +++++++ arch/x86/include/asm/fred.h | 18 +++++++++ 3 files changed, 105 insertions(+) diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S index d1c2fc4af8ae..f1088d6f2054 100644 --- a/arch/x86/entry/entry_64_fred.S +++ b/arch/x86/entry/entry_64_fred.S @@ -4,7 +4,9 @@ */ =20 #include +#include #include +#include =20 #include "calling.h" =20 @@ -54,3 +56,74 @@ SYM_CODE_START_NOALIGN(asm_fred_entrypoint_kernel) FRED_EXIT ERETS SYM_CODE_END(asm_fred_entrypoint_kernel) + +#if IS_ENABLED(CONFIG_KVM_INTEL) +SYM_FUNC_START(asm_fred_entry_from_kvm) + push %rbp + mov %rsp, %rbp + + UNWIND_HINT_SAVE + + /* + * Don't check the FRED stack level, the call stack leading to this + * helper is effectively constant and shallow (relatively speaking). + * + * Emulate the FRED-defined redzone and stack alignment. + */ + sub $(FRED_CONFIG_REDZONE_AMOUNT << 6), %rsp + and $FRED_STACK_FRAME_RSP_MASK, %rsp + + /* + * Start to push a FRED stack frame, which is always 64 bytes: + * + * +--------+-----------------+ + * | Bytes | Usage | + * +--------+-----------------+ + * | 63:56 | Reserved | + * | 55:48 | Event Data | + * | 47:40 | SS + Event Info | + * | 39:32 | RSP | + * | 31:24 | RFLAGS | + * | 23:16 | CS + Aux Info | + * | 15:8 | RIP | + * | 7:0 | Error Code | + * +--------+-----------------+ + */ + push $0 /* Reserved, must be 0 */ + push $0 /* Event data, 0 for IRQ/NMI */ + push %rdi /* fred_ss handed in by the caller */ + push %rbp + pushf + mov $__KERNEL_CS, %rax + push %rax + + /* + * Unlike the IDT event delivery, FRED _always_ pushes an error code + * after pushing the return RIP, thus the CALL instruction CANNOT be + * used here to push the return RIP, otherwise there is no chance to + * push an error code before invoking the IRQ/NMI handler. + * + * Use LEA to get the return RIP and push it, then push an error code. + */ + lea 1f(%rip), %rax + push %rax /* Return RIP */ + push $0 /* Error code, 0 for IRQ/NMI */ + + PUSH_AND_CLEAR_REGS clear_bp=3D0 unwind_hint=3D0 + movq %rsp, %rdi /* %rdi -> pt_regs */ + call __fred_entry_from_kvm /* Call the C entry point */ + POP_REGS + ERETS +1: + /* + * Objtool doesn't understand what ERETS does, this hint tells it that + * yes, we'll reach here and with what stack state. A save/restore pair + * isn't strictly needed, but it's the simplest form. + */ + UNWIND_HINT_RESTORE + pop %rbp + RET + +SYM_FUNC_END(asm_fred_entry_from_kvm) +EXPORT_SYMBOL_GPL(asm_fred_entry_from_kvm); +#endif diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c index 2fd3e421e066..f8774611af80 100644 --- a/arch/x86/entry/entry_fred.c +++ b/arch/x86/entry/entry_fred.c @@ -242,3 +242,17 @@ __visible noinstr void fred_entry_from_kernel(struct p= t_regs *regs) return fred_bad_type(regs, error_code); } } + +#if IS_ENABLED(CONFIG_KVM_INTEL) +__visible noinstr void __fred_entry_from_kvm(struct pt_regs *regs) +{ + switch (regs->fred_ss.type) { + case EVENT_TYPE_EXTINT: + return fred_extint(regs); + case EVENT_TYPE_NMI: + return fred_exc_nmi(regs); + default: + WARN_ON_ONCE(1); + } +} +#endif diff --git a/arch/x86/include/asm/fred.h b/arch/x86/include/asm/fred.h index 16a64ffecbf8..2fa9f34e5c95 100644 --- a/arch/x86/include/asm/fred.h +++ b/arch/x86/include/asm/fred.h @@ -9,6 +9,7 @@ #include =20 #include +#include =20 /* * FRED event return instruction opcodes for ERET{S,U}; supported in @@ -62,12 +63,29 @@ static __always_inline unsigned long fred_event_data(st= ruct pt_regs *regs) =20 void asm_fred_entrypoint_user(void); void asm_fred_entrypoint_kernel(void); +void asm_fred_entry_from_kvm(struct fred_ss); =20 __visible void fred_entry_from_user(struct pt_regs *regs); __visible void fred_entry_from_kernel(struct pt_regs *regs); +__visible void __fred_entry_from_kvm(struct pt_regs *regs); + +/* Can be called from noinstr code, thus __always_inline */ +static __always_inline void fred_entry_from_kvm(unsigned int type, unsigne= d int vector) +{ + struct fred_ss ss =3D { + .ss =3D__KERNEL_DS, + .type =3D type, + .vector =3D vector, + .nmi =3D type =3D=3D EVENT_TYPE_NMI, + .lm =3D 1, + }; + + asm_fred_entry_from_kvm(ss); +} =20 #else /* CONFIG_X86_FRED */ static __always_inline unsigned long fred_event_data(struct pt_regs *regs)= { return 0; } +static __always_inline void fred_entry_from_kvm(unsigned int type, unsigne= d int vector) { } #endif /* CONFIG_X86_FRED */ #endif /* !__ASSEMBLY__ */ =20 --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 5BEA9EDE981 for ; Thu, 14 Sep 2023 05:20:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235034AbjINFU7 (ORCPT ); Thu, 14 Sep 2023 01:20:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235199AbjINFUC (ORCPT ); Thu, 14 Sep 2023 01:20:02 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 530E12122; Wed, 13 Sep 2023 22:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668766; x=1726204766; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=T0jTyejyJ8JvDYansScu0V1dL1MHLI4ucPruSc2ZVaA=; b=h0h99R6OY5/nOSiEIXvynNt43Y4BJHh6hoxNoYCgOCp24tPeHsnB9KjE iT9l5pGI3OWBVbUBbcirR9tb6Ra3j79x4OzXkwJJJ7ojocxN/QFHZ49Vc YVrytypL6blQbjGGUZPjsNwgeqOEd7pKyt5oVqAwWfiS60DqvKBy2YLEm gAxZYJp6wlpBm/e0DWg0DOp4kPVtnZxP3m1s/NkiQ1Rk9bxq22wMvDnmp m91A/li/977op/1/zgjFpmAl8fKlOVyHopwk5/2QFR3wiF1+pX1+212cw K6B9I3hDxp8fdm4kfcrilLpIhL//IR2gKzuUCXHumSV1WkBHa3vgXaNre Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661510" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661510" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488841" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488841" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:46 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 34/38] KVM: VMX: Call fred_entry_from_kvm() for IRQ/NMI handling Date: Wed, 13 Sep 2023 21:48:01 -0700 Message-Id: <20230914044805.301390-35-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" When FRED is enabled, call fred_entry_from_kvm() to handle IRQ/NMI in IRQ/NMI induced VM exits. Tested-by: Shan Kang Signed-off-by: Xin Li Acked-by: Paolo Bonzini --- arch/x86/kvm/vmx/vmx.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 72e3943f3693..db55b8418fa3 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -38,6 +38,7 @@ #include #include #include +#include #include #include #include @@ -6962,14 +6963,16 @@ static void handle_external_interrupt_irqoff(struct= kvm_vcpu *vcpu) { u32 intr_info =3D vmx_get_intr_info(vcpu); unsigned int vector =3D intr_info & INTR_INFO_VECTOR_MASK; - gate_desc *desc =3D (gate_desc *)host_idt_base + vector; =20 if (KVM_BUG(!is_external_intr(intr_info), vcpu->kvm, "unexpected VM-Exit interrupt info: 0x%x", intr_info)) return; =20 kvm_before_interrupt(vcpu, KVM_HANDLING_IRQ); - vmx_do_interrupt_irqoff(gate_offset(desc)); + if (cpu_feature_enabled(X86_FEATURE_FRED)) + fred_entry_from_kvm(EVENT_TYPE_EXTINT, vector); + else + vmx_do_interrupt_irqoff(gate_offset((gate_desc *)host_idt_base + vector)= ); kvm_after_interrupt(vcpu); =20 vcpu->arch.at_instruction_boundary =3D true; @@ -7262,7 +7265,10 @@ static noinstr void vmx_vcpu_enter_exit(struct kvm_v= cpu *vcpu, if ((u16)vmx->exit_reason.basic =3D=3D EXIT_REASON_EXCEPTION_NMI && is_nmi(vmx_get_intr_info(vcpu))) { kvm_before_interrupt(vcpu, KVM_HANDLING_NMI); - vmx_do_nmi_irqoff(); + if (cpu_feature_enabled(X86_FEATURE_FRED)) + fred_entry_from_kvm(EVENT_TYPE_NMI, NMI_VECTOR); + else + vmx_do_nmi_irqoff(); kvm_after_interrupt(vcpu); } =20 --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 1C03FEDE981 for ; Thu, 14 Sep 2023 05:21:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235989AbjINFVJ (ORCPT ); Thu, 14 Sep 2023 01:21:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235585AbjINFUE (ORCPT ); Thu, 14 Sep 2023 01:20:04 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3CD05212A; Wed, 13 Sep 2023 22:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668767; x=1726204767; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=JgWsUmRzFqYpgTYtV9G6HHx6xStONu7aAX4AcJEGcLI=; b=ZQ9ZXuzv7q1fzcs7Tpo4U8Jn1u9vLw2zk4b0/VwJG3LiBXvM91SM7OE7 JVbRI3GlIQ8+e13/X2w+M11gMwyjqzoxzeiKdAKjXxgLJI4ib7KKZeIqW otP6aVJfEOkgxUW3+5t2rqW9+2PYEUzEkiqiZPMQWa4LwbWQHTMh1tnAE pA/k/OESxlZQZvIvWPJa6CCz0ET9pxkWrVzjFW9UqEuTHnMtNTtkTMaM/ keJ7dnzd2EdsCK4b/0/aaiNRJknevttpWVic0qtjlVjuFz/UJn1ZpXRNj QGFtdlXKUiL2pDGpl0jYmI4pKjd5XlGxc+3rzHkOi/XNdvzTDN+sGvCsq Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661530" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661530" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488844" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488844" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:47 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 35/38] x86/syscall: Split IDT syscall setup code into idt_syscall_init() Date: Wed, 13 Sep 2023 21:48:02 -0700 Message-Id: <20230914044805.301390-36-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Split IDT syscall setup code into idt_syscall_init() to make it cleaner to add FRED syscall setup code. Suggested-by: Thomas Gleixner Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kernel/cpu/common.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 42511209469b..d960b7276008 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2070,10 +2070,8 @@ static void wrmsrl_cstar(unsigned long val) wrmsrl(MSR_CSTAR, val); } =20 -/* May not be marked __init: used by software suspend */ -void syscall_init(void) +static inline void idt_syscall_init(void) { - wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS); wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64); =20 #ifdef CONFIG_IA32_EMULATION @@ -2107,6 +2105,15 @@ void syscall_init(void) X86_EFLAGS_AC|X86_EFLAGS_ID); } =20 +/* May not be marked __init: used by software suspend */ +void syscall_init(void) +{ + /* The default user and kernel segments */ + wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS); + + idt_syscall_init(); +} + #else /* CONFIG_X86_64 */ =20 #ifdef CONFIG_STACKPROTECTOR --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 BF205EDE981 for ; Thu, 14 Sep 2023 05:21:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235671AbjINFVF (ORCPT ); Thu, 14 Sep 2023 01:21:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235309AbjINFUF (ORCPT ); Thu, 14 Sep 2023 01:20:05 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74E4C212E; Wed, 13 Sep 2023 22:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668767; x=1726204767; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=DfU6e7Lxi3caIgHaas3RwgcYA9izTEYulGU0upU0hWQ=; b=ZzL6Kn4cqvAk6SV+zVcfAh1hkxVgYHhwoavTha/1ib/qszt4DPW2W38l G/zrHXbGWXq9QOEccAhBkpu6K+WHiBBH8EvoXsjMBNTCraepdmX7YEplF yHgd6DpyqRyddeNLmUJG1TYDcZN1BtOMU5JE59x7YixKWlZ/0nN9517Oo p9/YG3kcWg7G7tRyiMdVIWlhZYpq20XLyq37fRQBNUaUP78pVpRCwj7i5 0d2LvX/8vYZsEEO3OkCPPkYAQQHetkYo5f1XG2v6TiK0CuYXiU2IzjkN1 7ccVewM14F6YGA+O0FOLJb7bT2fIzJRdriaqJCHW4jND+ypmPimq+Uucc Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661535" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661535" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488847" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488847" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:47 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 36/38] x86/fred: Add fred_syscall_init() Date: Wed, 13 Sep 2023 21:48:03 -0700 Message-Id: <20230914044805.301390-37-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Add a syscall initialization function fred_syscall_init() for FRED, and this is really just to skip setting up SYSCALL/SYSENTER related MSRs, e.g., MSR_LSTAR and invalidate SYSENTER configurations, because FRED uses the ring 3 FRED entrypoint for SYSCALL and SYSENTER, and ERETU is the only legit instruction to return to ring 3 per FRED spec 5.0. Signed-off-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- arch/x86/kernel/cpu/common.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index d960b7276008..4cb36e241c9a 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2105,6 +2105,23 @@ static inline void idt_syscall_init(void) X86_EFLAGS_AC|X86_EFLAGS_ID); } =20 +static inline void fred_syscall_init(void) +{ + /* + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL + * and SYSENTER, and ERETU is the only legit instruction to return to + * ring 3, as a result there is _no_ need to setup the SYSCALL and + * SYSENTER MSRs. + * + * Note, both sysexit and sysret cause #UD when FRED is enabled. + */ + wrmsrl(MSR_LSTAR, 0ULL); + wrmsrl_cstar(0ULL); + wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)GDT_ENTRY_INVALID_SEG); + wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL); + wrmsrl_safe(MSR_IA32_SYSENTER_EIP, 0ULL); +} + /* May not be marked __init: used by software suspend */ void syscall_init(void) { --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 8FBC0EDE981 for ; Thu, 14 Sep 2023 05:21:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236006AbjINFVP (ORCPT ); Thu, 14 Sep 2023 01:21:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235668AbjINFUK (ORCPT ); Thu, 14 Sep 2023 01:20:10 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49F052681; Wed, 13 Sep 2023 22:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668768; x=1726204768; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=oAURox5d3DpugMW7F8/nDRZuIjZAXrI53V5n3V05JaY=; b=R5bbsZAMbaSVWWfaY8eQtTCgn2QRM6lA9doXlheyDlTRT8Mgtg74tAgl 3/fS47hLSvJia6NBuJOh9T+QDKYjCHbLprlvD01csojLNLZWZYrTgM8cq 4fRlRwuVbvi16AxU2daRdn5c/fkj/h/OXyAnD8dDxWk+EygOIHR5OLBEb u9yKW3SnLCIXdFH6Lcl96ikRq6jMu6g9Yx5GV6E4gRdS6Fplcjx6D37jY GsBQaKY3j0ZhINVMi9ltD8bAXU1oAuXdqm2BZV0sf8OY0hkA8YMhNe2Lt 86afIAHXNq1/s+M/JE7X9YIJx797xoDQyPP2/rQm3tXAfr7DRZmfEvCrt g==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661549" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661549" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488850" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488850" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:48 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 37/38] x86/fred: Add FRED initialization functions Date: Wed, 13 Sep 2023 21:48:04 -0700 Message-Id: <20230914044805.301390-38-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Add cpu_init_fred_exceptions() to: - Set FRED entrypoints for events happening in ring 0 and 3. - Specify the stack level for IRQs occurred ring 0. - Specify dedicated event stacks for #DB/NMI/#MCE/#DF. - Enable FRED and invalidtes IDT. - Force 32-bit system calls to use "int $0x80" only. Add fred_complete_exception_setup() to: - Initialize system_vectors as done for IDT systems. - Set unused sysvec_table entries to fred_handle_spurious_interrupt(). Signed-off-by: H. Peter Anvin (Intel) Co-developed-by: Xin Li Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v9: * Set unused sysvec table entries to fred_handle_spurious_interrupt() in fred_complete_exception_setup() (Thomas Gleixner). Changes since v5: * Add a comment for FRED stack level settings (Lai Jiangshan). * Define NMI/#DB/#MCE/#DF stack levels using macros. --- arch/x86/entry/entry_fred.c | 21 +++++++++++++ arch/x86/include/asm/fred.h | 5 ++++ arch/x86/kernel/Makefile | 1 + arch/x86/kernel/fred.c | 59 +++++++++++++++++++++++++++++++++++++ 4 files changed, 86 insertions(+) create mode 100644 arch/x86/kernel/fred.c diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c index f8774611af80..7d507f59315d 100644 --- a/arch/x86/entry/entry_fred.c +++ b/arch/x86/entry/entry_fred.c @@ -140,6 +140,27 @@ void __init fred_install_sysvec(unsigned int sysvec, i= dtentry_t handler) sysvec_table[sysvec - FIRST_SYSTEM_VECTOR] =3D handler; } =20 +static noinstr void fred_handle_spurious_interrupt(struct pt_regs *regs) +{ + spurious_interrupt(regs, regs->fred_ss.vector); +} + +void __init fred_complete_exception_setup(void) +{ + unsigned int vector; + + for (vector =3D 0; vector < FIRST_EXTERNAL_VECTOR; vector++) + set_bit(vector, system_vectors); + + for (vector =3D 0; vector < NR_SYSTEM_VECTORS; vector++) { + if (sysvec_table[vector]) + set_bit(vector + FIRST_SYSTEM_VECTOR, system_vectors); + else + sysvec_table[vector] =3D fred_handle_spurious_interrupt; + } + fred_setup_done =3D true; +} + static noinstr void fred_extint(struct pt_regs *regs) { unsigned int vector =3D regs->fred_ss.vector; diff --git a/arch/x86/include/asm/fred.h b/arch/x86/include/asm/fred.h index 2fa9f34e5c95..e86c7ba32435 100644 --- a/arch/x86/include/asm/fred.h +++ b/arch/x86/include/asm/fred.h @@ -83,8 +83,13 @@ static __always_inline void fred_entry_from_kvm(unsigned= int type, unsigned int asm_fred_entry_from_kvm(ss); } =20 +void cpu_init_fred_exceptions(void); +void fred_complete_exception_setup(void); + #else /* CONFIG_X86_FRED */ static __always_inline unsigned long fred_event_data(struct pt_regs *regs)= { return 0; } +static inline void cpu_init_fred_exceptions(void) { } +static inline void fred_complete_exception_setup(void) { } static __always_inline void fred_entry_from_kvm(unsigned int type, unsigne= d int vector) { } #endif /* CONFIG_X86_FRED */ #endif /* !__ASSEMBLY__ */ diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 3269a0e23d3a..8dfdae4111bb 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -47,6 +47,7 @@ obj-y +=3D platform-quirks.o obj-y +=3D process_$(BITS).o signal.o signal_$(BITS).o obj-y +=3D traps.o idt.o irq.o irq_$(BITS).o dumpstack_$(BITS).o obj-y +=3D time.o ioport.o dumpstack.o nmi.o +obj-$(CONFIG_X86_FRED) +=3D fred.o obj-$(CONFIG_MODIFY_LDT_SYSCALL) +=3D ldt.o obj-$(CONFIG_X86_KERNEL_IBT) +=3D ibt_selftest.o obj-y +=3D setup.o x86_init.o i8259.o irqinit.o diff --git a/arch/x86/kernel/fred.c b/arch/x86/kernel/fred.c new file mode 100644 index 000000000000..4bcd8791ad96 --- /dev/null +++ b/arch/x86/kernel/fred.c @@ -0,0 +1,59 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#include + +#include +#include +#include +#include + +/* #DB in the kernel would imply the use of a kernel debugger. */ +#define FRED_DB_STACK_LEVEL 1UL +#define FRED_NMI_STACK_LEVEL 2UL +#define FRED_MC_STACK_LEVEL 2UL +/* + * #DF is the highest level because a #DF means "something went wrong + * *while delivering an exception*." The number of cases for which that + * can happen with FRED is drastically reduced and basically amounts to + * "the stack you pointed me to is broken." Thus, always change stacks + * on #DF, which means it should be at the highest level. + */ +#define FRED_DF_STACK_LEVEL 3UL + +#define FRED_STKLVL(vector, lvl) ((lvl) << (2 * (vector))) + +void cpu_init_fred_exceptions(void) +{ + /* When FRED is enabled by default, remove this log message */ + pr_info("Initialize FRED on CPU%d\n", smp_processor_id()); + + wrmsrl(MSR_IA32_FRED_CONFIG, + /* Reserve for CALL emulation */ + FRED_CONFIG_REDZONE | + FRED_CONFIG_INT_STKLVL(0) | + FRED_CONFIG_ENTRYPOINT(asm_fred_entrypoint_user)); + + /* + * The purpose of separate stacks for NMI, #DB and #MC *in the kernel* + * (remember that user space faults are always taken on stack level 0) + * is to avoid overflowing the kernel stack. + */ + wrmsrl(MSR_IA32_FRED_STKLVLS, + FRED_STKLVL(X86_TRAP_DB, FRED_DB_STACK_LEVEL) | + FRED_STKLVL(X86_TRAP_NMI, FRED_NMI_STACK_LEVEL) | + FRED_STKLVL(X86_TRAP_MC, FRED_MC_STACK_LEVEL) | + FRED_STKLVL(X86_TRAP_DF, FRED_DF_STACK_LEVEL)); + + /* The FRED equivalents to IST stacks... */ + wrmsrl(MSR_IA32_FRED_RSP1, __this_cpu_ist_top_va(DB)); + wrmsrl(MSR_IA32_FRED_RSP2, __this_cpu_ist_top_va(NMI)); + wrmsrl(MSR_IA32_FRED_RSP3, __this_cpu_ist_top_va(DF)); + + /* Enable FRED */ + cr4_set_bits(X86_CR4_FRED); + /* Any further IDT use is a bug */ + idt_invalidate(); + + /* Use int $0x80 for 32-bit system calls in FRED mode */ + setup_clear_cpu_cap(X86_FEATURE_SYSENTER32); + setup_clear_cpu_cap(X86_FEATURE_SYSCALL32); +} --=20 2.34.1 From nobody Sun May 19 02:38:10 2024 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 11F35EDE987 for ; Thu, 14 Sep 2023 05:21:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235666AbjINFVC (ORCPT ); Thu, 14 Sep 2023 01:21:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235356AbjINFUF (ORCPT ); Thu, 14 Sep 2023 01:20:05 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B20AB2134; Wed, 13 Sep 2023 22:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668767; x=1726204767; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=24bZxrNwN6mEn31ObZA79OqggozStalI8dlLgDZYX38=; b=FcOJKbkI2JxS0MuL1xkMWMFKkzmaXpJh5Wek5BaOChLRVlSUpttnyDgi 0tLtQpYumIvj6+c7Qhgyp2LbTF882dvvjtPRwSzdnLUL+ezPgZafXcFdh u1H8ElVmng/Q1PbApNxPfuemnCb8SMyvToe162WSDC2SfEgLhcmddK9pD K/bSt0uZ8KsHINHNIkLjldk8U82VDFx603cVgpO9C4Yooc5vdDXtav3h7 gSvSplb6Gax+HPYSoY7VcjpimXBNTV/uCoBJ8vvPtUJnsS/o1iVOvH3r2 +qRz0+htpsWhTy+Dng91D2svXNSfM3QWhhBQZZJxoJCPYU7b+zA/tje9r Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661561" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661561" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488853" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488853" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:48 -0700 From: Xin Li To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 38/38] x86/fred: Invoke FRED initialization code to enable FRED Date: Wed, 13 Sep 2023 21:48:05 -0700 Message-Id: <20230914044805.301390-39-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: "H. Peter Anvin (Intel)" Let cpu_init_exception_handling() call cpu_init_fred_exceptions() to initialize FRED. However if FRED is unavailable or disabled, it falls back to set up TSS IST and initialize IDT. Signed-off-by: H. Peter Anvin (Intel) Co-developed-by: Xin Li Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v8: * Move this patch after all required changes are in place (Thomas Gleixner). --- arch/x86/kernel/cpu/common.c | 17 ++++++++++++----- arch/x86/kernel/irqinit.c | 7 ++++++- arch/x86/kernel/traps.c | 5 ++++- 3 files changed, 22 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 4cb36e241c9a..e230d3f4c556 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -61,6 +61,7 @@ #include #include #include +#include #include #include #include @@ -2128,7 +2129,10 @@ void syscall_init(void) /* The default user and kernel segments */ wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS); =20 - idt_syscall_init(); + if (cpu_feature_enabled(X86_FEATURE_FRED)) + fred_syscall_init(); + else + idt_syscall_init(); } =20 #else /* CONFIG_X86_64 */ @@ -2244,8 +2248,9 @@ void cpu_init_exception_handling(void) /* paranoid_entry() gets the CPU number from the GDT */ setup_getcpu(cpu); =20 - /* IST vectors need TSS to be set up. */ - tss_setup_ist(tss); + /* For IDT mode, IST vectors need to be set in TSS. */ + if (!cpu_feature_enabled(X86_FEATURE_FRED)) + tss_setup_ist(tss); tss_setup_io_bitmap(tss); set_tss_desc(cpu, &get_cpu_entry_area(cpu)->tss.x86_tss); =20 @@ -2254,8 +2259,10 @@ void cpu_init_exception_handling(void) /* GHCB needs to be setup to handle #VC. */ setup_ghcb(); =20 - /* Finally load the IDT */ - load_current_idt(); + if (cpu_feature_enabled(X86_FEATURE_FRED)) + cpu_init_fred_exceptions(); + else + load_current_idt(); } =20 /* diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c index c683666876f1..f79c5edc0b89 100644 --- a/arch/x86/kernel/irqinit.c +++ b/arch/x86/kernel/irqinit.c @@ -28,6 +28,7 @@ #include #include #include +#include #include =20 /* @@ -96,7 +97,11 @@ void __init native_init_IRQ(void) /* Execute any quirks before the call gates are initialised: */ x86_init.irqs.pre_vector_init(); =20 - idt_setup_apic_and_irq_gates(); + if (cpu_feature_enabled(X86_FEATURE_FRED)) + fred_complete_exception_setup(); + else + idt_setup_apic_and_irq_gates(); + lapic_assign_system_vectors(); =20 if (!acpi_ioapic && !of_ioapic && nr_legacy_irqs()) { diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index 848c85208a57..0ee78a30e14a 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -1411,7 +1411,10 @@ void __init trap_init(void) =20 /* Initialize TSS before setting up traps so ISTs work */ cpu_init_exception_handling(); + /* Setup traps as cpu_init() might #GP */ - idt_setup_traps(); + if (!cpu_feature_enabled(X86_FEATURE_FRED)) + idt_setup_traps(); + cpu_init(); } --=20 2.34.1