From nobody Wed May 15 09:45:03 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=1695463943; cv=none; d=zohomail.com; s=zohoarc; b=Ece0U63cjc9WVWLqXU/iCTPXqzOv0Cvrqwvkeu987y8aVcKoYg9TD7f7FVcQKIachVl+OR9gljBk9e3QJJyXhzCYVuxP5NrMnKEUd8/P2xnJOdXjKIxjkjTweRkgB2UNW4bHBSofO4ujUubcDU+GbGrGS7R3/YkvPYCERpGz0gI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463943; 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=L2i+gJc7EaPpwpKNnxVyvRw2+mhMHhqJSQ1MpSvR836uh9Ti6O7SOVkZ6DOFqEstszr/RoOU4cpZQt5HfJGMMndyaAXE8W2rBplcbhstxwmzu2+PJu9X0XwRifCaCCWI/MvwGsjrowP24hbSsBXg1THBiUF/2r2A44BmZkUBaRA= 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 1695463943654726.6488902982086; Sat, 23 Sep 2023 03:12:23 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607082.945246 (Exim 4.92) (envelope-from ) id 1qjzc2-0000QA-HV; Sat, 23 Sep 2023 10:11:46 +0000 Received: by outflank-mailman (output) from mailman id 607082.945246; Sat, 23 Sep 2023 10:11:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzc2-0000Q3-DA; Sat, 23 Sep 2023 10:11:46 +0000 Received: by outflank-mailman (input) for mailman id 607082; Sat, 23 Sep 2023 10:11:45 +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 1qjzc0-0000Pn-FO for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:44 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 965ca6ea-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:41 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:37 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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: 965ca6ea-59f9-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=1695463901; x=1726999901; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=5bEJT87B98JS6iQ6LlrNVmLBQuK2BkIiNY3V5ZdVNuo=; b=QQTuDaVYCPT/cJDM5ZzjV4FR99l8nu8zi9SZXCDpH1UE4cPTvQhBDFS9 6AZ+i96X58FYDD+A35cXLZdQ41mHuvYlFmSP91CqJYhKxfnJ6s/IlmdRd +ZaeKld9Hqk7viKyqNHD5FTIp86hXfwo+qfz3t8NUIaXz1q1Clq8V5lPm WRKgVB7A1uPOaQ936FdxR/ZXagCresBG0yuha7k8hLSr2FaWAcxF/xXlP Cgz77S7R5Z4a/o9TFdMQ1pgaFl3bLO/YLPpO+pBuehbLN6o1ipbmQkuym sYrDeDPMtiL5FNT/T9/WQkUHPRWyOTeTIqwVWZVhd2EEQI200x9L+s5Jg Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492082" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492082" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388100" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388100" 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, nik.borisov@suse.com Subject: [PATCH v11 01/37] x86/cpufeatures: Add the cpu feature bit for WRMSRNS Date: Sat, 23 Sep 2023 02:41:36 -0700 Message-Id: <20230923094212.26520-2-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1695463945043100009 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 Wed May 15 09:45:03 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=1695463938; cv=none; d=zohomail.com; s=zohoarc; b=maxWBt607WxsfAli2Kq8iQ4myYQlFi5l7PAx3A+Gas/1PhiWiW4kEJ7+LmR0V/BHfJ7B7VkzvkwBJ3ejkWxnc1A4eUwsplWYrOt39KPP0CUd9TQAIhQYEWFlmxjFpVkzgnz0LIyHlPjeAsx2/r39P9WsJyBv5ZMWP/etlwmspDw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463938; 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=LXbqdH8gWtoBhrb66it70sLCmNpcNVQi3CG1/rMatpY=; b=B2UwyzFoAGjI1giYW6E1DyQlzPywzxmNOBFO5+5CTpTSgVe3FFHs9oBDcIhFWsA03GkKAVepBl0k0oiVSAijvsA5FT9n9F2Nkn2v40rwrz+sQy55XGKz/90ZyJgT8yAwV+69Z9MTsddkVEPoB0DquK/9p9dO9AT667Jen3pH+qQ= 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 1695463938253295.7031015132193; Sat, 23 Sep 2023 03:12:18 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607084.945258 (Exim 4.92) (envelope-from ) id 1qjzc3-0000bp-39; Sat, 23 Sep 2023 10:11:47 +0000 Received: by outflank-mailman (output) from mailman id 607084.945258; Sat, 23 Sep 2023 10:11:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzc2-0000bc-Ue; Sat, 23 Sep 2023 10:11:46 +0000 Received: by outflank-mailman (input) for mailman id 607084; Sat, 23 Sep 2023 10:11:46 +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 1qjzc2-0000Pn-4d for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:46 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 973034ac-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:42 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:37 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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: 973034ac-59f9-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=1695463902; x=1726999902; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=MxQyQabDuj01hP6xHQ5mL2MlMceZ5LcTb8ReoP3KjJA=; b=KFGNScWaoQcbQsEA+h9DNqSZNUUaetMKn9dSXujxOMwSq9jpzJxYFsy1 HXuSOB0wIL8wTkmu0jffBYjKdOSqNGKWe/ncdQ+elM15/mv5NrdD5MfJQ jcJ84cJaabaD6TyNSICG3k+FyqVDrN4aYblKHfXbR74Yp2u6zdMc/xx8J Qf/4eZM4BwYVxS9/HmqdTfQ6S9D3yBua+Z7P+PDKUYJxBxNMG63t77q2L yM4u1yW65GDVho1N+vjTK/kevJQ0zkaHnOq5obS3zzHZE6EF8KLWcaQCK 5Tt7puzGEfIDrURRtGo8OnqTLgPCRJWQztBFH7N5DTuW7jUdzsq8YVkfT w==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492094" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492094" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388103" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388103" 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, nik.borisov@suse.com Subject: [PATCH v11 02/37] x86/opcode: Add the WRMSRNS instruction to the x86 opcode map Date: Sat, 23 Sep 2023 02:41:37 -0700 Message-Id: <20230923094212.26520-3-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1695463938749100003 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 Wed May 15 09:45:03 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=1695463943; cv=none; d=zohomail.com; s=zohoarc; b=g3qh767Jf5HBpmUrYgRcDYRI9Zh/G55mA2wZGJSQADJfyKbQX6u/LleQqeTO6Z0wS8o7Z8TcQObj9IoznIMMVQEZ9Ho0ECkcL4DAegy/wg5BGaCf6VxUudj8zRBeT55LnhRSuAiNsnJ5Q+LbPKkN5wCeQa1xKDwrDrq909Bz4pU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463943; 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=XAAdZSPJGMienJFlu9IKTR44Lt85Psggs+k4ndPEXNsRRR38VCzjGlJ1EXFVwFIkgH1QsEZ5NmKG4YsSvjPRiBxQEU/hsCdGVzd7OMREeE95dFT1UAXbkcewu5VPu8H3/IGmEXkogvbcrTrMZKhScnqOxXpKlSZJsuBY7vaw/bI= 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 1695463943835994.4935837223736; Sat, 23 Sep 2023 03:12:23 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607085.945276 (Exim 4.92) (envelope-from ) id 1qjzc4-000191-CI; Sat, 23 Sep 2023 10:11:48 +0000 Received: by outflank-mailman (output) from mailman id 607085.945276; Sat, 23 Sep 2023 10:11:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzc4-00018m-8l; Sat, 23 Sep 2023 10:11:48 +0000 Received: by outflank-mailman (input) for mailman id 607085; Sat, 23 Sep 2023 10:11:47 +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 1qjzc3-0000Pn-4s for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:47 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 98d7b2ed-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:44 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:37 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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: 98d7b2ed-59f9-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=1695463904; x=1726999904; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9qsPaAmdkqHl0KD85EKfAfnheAb+UY4gBzEbjksg7Tw=; b=fv0ZQs1QUktfRChCuvv9I9Cq0z5P02C58rdfW7HU9pZVWCM6fY6tSr6k sAs1D34MPJmCEpTgExc4BhK7WJThcoACO4TZJPIhB9EzWZmxKACYT4Sjj FHsXqTuSS6CpevI1h+YPPbAp9Gi9X/EXigiFQ5wZpdkjbMJ2599VW60Fb hyaQLbmjbzAD1LWTY+tSBHfG50aNbzS29NiKf3qDo2LkXvq2Wp6LTU4cj VEQlDOryOeLautz9q5Tyyp4vSSIAYN9hWsq04cel//8kzSdcnEafDrkSR I+AtyGlh6abJGwgQ0v5JMrV4WJaZLaFKZqwColi21wNi8g2n6IqnJfUcj A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492107" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492107" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388107" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388107" 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, nik.borisov@suse.com Subject: [PATCH v11 03/37] x86/msr: Add the WRMSRNS instruction support Date: Sat, 23 Sep 2023 02:41:38 -0700 Message-Id: <20230923094212.26520-4-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1695463944311100003 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 Wed May 15 09:45:03 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=1695463935; cv=none; d=zohomail.com; s=zohoarc; b=LJfi2Dw8SIkFjy/5xMxq4xn4r6zS6pRRKF7kq5SkHzLRE9A+1SrB2F90Fv/P7Vf7QkMYw7VAblE7pca3L4n8vF73SjA/Z4gMmm3HAT/XdZdjy1NuTJ26hNNoqdIHu9ZpFF1EO51OmpKfbHUXuwnAnc4AG3Vuy+WZsUpKrVpS6bA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463935; 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=RXN8BdOBDTxiJTHkvHAzH4cOK69PZTABVtm+q+g7aD4=; b=V3XfDyn3ZSES73RP/0Qq3MkuyXsUhC8jiSdKfcUOguFvZYxsGMWSK6Ynlb3awWChgiQ1lLyXdECcvfpDXEAoBCibVBBVh6xWuhAWcNVSLvPx4YiMYAzQ4BavmNB2Znv+e0RtJcgv5p/SHE+ETb9w5HQ1hFrCH1rPxwBOEQSLn6Y= 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 1695463935776348.50898911011586; Sat, 23 Sep 2023 03:12:15 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607086.945286 (Exim 4.92) (envelope-from ) id 1qjzc5-0001PN-Pa; Sat, 23 Sep 2023 10:11:49 +0000 Received: by outflank-mailman (output) from mailman id 607086.945286; Sat, 23 Sep 2023 10:11:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzc5-0001PC-LO; Sat, 23 Sep 2023 10:11:49 +0000 Received: by outflank-mailman (input) for mailman id 607086; Sat, 23 Sep 2023 10:11:48 +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 1qjzc4-0000Pn-4u for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:48 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 98e1b9da-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:44 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:38 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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: 98e1b9da-59f9-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=1695463904; x=1726999904; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=IuyTaHxTCpXU3koACAwE/wPTCk5NNVb2w/wLiweVXto=; b=GHYVT+h1s8TCrVaUxv5AJti6meqrrOCtLKp/q3coA26Q3sS7XS3ziLc4 /uw84P55JO3OIuL3qvlD+Sohv6ds6Z0K6Cq871FAcOlof8axMsZ/OPI7B 6r5nTDTVbn9wfEk+u8E2OV2uWpLqhmPZDYrdS8AzaU32214xWT09tYwHX RS9cxoer8/yPI5xXxe3rOiGYZJ/EsdgqD3Ho1BYJ5zYllXS3KUkcXo7lC MAhATr6TU2V8nTLUl8SYP+zjezx87+dGD+Glv02IvEqGNLCX9ISEZ3baB dHHJWHn64K1MUwQcIKFEn+I66eoW1wnN5Pa6Nw2Gzfi6ZgQGQPyF+DoPl A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492120" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492120" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388110" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388110" 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, nik.borisov@suse.com Subject: [PATCH v11 04/37] x86/entry: Remove idtentry_sysvec from entry_{32,64}.S Date: Sat, 23 Sep 2023 02:41:39 -0700 Message-Id: <20230923094212.26520-5-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1695463936873100001 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 f71664dea1a3..179e08d34eb6 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 Wed May 15 09:45:03 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=1695463944; cv=none; d=zohomail.com; s=zohoarc; b=RqBfOF3/qSP+yLnrcChUCSKDnd2oq4zvY8VoPM6p5rQShTwom99oXqcTMjnt4q3vdgLLlBQdI7iPMh/Qlfu5UFhLTrhGg/bSSXri8hyJyiESVhL+csoPINJHvbeSeAohQ7k+89Zl7lpF3q9sQnB59jMANHV1eCgzHR7B3nxusEE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463944; 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=PqP4DMdgM7kvwSmv/yxHvvf4DBcn5xf7VAz13iimlnM=; b=VGL12Z8sWUFfPBBJdot8uC50701KqzNzsiYo9VTgMf+oHcqRLDXXPgDn1MloxxyqcPJiU2FOnAo0Y9V5+7pnEWILtgIqyAZ2U+ROa9onWfM2EMZCmay/2w5EyN108mJ4te3WJbzsL5GwsC978zUGJ0sMfOVGfH/ZB12SD3o/oSI= 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 1695463944309963.5951665544264; Sat, 23 Sep 2023 03:12:24 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607087.945291 (Exim 4.92) (envelope-from ) id 1qjzc6-0001Rw-3P; Sat, 23 Sep 2023 10:11:50 +0000 Received: by outflank-mailman (output) from mailman id 607087.945291; Sat, 23 Sep 2023 10:11:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzc5-0001RC-UG; Sat, 23 Sep 2023 10:11:49 +0000 Received: by outflank-mailman (input) for mailman id 607087; Sat, 23 Sep 2023 10:11:49 +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 1qjzc5-0000Pn-5I for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:49 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9948a36c-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:45 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:38 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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: 9948a36c-59f9-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=1695463905; x=1726999905; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=peVjyb58aU5czBXdVg55hBuRdCD6fg7woOPGVcAZ2Yw=; b=fdJRXkyyG1r++z7OQn+9FM9DZ7F8+mRM9LnWWGk1Zx3IdmQwdf+lxRo+ P0eWTJFDs6bmkGG6st6+M7WdhEZ9ZX/M/ktCS0lv4mDYkoBREtSFZnFpV PeyT2gmJB7mo4Slr+Ke8FgYe0qH3X3IgW20hLWBYjzBHSI9RMaPyA5nk8 b25gcY2z4y1+9dWGXYIcqjTYYX5Ql+Y9wVbj+WHG7xI8dvCqXRAXij01x /qf+uzaZr100O4rPPNKm83HtrhCSZtDSac15xk8mPn4SkNpsET7BxlySb yqnRbAXJGZm/UtgnbTv0RFMsCo0945XbezQaohHdjC2yz+d9EZrZXYji4 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492131" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492131" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388115" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388115" 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, nik.borisov@suse.com Subject: [PATCH v11 05/37] x86/trapnr: Add event type macros to Date: Sat, 23 Sep 2023 02:41:40 -0700 Message-Id: <20230923094212.26520-6-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1695463944546100005 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 --- Changes since v10: * A few comment fixes and improvements (Andrew Cooper). --- 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..8d1154cdf787 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 FRED, Intel VT-x and AMD SVM + */ +#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 // INTO, 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..4dba17363008 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 */ +#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 Wed May 15 09:45:03 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=1695463939; cv=none; d=zohomail.com; s=zohoarc; b=SQobg0vONc0a1Eaw5DC6GqnRT7PwUkOm8eZK+NTQskabnTz3Kiueuw+UoezYnZmUPKLe18fTIaRCz95VReA+GS8YmjIbXUxB7RYm2BDBiI0ycUFWfGS6E8iSjAYmdKhd0RwfYr/XNkzAzjvptiyjcJcEnxFO29Pj/vN1GEUHTw8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463939; 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=uPnnrbXe+TDfq8zfyjGM+GH3wvyTuQbKw9KJcPGbxDY=; b=ZjfESQhE7EGndOQb7UssgtLk4KT/WP42ZwVT5wCvXIxfJ93c8SOGWQSrCNC6IlO8jKLNBxlAfZsYkFR1O/7ftgbkG3cHdrS6tOzBcx3h3b6b2wIcJOISG0aEkyX6n8+9IEchdJCASixGoS5bn8VDk716lX3NpWIQOVXKSeH8lPs= 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 1695463939965528.3979814380779; Sat, 23 Sep 2023 03:12:19 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607088.945306 (Exim 4.92) (envelope-from ) id 1qjzc7-0001vN-F9; Sat, 23 Sep 2023 10:11:51 +0000 Received: by outflank-mailman (output) from mailman id 607088.945306; Sat, 23 Sep 2023 10:11:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzc7-0001uO-90; Sat, 23 Sep 2023 10:11:51 +0000 Received: by outflank-mailman (input) for mailman id 607088; Sat, 23 Sep 2023 10:11:50 +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 1qjzc6-0000Pn-5K for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:50 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9a287b8b-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:46 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:39 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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: 9a287b8b-59f9-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=1695463906; x=1726999906; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bNeoh4I4zABONAQfik1sKjrzvYgDVMEQH0uLYFn+NlU=; b=lVqdWKyyyXoWDBsA1sYu7LxUNM73G33ABkiz6LWU3VIXwVVa3ajU4Q9J JUDhOd7rcuQwyTEZM/BPVmff9tA5I6pge0m5KdqtGAvPVDLdQB0S9DQea twcSIv+PRXFIbevA+SGMJoY3MvP72YUJwRCEDpFTjcYoVFuS6AMKHJxyf QFiFdEk13HEdbCI+6v3xv9Y7SDm132L6eHdge879ff0gipITK5J6fqIoH wrn45sthYpJg2vrL9GMI+bdibBAFyDkQVNTlaLG2/uWuI5vB8fptw1b+G mQNLxovubTm5MZjoIGTKfogOgsPr081Mp8LE2LG8h/xjd8spVqMCG8lXB A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492144" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492144" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388120" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388120" 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, nik.borisov@suse.com Subject: [PATCH v11 06/37] Documentation/x86/64: Add a documentation for FRED Date: Sat, 23 Sep 2023 02:41:41 -0700 Message-Id: <20230923094212.26520-7-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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: 1695463940345100005 Briefly introduce FRED, and its advantages compared to IDT. Signed-off-by: Xin Li --- Changes since v10: * Reword a sentence to improve readability (Nikolay Borisov). --- Documentation/arch/x86/x86_64/fred.rst | 96 +++++++++++++++++++++++++ Documentation/arch/x86/x86_64/index.rst | 1 + 2 files changed, 97 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..9f57e7b91f7e --- /dev/null +++ b/Documentation/arch/x86/x86_64/fred.rst @@ -0,0 +1,96 @@ +.. 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 and ERETU both swap 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[123]. + +Only execution of a FRED return instruction ERET[US], 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 Wed May 15 09:45:03 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=1695463943; cv=none; d=zohomail.com; s=zohoarc; b=iS0JS3fGyPLAkiz6umBiAl1fh9zNccsJY31Z+hZ8VGq9f0MNBboLuEIi2ZFo3H+0nf77fPz844gPL+FLTW75+fJvye/ZM2sP1nVSMAmCH9bjk48AGlJZlOFR4B/y6j+S1uFiRZMWROUtqmVa5l2NKPdIpKxfnC+T+zqshjgTpKM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463943; 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=n3hwZTZRILNDrrvXBP1w8gS7wmwhapSgxKaV9EfhbIg=; b=fv1cguyLsZCkh9F8WBF8BHp4dNHj3WVHR1ZON/MFXwgPpjlpDE+lQ8/PeIOg+/Kx3pWtwyMXW9pTzkG7XO+AvVKeLq3Y12djdnt5580NpTzHpN5wCm5l6q0DUUNM1M75GvStSqI6H0y98WRJjh/xY+CYpco2Lss2E4f1wxWXp7o= 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 1695463943670533.197588285362; Sat, 23 Sep 2023 03:12:23 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607089.945316 (Exim 4.92) (envelope-from ) id 1qjzc8-0002Eg-PC; Sat, 23 Sep 2023 10:11:52 +0000 Received: by outflank-mailman (output) from mailman id 607089.945316; Sat, 23 Sep 2023 10:11:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzc8-0002ED-Jn; Sat, 23 Sep 2023 10:11:52 +0000 Received: by outflank-mailman (input) for mailman id 607089; Sat, 23 Sep 2023 10:11:51 +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 1qjzc7-0000Pn-5G for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:51 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9a380aa3-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:46 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:39 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:39 -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: 9a380aa3-59f9-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=1695463906; x=1726999906; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FhC/0k2yq7T7yCxf9L591KcnQJP82j/O9GzJYrzxumw=; b=dmDsfVyDX9rVK3SfLX+OZDBK/sWHUt7ayiKzahqeKefTf3Ujnl4Yle7r OdW4Lk/xaqlp7Qr2AUrQt6Aibo4Hf7BqjDuqhK9mLLkPhnuHTLTlkP3aU KJdk7uadDnMMRn3AzXr4lz8zIUz+ljlUUrPkwtzFa523M33UazWncE8sl z1YUpG64YfqVmqPXpvT5nrgnwGxzQp0ROO+O2hxUyRcI6+P6bVvEEEmZ7 RkeG/7WlY34U4eq7inTpqTXgBdaIifQu+yhj0jwF62um90QQX1EitEoM5 /uJp1IYAJU9pkbEnmTyspG4KAExwRhfVQ+tCv+YzzaZ+ivUxOwAqlvL3S g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492156" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492156" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388125" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388125" 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, nik.borisov@suse.com Subject: [PATCH v11 07/37] x86/fred: Add Kconfig option for FRED (CONFIG_X86_FRED) Date: Sat, 23 Sep 2023 02:41:42 -0700 Message-Id: <20230923094212.26520-8-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1695463945039100008 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 3154dbc49cf5..c3dd317d476c 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 Wed May 15 09:45:03 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=1695463953; cv=none; d=zohomail.com; s=zohoarc; b=cv9mIUq11QNhHkjZCIn1tC5mjurCmHlU4tkLJEBJZsxuhaWzRUPYTTbmuQjjA8zLcH3buLJM0RpW+Itm4iMC7Cy/zqWSoHVapbRU34MDbfXqDO21LE8fUm5atXLqDQet1URyrVt31MH6bNrheLyaTCkIL3ekwO5yr6/vDSPwEow= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463953; 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=e+Is0ufHJigBMo3+m1lfsivDx+AnqOqv6EIcFs783DAqLusRTsiNxtcy5wjaDMRcC+RUUlcM71bz4lsXwnrxAw6ydHIg+Fn85S+EB6ykraTqwENS4BiLAhDMmezhEGzxO3aosSUxUthndEXAI36khV22Fxdy/DHbS/eiX/JpUDw= 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 1695463953800344.6419171654728; Sat, 23 Sep 2023 03:12:33 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607090.945326 (Exim 4.92) (envelope-from ) id 1qjzcA-0002WJ-6G; Sat, 23 Sep 2023 10:11:54 +0000 Received: by outflank-mailman (output) from mailman id 607090.945326; Sat, 23 Sep 2023 10:11:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzc9-0002W2-Vv; Sat, 23 Sep 2023 10:11:53 +0000 Received: by outflank-mailman (input) for mailman id 607090; Sat, 23 Sep 2023 10:11:52 +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 1qjzc8-0000Pn-5X for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:52 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9a94ddf5-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:47 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:40 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:39 -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: 9a94ddf5-59f9-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=1695463907; x=1726999907; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ZlGESG1ZjbxHp/2vGEpu7uzY2F9a0taEPQgxug8c1Qc=; b=mqWpm+ziSGBCxt1+XVJGIbKQqj3tDJ1a2SGdSpLugmodk6BV/jG2IYUG xDtt9PFMt9uvf/RzLxDtrFxjZntCctTxWGprivFHKaZ9sQhzLxCYa23MF pPtie+ZW2xpYX+5lfH+pjaYt1CPdsEbuTyt8m8RbWlUejErSbDxwu0eD+ ZvgF3KH0yprB/KcBNsSrORn65VnxIOv1ioiNKImHBMlxwLnceONTO2zqM mndCHtt6BwRFhtKXRxvst/6O9yuwPbyVoVEzPbsPQf3feDmFA5CFrSjRK fi3yEC8GoD6dbItYBNGXzU7i///fO+pOuh90OAjqa9ARr9XuRgcVRYuGA A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492168" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492168" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388128" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388128" 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, nik.borisov@suse.com Subject: [PATCH v11 08/37] x86/cpufeatures: Add the cpu feature bit for FRED Date: Sat, 23 Sep 2023 02:41:43 -0700 Message-Id: <20230923094212.26520-9-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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: 1695463955312100001 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 Wed May 15 09:45:03 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 6DA50CE7A88 for ; Sat, 23 Sep 2023 10:12:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231650AbjIWKMU (ORCPT ); Sat, 23 Sep 2023 06:12:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231351AbjIWKLs (ORCPT ); Sat, 23 Sep 2023 06:11:48 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A3909E; Sat, 23 Sep 2023 03:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463902; x=1726999902; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=CcGvpPsp9yPYBKGgtw+pwzSruaWdmcjQipAacX3tyYo=; b=JcOUI+47YJOJ4+PXISLurQZlPVSZgr8wF44vfml4l37PL0G1Gzdq7a+t HHF1IEeskazSm+LgeNfOylzsuskG6PurftEWQ6PG/ElUZQqqWz7vYI4yO mg2m6N0wH2X/v6aLhs4aIsE+LHK6popQjOe6xiCZBliOukQpj2p/QgfoF hcQucfGO6iLLDv3JvSSj4EZwIfVYvvv1lCHdCr/dTf2ho3Nch2gEaKaWY dJVGArS5mON3KO8knPsfCwL0XYB2cyVvYl9hc9Wy1K643yMn73BTu4xe0 3gvrkTuE0IEYyzgjQQjd+qKPAiMJPkI5D+XS0f/S5Vqyti3Bwqgiys4U7 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492179" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492179" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388131" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388131" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 09/37] x86/fred: Disable FRED support if CONFIG_X86_FRED is disabled Date: Sat, 23 Sep 2023 02:41:44 -0700 Message-Id: <20230923094212.26520-10-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 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 --- Changes since v10: * FRED feature is defined in cpuid word 12, not 13 (Nikolay Borisov). --- 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..f40b29d3abad 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 */ @@ -133,7 +139,7 @@ #define DISABLED_MASK10 0 #define DISABLED_MASK11 (DISABLE_RETPOLINE|DISABLE_RETHUNK|DISABLE_UNRET| \ DISABLE_CALL_DEPTH_TRACKING|DISABLE_USER_SHSTK) -#define DISABLED_MASK12 (DISABLE_LAM) +#define DISABLED_MASK12 (DISABLE_FRED|DISABLE_LAM) #define DISABLED_MASK13 0 #define DISABLED_MASK14 0 #define DISABLED_MASK15 0 diff --git a/tools/arch/x86/include/asm/disabled-features.h b/tools/arch/x8= 6/include/asm/disabled-features.h index fafe9be7a6f4..0b47ab1930a3 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 */ @@ -121,7 +127,7 @@ #define DISABLED_MASK10 0 #define DISABLED_MASK11 (DISABLE_RETPOLINE|DISABLE_RETHUNK|DISABLE_UNRET| \ DISABLE_CALL_DEPTH_TRACKING) -#define DISABLED_MASK12 (DISABLE_LAM) +#define DISABLED_MASK12 (DISABLE_FRED|DISABLE_LAM) #define DISABLED_MASK13 0 #define DISABLED_MASK14 0 #define DISABLED_MASK15 0 --=20 2.34.1 From nobody Wed May 15 09:45:03 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=1695463943; cv=none; d=zohomail.com; s=zohoarc; b=juUytbS7f+28vQMw0Ve6Bh1asrsHvh3EZ8rmN/41p241SyFt7ML5O7OldRfI9JfBDHS+CVP8pYT8GljGPwsrhrH7kYIL/z8KpV+Doa6Vl8s81mWeGmJQDJWsjWzAHy1v1XXRIGG7HQtVzxrWvCcoegkkMW5J6uIIqdMtpIsawmc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1695463943; 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=L6d626jI3qyIZKoZSq1vkSSDhtm126FQWSTjqVPzUA4=; b=Ev2RRTQLv1o1htDLtOwUo6OMvrCXRWNhn2SUM3q9YhFCVGmHHnvLRvEkGUvGyFXohLUXho+pekCLIqT011POT8XWipGde0xYtCeulhMN92U309Q+aVSsqEkk7UZTUwl4ID92KKP7K/CGF9aYLCILrUTnuj84/R+9R9HIYWhULY4= 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 1695463943960300.43843773523633; Sat, 23 Sep 2023 03:12:23 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.607091.945331 (Exim 4.92) (envelope-from ) id 1qjzcA-0002fT-Ng; Sat, 23 Sep 2023 10:11:54 +0000 Received: by outflank-mailman (output) from mailman id 607091.945331; Sat, 23 Sep 2023 10:11:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qjzcA-0002dk-J3; Sat, 23 Sep 2023 10:11:54 +0000 Received: by outflank-mailman (input) for mailman id 607091; Sat, 23 Sep 2023 10:11:53 +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 1qjzc9-0000Pn-5Y for xen-devel@lists.xenproject.org; Sat, 23 Sep 2023 10:11:53 +0000 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9b86a226-59f9-11ee-9b0d-b553b5be7939; Sat, 23 Sep 2023 12:11:48 +0200 (CEST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:41 -0700 Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:40 -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: 9b86a226-59f9-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=1695463908; x=1726999908; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=8L4dZHWPEow2ZsckWCTENKztBfQe3j0MHQV1pASC0Y8=; b=lL1xZ85NSL8Gwct/7lwhDiZukUN9gEsZ/DQ+VT5BtJ/sy83tGtLaXe3u spSfvNutpZleO/02PlypJSR0Ojgr/C5qvOMSjc+SU+rlOwxpCEYPs3UCh m0RufCJDT+J3JroRva7JmSIHipf+FHvyA+5gC7WJDn8xpLd8n0El08fk6 d1Ahksldiw8Psll9ctj/xjWDB1WB6gxNDauYBE5W023D/k36t68WxKxNS JtYjPM6CwuuYfrHC/5pFpRvikDjwwzDCaKqPMAMbO6NJzEn8OhPm5hG3v 0sXkwi4CuKWKdQRGJpFdwUMS1fRZYZQ2jwbFn3fqOjEa3y7aAvss0hULX A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492192" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492192" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388135" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388135" 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, nik.borisov@suse.com Subject: [PATCH v11 10/37] x86/fred: Disable FRED by default in its early stage Date: Sat, 23 Sep 2023 02:41:45 -0700 Message-Id: <20230923094212.26520-11-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @intel.com) X-ZM-MESSAGEID: 1695463944973100007 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 45e34be4ed56..ee939ea00458 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 afa755e06ae9..4dec7822a291 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1487,6 +1487,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 Wed May 15 09:45:03 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 3D9C8CE7A99 for ; Sat, 23 Sep 2023 10:12:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231627AbjIWKMP (ORCPT ); Sat, 23 Sep 2023 06:12:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231359AbjIWKLt (ORCPT ); Sat, 23 Sep 2023 06:11:49 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 652D41AC; Sat, 23 Sep 2023 03:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463903; x=1726999903; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=i5VPM7WJy8QX3AfDJPn+y86GzsjxiQoeNBcvUeRwUoQ=; b=FYjF932OR3QHVgfDGDjrHpWKp6BPvvFE4shW/ZL0c6mzKJnNx3j1bovH sH4P9qQpID6cNHh3/ScpiyBELF+i+IT+PnaOaZD/hJfFCZLYSbmNMKjeZ JdUxuBG5sJk+5KRno0fMy3uOXtAjplMdBwRUX5JRixrDDVX3DDrUZpUM1 LaQ/CCrXHPkUOfbFkNoYoh6eADORM36mm5Da8LXHAYujo446dKPE80JEu /44JftvUgLP6lGBu7ZZfa5TTF7bdOmw9fCEUSWG6EynnyixzSorOyp7eq tpAgwBsNDwIqyYcddPnz4+I0eYqeB5yCMzpCasNMXBha0P8y9vY6h47Nx g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492203" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492203" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388138" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388138" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 11/37] x86/opcode: Add ERET[US] instructions to the x86 opcode map Date: Sat, 23 Sep 2023 02:41:46 -0700 Message-Id: <20230923094212.26520-12-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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)" 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 Wed May 15 09:45:03 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 6E52BCE7A90 for ; Sat, 23 Sep 2023 10:12:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231741AbjIWKMj (ORCPT ); Sat, 23 Sep 2023 06:12:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231373AbjIWKLu (ORCPT ); Sat, 23 Sep 2023 06:11:50 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E85A919F; Sat, 23 Sep 2023 03:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463904; x=1726999904; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=nnaiSfOR32UqURagnGQyKATdoHKyxN7QZzCa/h9+/jY=; b=loCMPhojLXtMwU6w8DVPX7Uf6B41ko73La/Azqg5OEqaEYqGxJQX77nr UeoapNHu3u+leM3CxPRJmJBY+IXnFZPenIC8pJgzzmOEslyBbhGTdurX9 Rj7veLRMpUIVv0KpkcN49sbjShg6EJpvhmDLqdljFWkJ7gAWRLZspSUeJ fNIAUfudZjAh8xAYvUIxHg0EF/JXmvJlroRPl9U+qQEe2/7wtqHIAN43+ CpeDEvocAb+EhbGLh6zojpok88bhXJixEciJ3apArkPYpIW+eC6Z+dT2A NmWpPkM6aGPG3xHJ3OkH/skRj7I5dLyO34glsM6ouWcObtJZnbiCwvkBr g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492216" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492216" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388141" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388141" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 12/37] x86/objtool: Teach objtool about ERET[US] Date: Sat, 23 Sep 2023 02:41:47 -0700 Message-Id: <20230923094212.26520-13-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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)" 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 Wed May 15 09:45:03 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 3D26ACE7A89 for ; Sat, 23 Sep 2023 10:12:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231718AbjIWKMe (ORCPT ); Sat, 23 Sep 2023 06:12:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231367AbjIWKLu (ORCPT ); Sat, 23 Sep 2023 06:11:50 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC4C51A5; Sat, 23 Sep 2023 03:11:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463904; x=1726999904; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HpayuDP0G6ySf2KQMWwvFighiKo7ZJmuZuQ215k2l1g=; b=lU3kY2b1mloP/Llhpm5fhd7XanC1j8u/Mj+maRUbTQ+yfhC4Gji0a6BA 09GznR4PtexVP+NwOywvflZagIG0EtyWgzQUKeJ/LZB79H0dyV9OxapJP hBRl5q6Cq1LYngMRI4ZnKgbfwS7WT31jwvbhWjXs8u5XxaTr8Ndezomer d0WYeiHJTyJLgL64pKSEK++/IU+UeX8bHDiz3XVHYdaH0SFcJPeXAZ+MM vB5suDP+E6Ae6IU2boqB8tXIewFkymgAdODWtstsojuJoPJ/2WRdKCt/P u/3X/+/j9+6/07VypQH+qUYnG/4eDntJNsweH6tC6fj5xH+gY2A7MSWuR A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492228" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492228" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388144" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388144" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 13/37] x86/cpu: Add X86_CR4_FRED macro Date: Sat, 23 Sep 2023 02:41:48 -0700 Message-Id: <20230923094212.26520-14-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 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 4dec7822a291..20bbedbf6dcb 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -401,9 +401,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 Wed May 15 09:45:03 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 30E69CE7A89 for ; Sat, 23 Sep 2023 10:13:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231742AbjIWKNV (ORCPT ); Sat, 23 Sep 2023 06:13:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231377AbjIWKLu (ORCPT ); Sat, 23 Sep 2023 06:11:50 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 686391A7; Sat, 23 Sep 2023 03:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463904; x=1726999904; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=szPt1r95a6G9RGqQRcu9cfSwmWMFMGoo6TuZWPez9pk=; b=aiHp3F93ZLAAx68RVNAF9kDM48Xa4MHBEVCM0o7rJH0sKCBEdKCIyB1x Ip7LpJojTmQfHM9DuxeA6AeyAyukQImVfp8Nid6IXm3jmoPgaiGMbjtSH 8obi3zGXrgb7JsG7WXXxo9Cbt8Cb3hLmADuIgIjxBKsHJ+oSjaFnJuf8B 6p5IpWXil2gARsKf9soNV8ts4mXAHTjBDM67MlzR0CzL9r7JIb9NQgSGH 1tRJz0pbjlykJ3aNi1ZiTGqTBXRmMDWnpe8zmWja1nMxanmShFGTSmFDs Kmv6lGFcahhw5t/RWJ1qo8iuDhsrE0L/qzvzzmD/BNrfm0REJU1ui78gx Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492240" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492240" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388148" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388148" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 14/37] x86/cpu: Add MSR numbers for FRED configuration Date: Sat, 23 Sep 2023 02:41:49 -0700 Message-Id: <20230923094212.26520-15-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 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 6a6b0f763f67..200d7715696d 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 Wed May 15 09:45:03 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 7326DCE7A88 for ; Sat, 23 Sep 2023 10:13:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231539AbjIWKNS (ORCPT ); Sat, 23 Sep 2023 06:13:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231390AbjIWKLv (ORCPT ); Sat, 23 Sep 2023 06:11:51 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F40911A6; Sat, 23 Sep 2023 03:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463905; x=1726999905; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=yFOHuHE47yU8Pv3f7vyK1KueQKaw2/ZJmrjuiwmDzLE=; b=IWnaelHWYToj5baMKtpTQf5PGC4D4ZkLwsJuf4tIlpR4E2dRfo2PUUgK egi3BREtFGAyWH9jlzI4T43jwfpSkka/BU1osR/pcNLe6+T2OiBJFwVKb nOGvGX4tRNdnvDC333dBFaKZIYExqD9nNmzGutw8LfDt+6qpZqJv6JqVM v22xOdDh+y/rSszfoEnzEjTYX9+IBBj6d6nd8wbvu1I99k98dNOODwsaS 9G53qj4YmgGkNaAdMaBkPs/fx1PahXV7g7KiyOrf1Q7js6CvIS7KJU6/0 3z8Y9x3DzTl+NkfvSlJl2qcAc8gVDWmvZX0KKycxQp3Y774y0Gx0BCcvS Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492252" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492252" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388151" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388151" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 15/37] x86/ptrace: Cleanup the definition of the pt_regs structure Date: Sat, 23 Sep 2023 02:41:50 -0700 Message-Id: <20230923094212.26520-16-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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" 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 Wed May 15 09:45:03 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 53E12CE7A8C for ; Sat, 23 Sep 2023 10:12:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231759AbjIWKMl (ORCPT ); Sat, 23 Sep 2023 06:12:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231393AbjIWKLw (ORCPT ); Sat, 23 Sep 2023 06:11:52 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 119511A8; Sat, 23 Sep 2023 03:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463905; x=1726999905; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/vulkjS/nAxN+RJ3C7R6J4h15cqNiAED/GUC9x16vUQ=; b=QOYoVbkxcmt/7LwWVahKIIt/Sz4sD0tXHIC3jexpGOx4UiGMHFKD+QIt /qFCKQ5AOgBSWiS0ODeiKZ/lsahrW+Ktz+WW9tdduvzyDpo/HbWw59Tj5 JfxsmnYAjlW2OgLlgoQkvc0wUrKunrp1ZSlzb0O+okR+71sJ6V85v/DwW Q7TnCL25UA5OpLPKopfEMTJsgDllIX4SQZknGdTlNTwAqoUedpApNmN/d I5HXbziikfegppcUIZ8Jo/rZiHptCTbrVsj3towi1G8W6PCMeFTdApUMM C+wWRKmZqta/7b4tOeUYFarOI798RCfGbup8/y5TkYx5RTUdSlN76z5sz Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492265" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492265" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388154" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388154" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 16/37] x86/ptrace: Add FRED additional information to the pt_regs structure Date: Sat, 23 Sep 2023 02:41:51 -0700 Message-Id: <20230923094212.26520-17-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 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 Wed May 15 09:45:03 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 DFD8ACE7A89 for ; Sat, 23 Sep 2023 10:13:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231747AbjIWKNO (ORCPT ); Sat, 23 Sep 2023 06:13:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231398AbjIWKLw (ORCPT ); Sat, 23 Sep 2023 06:11:52 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D56719E; Sat, 23 Sep 2023 03:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463905; x=1726999905; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SbR2wCTkousO/IPIjdDUqT7zLHmXpw3IGG9LN/Z2MXU=; b=eJd5ydBbkRSEEfxYp+oXjchgGCVniK65y84AMrB2vikSANZOheEuNk/Z vzTXsfRQiqeUwP8HWPaJLSfXP+mzioMWHUS52QNMmpyYFiJubkLBhBe0n Ncrx35Oq5TL4ByhqwrmhBiqjBAS8k2+CqQSuVRlbqiQo7IY8E2UaZrp3x T4rg1MytM/mK0pQR1SaTZ6sGVTlKb0V0pSd6HOqBRmgLzYUbkCOxq0eZI taq2TfzsGAuIxPqH95ebEv8eJrykq2mqwFG4FUcGVXyzFNxd/GBK7IPlh 8ZrOYodVZwJbhM+1wDQ7T0HAohLLGp9q8gZYx9y210hmUzh6OBlb8NoGo g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492277" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492277" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388157" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388157" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 17/37] x86/fred: Add a new header file for FRED definitions Date: Sat, 23 Sep 2023 02:41:52 -0700 Message-Id: <20230923094212.26520-18-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 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 Wed May 15 09:45:03 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 795CBCE7A88 for ; Sat, 23 Sep 2023 10:12:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231592AbjIWKMz (ORCPT ); Sat, 23 Sep 2023 06:12:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231445AbjIWKL5 (ORCPT ); Sat, 23 Sep 2023 06:11:57 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A83CA1AB; Sat, 23 Sep 2023 03:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463906; x=1726999906; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=f4gesqgoemAM7gLIVW0tfHuShJv23oH28+TguMOULZ8=; b=QxWUBZs0xpA7p45SMCJP3pzboZwv1TWVn8628483/zG1HN6J3uhYFht0 8wbEKjofUV5ftUEKibda7nWg3+Zz3/6MhwKuLmcTkGWpumromTH58FCkM vn0z6XIWq4sjp0uhOhy5iySOKDOuojLMrlJRxrG2OR8vaDGGRaNSfLmoH 047a2i9MLbggY/U922moqfRaC2R0N/FdYTWCQbNG2HaA3WDJVd8eS8htp 8X0ZBQfgiuAVJ3D/c/KuIsrFMn1X971OQ+g5mSqXkOr3zmlFR3+nBr6O3 38RSSIasELGBMsA0JXZUQiZnUUVdeX63YB2q98yDP0Li8d/CNOg0tV6aA Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492290" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492290" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388160" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388160" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 18/37] x86/fred: Reserve space for the FRED stack frame Date: Sat, 23 Sep 2023 02:41:53 -0700 Message-Id: <20230923094212.26520-19-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 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 Wed May 15 09:45:03 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 2CB5CCE7A89 for ; Sat, 23 Sep 2023 10:12:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231792AbjIWKM7 (ORCPT ); Sat, 23 Sep 2023 06:12:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231444AbjIWKL4 (ORCPT ); Sat, 23 Sep 2023 06:11:56 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A9ED91B2; Sat, 23 Sep 2023 03:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463906; x=1726999906; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=U5v5FfPZcbv+kEeu4BDXYc9n8fkslqM+14uJJDiLwkk=; b=ixQUNrJAyVY8HNPqmZmobN0KOm8z0sYCjmnxRgrHa21aF7gDb2l0JjAJ SduROhw4WqIZFzrJIDZikzmbl2ys2xAw1kINfl5W9KbYeaI1R2HdAkmiJ LfRlTvm8JCW7SUoZGZ1/uC6Ga0URrF/GBtxZPvJwJLwMCFuhK04I0QCz9 rK10C81fTG8soG4v2mXvLBzavgFbIlTNWqXfSE3Av6RF7QxSHNFK1f9aK FUGw2TIvFu1AY7OLsr/H2sye/yG32Ib0HAMQ4RCnkTQZuUfds8uhl1JSR coumZW0UTi/E9IgZwJ0gRcq6gwS8nB9WTXXQIN6INyHqDviyXCzl9yFGb w==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492302" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492302" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388168" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388168" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 19/37] x86/fred: Update MSR_IA32_FRED_RSP0 during task switch Date: Sat, 23 Sep 2023 02:41:54 -0700 Message-Id: <20230923094212.26520-20-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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)" 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 Wed May 15 09:45:03 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 CC0BCCE7A88 for ; Sat, 23 Sep 2023 10:12:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231655AbjIWKMt (ORCPT ); Sat, 23 Sep 2023 06:12:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231461AbjIWKL5 (ORCPT ); Sat, 23 Sep 2023 06:11:57 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 215471B3; Sat, 23 Sep 2023 03:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463907; x=1726999907; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HaNFd9+f6o42v45n40NutGcoZldX+CMRVlEU3cDygtg=; b=jEL8tLXPUHJRQLVSuI6qyrNJxohs3fISpFjBgeeeXU+sYKhsCTXwz5Bb TYEglSxovRDRIzRh7MWvQzb0/rhgmS7r3ksmhPbad3DgPJLcmPLLW5LoH o4ypyAwSNx9KcUtfQQC9oHo6O3VAWszAQYSHisQvB9hzRAWqaozAOv9wh WY/a53Z6o6UPB12m8SDlnpy3+KscD0sT8dHWKNUTiX21r7+tQzjcauKGb pIrRRQot4oKGDblcaduq4fB1WzBGzt09FJMDjOHBjqYD2T3DKQdH+Dkad SBHRwNfqEVtBrSRGIRDCE2ZmZw2o6FuNBKljLWugRVMZ//MYnjwdrHH82 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492314" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492314" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388171" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388171" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 20/37] x86/fred: Disallow the swapgs instruction when FRED is enabled Date: Sat, 23 Sep 2023 02:41:55 -0700 Message-Id: <20230923094212.26520-21-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 740CCCE7A88 for ; Sat, 23 Sep 2023 10:12:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231782AbjIWKMq (ORCPT ); Sat, 23 Sep 2023 06:12:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231474AbjIWKL5 (ORCPT ); Sat, 23 Sep 2023 06:11:57 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C7771BD; Sat, 23 Sep 2023 03:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463908; x=1726999908; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=daicXFK30tmpTUp95RTD2ZQAe5K9xY8zuW1WSEbSaqA=; b=RF50qkSpXHkHvKH70GYJdehu6SU3Tclu7ny+agEjlzZReORO8M5gsxbV 8jDchmx4WmEn33UhCqsX4CjoBXYgdfBdjAmS+HMFbfDBCFPV7eWDoMkGv q/7eEWUDKWJdYTRbV8hzQ2Iz+5sDgKxf+Wv6rMjHbYhdZUa5fWmNndX4Q eXYORjBSws+aAHGQOyrCwmPQ+0yRqv4Rifm2RXtDgJT+SBBlUF4BrgT9f 68LAUNQbSN9Kiu5LqsIlG8OLU6bawp61JmyjAoGzoX/VMBSsWIzUgyZSf WVba+/zSdaJoJcfXH3TAgiA8+siEh/zsn4Rc1T2qwfGaMtmo+rsOhFdBP g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492326" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492326" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388176" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388176" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 21/37] x86/fred: No ESPFIX needed when FRED is enabled Date: Sat, 23 Sep 2023 02:41:56 -0700 Message-Id: <20230923094212.26520-22-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 60803CE7A88 for ; Sat, 23 Sep 2023 10:12:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231772AbjIWKMm (ORCPT ); Sat, 23 Sep 2023 06:12:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231476AbjIWKL6 (ORCPT ); Sat, 23 Sep 2023 06:11:58 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 462471BE; Sat, 23 Sep 2023 03:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463908; x=1726999908; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=m7R91mzhAyMwuxf88uvtu3V1UGcA6vznqDxNdL57F/c=; b=lI3qFdBJ0gCc7+51MCb+eAv5IiowMkXv3og/CBaw/6tkoV8wy2mGUviT PYOP9T7oueM4cPUQLlt/QUHvEBwadIDOxJ8sKmjcY0HnkU2EU3vyuA6rl kKkMWLw5k3mMXqyYJq9GT52TEj3IymjS543L+ircqKG/qQapW9JzjdA8Z Yj9Jq1JQqMCxLgw03R4vRj3l8vRqg0PFJ4rRIXFhEmqTYaW55wJIdTrWb 8SrLaU3WgyCuGNha1CNMUezExH/liIDAF8w5MYAwa2JRW+WE/OEyWblPu raCnzzZ4u2tTJ63/SbUrVNsluNIlYy/evAHRKm6mzCpHbZQs+H5teYeRs Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492338" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492338" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388180" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388180" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 22/37] x86/fred: Allow single-step trap and NMI when starting a new task Date: Sat, 23 Sep 2023 02:41:57 -0700 Message-Id: <20230923094212.26520-23-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 93148CE7A8B for ; Sat, 23 Sep 2023 10:13:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231596AbjIWKNL (ORCPT ); Sat, 23 Sep 2023 06:13:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231486AbjIWKMA (ORCPT ); Sat, 23 Sep 2023 06:12:00 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9223A1BF; Sat, 23 Sep 2023 03:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463908; x=1726999908; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=vZ6vels66+tC8YRpSCj8dEsAAUPLXovJkO1WpIp9s0Y=; b=FxShut8OSTP2gqFGPujEDcYiQhcPUSHeoZoj+QHqy1pUb9B1DRuY5yaY IbC9z21iDeetxKbaOD0/4hrxehwDIOUxIYhVqo9nGgLUzfVq1oNzMF3Kf UD/m1XitLicMxP/OzIBlbTWIl2DnldTFBYOxEdgOAsXvF3XV6Zto1p4DC XNVmrFMV6TOZzVVGgBpq4pShVmioZNl0EJGixgo10rvjjMvcjgHH+Lcnt NprkMZ9RJuLP8IdGRElYXfQ+79lWhdUNA0WRH4Xib148QhRFG1apQuCSp ZUSZhx0QKalDZxp6QAov56uDTuCE6R0JU+TYk3fPhT1ZBG00o5FGU4/FS A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492350" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492350" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388183" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388183" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 23/37] x86/fred: Make exc_page_fault() work for FRED Date: Sat, 23 Sep 2023 02:41:58 -0700 Message-Id: <20230923094212.26520-24-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 A00C1CE7A88 for ; Sat, 23 Sep 2023 10:12:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231805AbjIWKNC (ORCPT ); Sat, 23 Sep 2023 06:13:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231497AbjIWKMA (ORCPT ); Sat, 23 Sep 2023 06:12:00 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C088CC7; Sat, 23 Sep 2023 03:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463909; x=1726999909; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=aB9X6AvBbEVqHF8pDqD66jUIoaqA7x/kswu7ifFPwEo=; b=EQlheWZQyM+xpEc5LFCK3iJgqh0a1Ze+1mZLQP5I4taeSAhoioEPueCd SZldmEgMktZEv7DyX7L4WPl328qXiit5gJ7LrWDBlRd/kOULG2SYM1rTh pb+o53btUjxPYK4IzJAVn65ISmEtqinNkLFJUfb8KWIU1BuwwTcLmYlNr Q9J0Rit1JS/Qnns53xB/gBwhBLQ3mqZTa6z6RyuroNtHRTzzkLWgCwoQ0 VMYW/wYa2aBfgN7Sow24afJAUJxih4C4yjAJPvu2BCFwbNqPCzDcbsbee 12WkpZXimQC4Fx9bMxi8uRw/3IddbIp9VuKL906ry4xPqStjnGtitp/Da w==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492362" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492362" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388187" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388187" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 24/37] x86/idtentry: Incorporate definitions/declarations of the FRED entries Date: Sat, 23 Sep 2023 02:41:59 -0700 Message-Id: <20230923094212.26520-25-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 B190CCE7A89 for ; Sat, 23 Sep 2023 10:13:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231583AbjIWKNJ (ORCPT ); Sat, 23 Sep 2023 06:13:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231465AbjIWKMA (ORCPT ); Sat, 23 Sep 2023 06:12:00 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 87DF0CC8; Sat, 23 Sep 2023 03:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463909; x=1726999909; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=WI4PNmnQNqWbUIJ+xrhdRHV/OU0QAbzmppTdHG3/yfg=; b=iBreqhQRLSszEndwgC6U04lI/UB3Vi1BrHVsa+ANCc2XSsQBNOgDPX+s PICiMjhU38vcOHwDs6z5Mb2Tp8JnzoDMN2kh06u6rPXFVE7SEYUobmmF7 DvZ3i6ndgVw5HWiWxKNIxEl/U4jlJ4d9+5epvZbXHyMudR4synseOd/mK l5Dx8cb/MP6xlunP27yfMLrl4TsL9Du4wB5efKPDA9jcofym/vW/K+E+I /B6e3O3KE8p2cmNCS+53H+YigaJY/rYaHPpu5Rj+4pX4Dk7e6tblWgcOS nQSFEf4h8ifBMBYqN9C7c4aMZZKKv6Lb6kq7PMZFvMMJeS088XFbJxZvM A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492374" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492374" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388190" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388190" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 25/37] x86/fred: Add a debug fault entry stub for FRED Date: Sat, 23 Sep 2023 02:42:00 -0700 Message-Id: <20230923094212.26520-26-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 B4129CE7A89 for ; Sat, 23 Sep 2023 10:13:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231818AbjIWKNF (ORCPT ); Sat, 23 Sep 2023 06:13:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231536AbjIWKMD (ORCPT ); Sat, 23 Sep 2023 06:12:03 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BFE92CD6; Sat, 23 Sep 2023 03:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463911; x=1726999911; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=FcZc1QeKj2isPTwOBVaGNTy+si5WeOaciLFU4yv7EQo=; b=nVW83MJceR44mXs4eU6YGOLUkZ4JPL7uyLiea2l0d9UJsvpyQ3fL12lm Z4+1v8fiRJ4URJmYq05kz6wnYovA8uA3xCfcsFJ7E+xI+OE65ZsMVHQJn Nf6YyyIXepqGa4HhEUAt9BRBh0q+/NHXAfyfLDI/W2YWEwKbgHVxAKVFR kJaVLSxzfIsRM3rDEEPtiixRq3x1YPknL0F0kZ4joOqTF0/OT44T6m3rW 9XFDBm8/sEYd7iveabrh2raLXS+AM3wMPLbq5lkZIFz0lIZx/Q47S4zIP oQcU1oSdZDqgzYeY+5nnqk67YJtqIVJaInr14h5YYBknU6fLPtB5oV9yW A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492387" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492387" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388193" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388193" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11: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, nik.borisov@suse.com Subject: [PATCH v11 26/37] x86/fred: Add a NMI entry stub for FRED Date: Sat, 23 Sep 2023 02:42:01 -0700 Message-Id: <20230923094212.26520-27-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 D5B8ECE7A88 for ; Sat, 23 Sep 2023 10:13:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231336AbjIWKNZ (ORCPT ); Sat, 23 Sep 2023 06:13:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231555AbjIWKMD (ORCPT ); Sat, 23 Sep 2023 06:12:03 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 455E5CDF; Sat, 23 Sep 2023 03:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463912; x=1726999912; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=bNtEfhEic2/4eI6U3F6LZD3GtdQN7TZ08d/4AOd+L9I=; b=LZ2QO50YfqdDo8MkxH7jn0cK9EzSuhuOH0Liq8Ra7laGgJV7BFrLvuWl 5ck1IsGyzIYRExmfyAhQ+Np1MkhaCqbwV5hCpRg/4RmtJcKhzewsFR+BQ HvsQMGqpdeutNBdeoLotc22LW+zOBTxNbIdzWRYKUK+sAthn8iil/M8wo oRa4ZMrcRqwnx1/3B5UqTIm73vkbGSDY/FkC7V2rfXftOAf4ukNvTZTDT L+aUA9o3YbVNQ8XlAS/HTEgWI9y1H+H/errtdLfVo5TYuAj1ncCgOxifO SfJ23tBhmkeVnFxQbrAqWqAaQfrtTGCTS7DfVmlIymV9JpAtEHLl3iZFI w==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492399" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492399" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388196" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388196" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:49 -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, nik.borisov@suse.com Subject: [PATCH v11 27/37] x86/fred: Add a machine check entry stub for FRED Date: Sat, 23 Sep 2023 02:42:02 -0700 Message-Id: <20230923094212.26520-28-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 73D33CE7A88 for ; Sat, 23 Sep 2023 10:13:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231671AbjIWKN2 (ORCPT ); Sat, 23 Sep 2023 06:13:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58998 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231459AbjIWKMG (ORCPT ); Sat, 23 Sep 2023 06:12:06 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6261ECE2; Sat, 23 Sep 2023 03:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463912; x=1726999912; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=uI63qS685+NUKBSTh3pyJcOWduGAZyH2DYXDq4Svog4=; b=YExhr+rSE/fMNLMdTxsRDmVS1vShbVgXX9fF/UGEE7KeE9HOMcvAujna m7Ye4Kyn+8S5Ph5z6Q94Q5PTjQLU9/GZG4GAIXZx/WQGv1a4SaMGCdCBl su3Wzb5xkrTTpa/OEROdYoXdUis5ojspE2eSCPCp5tclNVkxnXxPCiyG/ UpjEmF0xiKukgrGbvEm1IIBtRkFHPX9IH5Gvw5G5DAC27o6cP2StrcpKv ct7YaJFgyiktzM0W5vAXFZBse4ldp+MmSAtkikb93+u3Ct09iUx6CQ/z4 sMbpVAr4pfwRgmWc1kIztzjtvfVT2So1rKLiXIJOc5F4W4gvpEa1FFp2O g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492411" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492411" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388200" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388200" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:49 -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, nik.borisov@suse.com Subject: [PATCH v11 28/37] x86/fred: FRED entry/exit and dispatch code Date: Sat, 23 Sep 2023 02:42:03 -0700 Message-Id: <20230923094212.26520-29-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 v10: * Replace "IS_ENABLED(CONFIG_IA32_EMULATION)" with the new ia32_enabled() API (Nikolay Borisov). 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..68bec3888a36 --- /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 (ia32_enabled()) { + /* 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 (ia32_enabled() && + likely(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 Wed May 15 09:45:03 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 72B0ECE7A88 for ; Sat, 23 Sep 2023 10:13:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231737AbjIWKNd (ORCPT ); Sat, 23 Sep 2023 06:13:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231496AbjIWKMG (ORCPT ); Sat, 23 Sep 2023 06:12:06 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3DDC8CED; Sat, 23 Sep 2023 03:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463913; x=1726999913; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=PKEOP4k0ZbBHtG5Hiii+7GvY74WaZh+swnEHI3cDOxs=; b=bN6b3769NmljRs7G8K49eFjaQlKC9cSDbik4q16aGE/EQFcarnRVXD+L mjYyF+3N0MrcS60LwTHJJnNwffH6TOvPcgZ/Gxu4EIqvaIEFA0ezCAEoh nJaocAE/qtwlr7e2SBwGF/9I9wFw6gEYU9w88NAUMQItV2sF9iJXL6640 XljkhBA5qFwksV1lH6mmqatRU+lp2u8sz9lamzPOX92dAEH1ZovPSi/eN FLY1bt5KZQP688VOt0MdISD4ho/QxEY6deKVme8z9X4SXMNQqEgb27tCS xX8LApdVg0J+HSsyy+8OwHz3dQA6w0UfpmJWrI8BJKE4MOMrt9S6FQV0C Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492423" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492423" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388203" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388203" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:50 -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, nik.borisov@suse.com Subject: [PATCH v11 29/37] x86/traps: Add sysvec_install() to install a system interrupt handler Date: Sat, 23 Sep 2023 02:42:04 -0700 Message-Id: <20230923094212.26520-30-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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" 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 68bec3888a36..97e2552d6951 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 8857abc706e4..2b734927eec1 100644 --- a/arch/x86/kernel/idt.c +++ b/arch/x86/kernel/idt.c @@ -337,7 +337,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; @@ -346,5 +346,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 Wed May 15 09:45:03 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 25BEACE7A88 for ; Sat, 23 Sep 2023 10:13:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231827AbjIWKNh (ORCPT ); Sat, 23 Sep 2023 06:13:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231657AbjIWKMV (ORCPT ); Sat, 23 Sep 2023 06:12:21 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E372E42; Sat, 23 Sep 2023 03:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463915; x=1726999915; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=1q9TX+E9M+XAvCy1QsZHulLmmodNJZdOtsrh5PyAo94=; b=BSoRMQU3UDlxsImqiXJoM4K5k+zFH3SpWys/576wd49w8l61JyMxqsbG C0YmByCxgI4hvFIwfb68sDcByyWtz0kXM8eMLXra3nViNrHXlU9wQgwkl UIfN5uG7JGOSofS7lkKIOsl3znipGNUNasDGloS4qKX+hI83E2ftMvH94 8v0Vatc79B09u0Mk0SGzdCXkaItWrLF6G/M9cr22WLeX/eEsEUNTX+SaZ 9Rl8rTRKX4LQkmhNRlYOXRX38QfGwPj8xFy6JsbUCQu408lszOHhRKSd1 060IKVzwcBG7y21YgZ5ETiTKPcexlYHwKfADrDEhs8tmPTjRcMyEcwwXH w==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492435" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492435" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388206" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388206" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:50 -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, nik.borisov@suse.com Subject: [PATCH v11 30/37] x86/fred: Let ret_from_fork_asm() jmp to asm_fred_exit_user when FRED is enabled Date: Sat, 23 Sep 2023 02:42:05 -0700 Message-Id: <20230923094212.26520-31-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 179e08d34eb6..f7db3a12ccb1 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 Wed May 15 09:45:03 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 506C9CE7A89 for ; Sat, 23 Sep 2023 10:15:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231387AbjIWKPT (ORCPT ); Sat, 23 Sep 2023 06:15:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231674AbjIWKPC (ORCPT ); Sat, 23 Sep 2023 06:15:02 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDE05E5C; Sat, 23 Sep 2023 03:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463917; x=1726999917; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=I/WDYuAd3nxCrdi9nQ03uROwALnkbrNhAERS8D1SLLE=; b=Tx3TkyCCjCVXjf0rj3Nz5YDTdSS+WvV9vLsawe+1ZSMGtqvqmb8jCFjZ Fa87W//jst/MhetknBuAWx7Q3GcCWek+PU1hXzpKU6UouWUr6uDDqYLTC oZeASKT7ieA/xBgriDLLVm4GeFL9oNFlXOAMmfMmLgWI8uYcbNsMRc7le RCyVyFt+nCwuLN0G1Rz4D0FKPReKfNS/DeOV3DYM9j3+Dug2GVgGHV6DN O68TiXGlvq1bvT6H6E0KxRT+xe6YX/yC2dEaM6aN4oASflIW9Ju1YTukK HhWNmia4XMfG7R/aU1ahyf+I80fGHkFlOwlk5QZhkDyOIJ6sMPEfSOIvJ w==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492448" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492448" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388209" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388209" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:51 -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, nik.borisov@suse.com Subject: [PATCH v11 31/37] x86/fred: Fixup fault on ERETU by jumping to fred_entrypoint_user Date: Sat, 23 Sep 2023 02:42:06 -0700 Message-Id: <20230923094212.26520-32-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 05FD1CE7A88 for ; Sat, 23 Sep 2023 10:15:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231788AbjIWKPN (ORCPT ); Sat, 23 Sep 2023 06:15:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231533AbjIWKO7 (ORCPT ); Sat, 23 Sep 2023 06:14:59 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE194E5D; Sat, 23 Sep 2023 03:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463917; x=1726999917; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/UldAmuJEnsflYS2+cyLAQ4E+J1yAKX8pToUnF0eneI=; b=cSgCws86QNPsjOO5vVLxydRsfm5uymPrqcLO/cLPHAOLmoAx1dwP2l9Y cRK1fqM3UKAxPhRwY7EfH7LC858sWA7bfExQRUyDK/OCDFeWZcg0j/G5F zDjspyIy0nyBnLjn+l2xynn+FEFmrxiCE+GutdSnUObZ4686/pgJB7Tei 5+vw520MNuKuDRykFe3HZVb6+pVNwTXJ3czCMn5TOhj+nh/Bog6zrzwja YUhhLJOaiSljHU1N9iaS1atRAa0itFA6yfKCeu4PNCLPqwtSuyuOVMp4h lvZLaTdnpI9a0Ua5QXlrqcyocZTfygd+0rFtpiygg1jgkcviRh1dRXcr7 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492461" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492461" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388214" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388214" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:51 -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, nik.borisov@suse.com Subject: [PATCH v11 32/37] x86/entry/calling: Allow PUSH_AND_CLEAR_REGS being used beyond actual entry code Date: Sat, 23 Sep 2023 02:42:07 -0700 Message-Id: <20230923094212.26520-33-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 BE9DFCE7A8B for ; Sat, 23 Sep 2023 10:15:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231621AbjIWKPY (ORCPT ); Sat, 23 Sep 2023 06:15:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231721AbjIWKPG (ORCPT ); Sat, 23 Sep 2023 06:15:06 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13B34E72; Sat, 23 Sep 2023 03:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463919; x=1726999919; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=VloAwH9oCchhYDbjf1WOu4unTMxJzsUhKvR9qovigv0=; b=DDr4Dn5EqMyEjPKKPHGR9jDilr8ZHsqMCPmaoQVv3YhHRf5rkJVrdXTM 4uuys24hV7Gq/G7FcC+Qpl6ND+45jaCGz/2zwYdaI7QpdP7bJR7ntDy6y NaV/bGqA4BEDdzLbry7n6PCXJMdmRw54NXTo2BkqdIno6Sn/ABTZN3zru uQgBOoHueXUpGM7bgkUF0EtZsWqt0aGd5cLCOTZ/+wUOfUJYcy2TPNpvC pZhAk2aIMYq+KrI1jSzbhsjK9Svgucfkolv6W9yPQT3usESw6kSs3fj4i PZjCQAIcoK/lJZWZqYNGqDN+4cf6dOzqjrtc4i8VDcgjTAdWnh3FMaap6 w==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492473" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492473" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388218" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388218" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:52 -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, nik.borisov@suse.com Subject: [PATCH v11 33/37] x86/entry: Add fred_entry_from_kvm() for VMX to handle IRQ/NMI Date: Sat, 23 Sep 2023 02:42:08 -0700 Message-Id: <20230923094212.26520-34-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 v10: * Better explain the reason why no need to check current stack level (Paolo Bonzini). 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 | 76 ++++++++++++++++++++++++++++++++++ arch/x86/entry/entry_fred.c | 14 +++++++ arch/x86/include/asm/fred.h | 18 ++++++++ 3 files changed, 108 insertions(+) diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S index d1c2fc4af8ae..9917b4ea1543 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,77 @@ 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 + + /* + * Both IRQ and NMI from VMX can be handled on current task stack + * because there is no need to protect from reentrancy and the call + * stack leading to this helper is effectively constant and shallow + * (relatively speaking). Do the same when FRED is active, i.e., no + * need to check current stack level for a stack switch. + * + * 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 97e2552d6951..4c0398010e04 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 Wed May 15 09:45:03 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 3C5FACE7A88 for ; Sat, 23 Sep 2023 10:15:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231487AbjIWKPt (ORCPT ); Sat, 23 Sep 2023 06:15:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231713AbjIWKPZ (ORCPT ); Sat, 23 Sep 2023 06:15:25 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4114910C1; Sat, 23 Sep 2023 03:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463920; x=1726999920; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=MZgokrEaX/IcaX3hD6O7bYEAIXqVjdzkrr/jdEXzfh8=; b=cqZIw/GH/2210S2Zzg56rpU4JD+tvIVoft0VnGbzfvZj6nYlJbBnZsjb EdECRi2YzccxaRkXbG5w0xYrZkWyHPDScax6AfFTk+YOkw0Le/jhcBVSR dJnO2GVJ3jw5rcppjdwMfISE5+bUtm7dGC2n5Ji24YGiWoKIK1WDYKev9 mf7bPlSf1K0Gld7ZhUrXL3uYkJHK5ZejgdWBDMVtTVcjI7rwaXNrw/5nU 4a3K5oXI02LtAeYDegd74LHSwi6emEl+io1g23YJePz59ebxmI3MXn/Ei S7Vi69C+VHo8fT0m5azS/EeN9Fv1CseT/OM1mdGlquCsG4RpWCPP+YKDc A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492485" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492485" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388225" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388225" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:52 -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, nik.borisov@suse.com Subject: [PATCH v11 34/37] KVM: VMX: Call fred_entry_from_kvm() for IRQ/NMI handling Date: Sat, 23 Sep 2023 02:42:09 -0700 Message-Id: <20230923094212.26520-35-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 Wed May 15 09:45:03 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 9548BCE7A8B for ; Sat, 23 Sep 2023 10:15:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231698AbjIWKP3 (ORCPT ); Sat, 23 Sep 2023 06:15:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231752AbjIWKPJ (ORCPT ); Sat, 23 Sep 2023 06:15:09 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63B4E10C3; Sat, 23 Sep 2023 03:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463920; x=1726999920; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=kgfFMDbJiu5q1BDcTkBjlFfGWj3DWiVrEUdh+fgWCfs=; b=H0O7zSg5PdybzX4KB8gp+ZBCg9RyACeRGF/B1Z6MCM+97CyvlLpShiun vFu3n6WliTaurPp4cj7GOn+vX40BbB8O8d9JLEjAT+K+zef81AszW+LM9 yMC7HL31mFFn7RvHZezYtiIZjNTQ497hmbOCjMgL3HW5bhwara4i7MUyZ 8qEmGAMqAUr2YHrqH/hzJt6R5wDKZqKQiN2sQ0HX8nio3nAM7tMSGRutN InPTDs1KOktSNSLDvnrbFVUE9K3Ole40Abk3rOcs9xPamNokZXa7kQwn5 NLqesP3aJruu2QA5Om5uOuyO/o993DRBPRcALi5g5+yzkdR8M2M3uhCJV w==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492497" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492497" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388236" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388236" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:53 -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, nik.borisov@suse.com Subject: [PATCH v11 35/37] x86/syscall: Split IDT syscall setup code into idt_syscall_init() Date: Sat, 23 Sep 2023 02:42:10 -0700 Message-Id: <20230923094212.26520-36-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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" Because FRED uses the ring 3 FRED entrypoint for SYSCALL and SYSENTER and ERETU is the only legit instruction to return to ring 3, there is NO need to setup SYSCALL and SYSENTER MSRs for FRED, except the IA32_STAR MSR. Split IDT syscall setup code into idt_syscall_init() to make it easy to skip syscall setup code when FRED is enabled. 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 20bbedbf6dcb..2ee4e7b597a3 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2071,10 +2071,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 if (ia32_enabled()) { @@ -2108,6 +2106,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 Wed May 15 09:45:03 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 87754CE7A8B for ; Sat, 23 Sep 2023 10:15:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231430AbjIWKPn (ORCPT ); Sat, 23 Sep 2023 06:15:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231276AbjIWKPY (ORCPT ); Sat, 23 Sep 2023 06:15:24 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD5E4CDA; Sat, 23 Sep 2023 03:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463922; x=1726999922; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Sp0+AV8Wk0Fbo8OC2qcHvn3gACkXfZEMeDhitLz3FOw=; b=DIGC24SSzEW2sW+ejx4Q39no2XvditXym88PPscxE6uLGsHaZkOcnOS5 RAyXVKX9p9rL4W+hr5A5GHxA8q/Tn2H+vjKAWJoMxSP995pRhO3xg/FOI +icD5dNckGjU3tA+QfjueBc7ZMKdjirHl8/fk416xMDR86d+cNB4FhGXW /DyGnzEqfl1zTdxDS7yqi92v827hwT3yohQDmOdelX2Le+H2Ap89qcU7R ZL6Ig3/+ayMkradUFJDiGJsmsDI8H8zzXPbNhud+R5WHkPXfgxLa9KEdt /nmnvrPo6ynZQ7BW4PPxxJdAFFQlZLmmZTJ/pIZPfvPGGdr8LSKDxmm0y g==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492509" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492509" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388245" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388245" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:53 -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, nik.borisov@suse.com Subject: [PATCH v11 36/37] x86/fred: Add FRED initialization functions Date: Sat, 23 Sep 2023 02:42:11 -0700 Message-Id: <20230923094212.26520-37-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 4c0398010e04..e77429683240 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 Wed May 15 09:45:03 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 5F3C3CE7A88 for ; Sat, 23 Sep 2023 10:14:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231415AbjIWKOe (ORCPT ); Sat, 23 Sep 2023 06:14:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231158AbjIWKOQ (ORCPT ); Sat, 23 Sep 2023 06:14:16 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC2451733; Sat, 23 Sep 2023 03:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695463929; x=1726999929; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=dp4g3U5j1+mHLqLShoixZI9RDsoukyKAu6bCdytj8jk=; b=bLQY4bdOT3wjV8b2BfFCfeFJAJYzr06hcUl+W+MNXreUSv7xKotPnT3V oGFvx0CUpZk5ZnwPwKmhYImXjRQ8oSrMyUEp8bYo8Z2KZf3R99aS4uNeI I6zuyIPKZNH9H1rlZTbAwFuAm2PinZfoxtDtGPgjgs5EgEfV6MtOK8jXm K1DYJO/AuuCSNQSvb8BX3RqwhqyKMJBnLnhaivhr6Oe11IpUnI2RcdUma YNhTADBguUMwKW3uHGo8PaddYILIkQFk+woxHOAImGIfuaBCu1N6j0nOn 9XdM4GE1AkKSCqRUkvPKQ0wQhZy5GrUQGAltI3Bcz25g2re3VZ+ss0sNz A==; X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="447492537" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="447492537" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Sep 2023 03:11:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10841"; a="813388252" X-IronPort-AV: E=Sophos;i="6.03,171,1694761200"; d="scan'208";a="813388252" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga008.fm.intel.com with ESMTP; 23 Sep 2023 03:11:54 -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, nik.borisov@suse.com Subject: [PATCH v11 37/37] x86/fred: Invoke FRED initialization code to enable FRED Date: Sat, 23 Sep 2023 02:42:12 -0700 Message-Id: <20230923094212.26520-38-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230923094212.26520-1-xin3.li@intel.com> References: <20230923094212.26520-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 v10: * No need to invalidate SYSCALL and SYSENTER MSRs (Thomas Gleixner). Changes since v8: * Move this patch after all required changes are in place (Thomas Gleixner). --- arch/x86/kernel/cpu/common.c | 22 +++++++++++++++++----- arch/x86/kernel/irqinit.c | 7 ++++++- arch/x86/kernel/traps.c | 5 ++++- 3 files changed, 27 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 2ee4e7b597a3..e7a5b9831252 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 @@ -2112,7 +2113,15 @@ void syscall_init(void) /* The default user and kernel segments */ wrmsr(MSR_STAR, 0, (__USER32_CS << 16) | __KERNEL_CS); =20 - idt_syscall_init(); + /* + * Except the IA32_STAR MSR, there is NO need to setup SYSCALL and + * SYSENTER MSRs for FRED, because FRED uses the ring 3 FRED + * entrypoint for SYSCALL and SYSENTER, and ERETU is the only legit + * instruction to return to ring 3 (both sysexit and sysret cause + * #UD when FRED is enabled). + */ + if (!cpu_feature_enabled(X86_FEATURE_FRED)) + idt_syscall_init(); } =20 #else /* CONFIG_X86_64 */ @@ -2228,8 +2237,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 @@ -2238,8 +2248,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