Message ID | 20230914044805.301390-37-xin3.li@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp232213vqi; Thu, 14 Sep 2023 02:58:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEWrOeTQISkSIJuQhGtz16UTbmWCHWZ/Rj2i5nCHBnQ+KIfN13ZkBauSGDLBtU74jc+UR9K X-Received: by 2002:a05:6a21:488b:b0:13b:9d80:673d with SMTP id av11-20020a056a21488b00b0013b9d80673dmr4389922pzc.48.1694685488153; Thu, 14 Sep 2023 02:58:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694685488; cv=none; d=google.com; s=arc-20160816; b=sAa6kGscQJn1dFBekXmgDQ9VmzvTseE3mpjCefo88w+XI8wffUccS70tV6NhVGEaHC gRQCLj+mwrOt/ECYTXDjbW9VRuwuFd33/eFE522zWRf4XkHz9/BExUyxgY6IKCHSx/rl ovGyoS+JQX+kqAmhxYleng6c5V8Mg/EvOXV/rlfIBIeaX/krAANH1OXbNfR7AIYpdjvZ rZAcWW+lqxebvUFhveqaB7rwi5Y1B21BzlZNsUnh96EVmLBN10YGKfVo61pn9p5YvJ2q q45SGf3bnO5+mZAiK1QQ8VK79gWgnkuwxmG1vmWQIlFyeBdT34ZREWad/ZQFN5qf4ePI JRZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=bgbUUJZhuqIO1/x6sZ1siXYFIMDY3FFQhVAdvod2IYc=; fh=jqCbnajAXgJ+s7A1aA7DOHJD13/+EpD442pw8d+Ofss=; b=X6LZfBFp2m6EzS3Thwnnmjbgse5Axdvk2VfHtnidVMC+m8mNAaS8Coe4SHK2xJBRMZ lJn2n1sy1sLdV4VN6xKK7/YcFuZDBYb0wPGz12lsfv9NdrGf5024Zqvll3Zf4FL0kE1V n9TkE4kOsYJyE7HA0Vtvw+BBWqA2ha2jyVrp4GGdPgfgNF9MpOds83pCZq6tVlvTIqxE ijxO8IzM46c25mC5a3Nf27qvDQPwXXn65GdMDiwhwSqE1VarTevFJAm70kg0RSRmeIdV 6v6TrrUMn5HBTAnJFX0hsO1o/dGT9Qnc6ffGldKS945mCFjPvrkceuB4LTbCKJOEFnmb WAcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZzL6Kn4c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id i1-20020a17090aee8100b0027015573fbasi3570892pjz.70.2023.09.14.02.58.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 02:58:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZzL6Kn4c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 9E8B681F966E; Wed, 13 Sep 2023 22:21:32 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235684AbjINFVE (ORCPT <rfc822;chrisfriedt@gmail.com> + 35 others); Thu, 14 Sep 2023 01:21:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235309AbjINFUF (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 14 Sep 2023 01:20:05 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 74E4C212E; Wed, 13 Sep 2023 22:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694668767; x=1726204767; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=DfU6e7Lxi3caIgHaas3RwgcYA9izTEYulGU0upU0hWQ=; b=ZzL6Kn4cqvAk6SV+zVcfAh1hkxVgYHhwoavTha/1ib/qszt4DPW2W38l G/zrHXbGWXq9QOEccAhBkpu6K+WHiBBH8EvoXsjMBNTCraepdmX7YEplF yHgd6DpyqRyddeNLmUJG1TYDcZN1BtOMU5JE59x7YixKWlZ/0nN9517Oo p9/YG3kcWg7G7tRyiMdVIWlhZYpq20XLyq37fRQBNUaUP78pVpRCwj7i5 0d2LvX/8vYZsEEO3OkCPPkYAQQHetkYo5f1XG2v6TiK0CuYXiU2IzjkN1 7ccVewM14F6YGA+O0FOLJb7bT2fIzJRdriaqJCHW4jND+ypmPimq+Uucc Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="382661535" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="382661535" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 22:17:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10832"; a="779488847" X-IronPort-AV: E=Sophos;i="6.02,145,1688454000"; d="scan'208";a="779488847" Received: from unknown (HELO fred..) ([172.25.112.68]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2023 22:17:47 -0700 From: Xin Li <xin3.li@intel.com> To: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-edac@vger.kernel.org, linux-hyperv@vger.kernel.org, kvm@vger.kernel.org, xen-devel@lists.xenproject.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, luto@kernel.org, pbonzini@redhat.com, seanjc@google.com, peterz@infradead.org, jgross@suse.com, ravi.v.shankar@intel.com, mhiramat@kernel.org, andrew.cooper3@citrix.com, jiangshanlai@gmail.com Subject: [PATCH v10 36/38] x86/fred: Add fred_syscall_init() Date: Wed, 13 Sep 2023 21:48:03 -0700 Message-Id: <20230914044805.301390-37-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230914044805.301390-1-xin3.li@intel.com> References: <20230914044805.301390-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 13 Sep 2023 22:21:32 -0700 (PDT) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777006530873395439 X-GMAIL-MSGID: 1777006530873395439 |
Series |
x86: enable FRED for x86-64
|
|
Commit Message
Li, Xin3
Sept. 14, 2023, 4:48 a.m. UTC
From: "H. Peter Anvin (Intel)" <hpa@zytor.com> Add a syscall initialization function fred_syscall_init() for FRED, and this is really just to skip setting up SYSCALL/SYSENTER related MSRs, e.g., MSR_LSTAR and invalidate SYSENTER configurations, because FRED uses the ring 3 FRED entrypoint for SYSCALL and SYSENTER, and ERETU is the only legit instruction to return to ring 3 per FRED spec 5.0. Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com> Tested-by: Shan Kang <shan.kang@intel.com> Signed-off-by: Xin Li <xin3.li@intel.com> --- arch/x86/kernel/cpu/common.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
Comments
On Wed, Sep 13 2023 at 21:48, Xin Li wrote: > +static inline void fred_syscall_init(void) > +{ > + /* > + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL > + * and SYSENTER, and ERETU is the only legit instruction to return to > + * ring 3, as a result there is _no_ need to setup the SYSCALL and > + * SYSENTER MSRs. > + * > + * Note, both sysexit and sysret cause #UD when FRED is enabled. > + */ > + wrmsrl(MSR_LSTAR, 0ULL); > + wrmsrl_cstar(0ULL); That write is pointless. See the comment in wrmsrl_cstar(). Thanks, tglx
> > +static inline void fred_syscall_init(void) { > > + /* > > + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL > > + * and SYSENTER, and ERETU is the only legit instruction to return to > > + * ring 3, as a result there is _no_ need to setup the SYSCALL and > > + * SYSENTER MSRs. > > + * > > + * Note, both sysexit and sysret cause #UD when FRED is enabled. > > + */ > > + wrmsrl(MSR_LSTAR, 0ULL); > > + wrmsrl_cstar(0ULL); > > That write is pointless. See the comment in wrmsrl_cstar(). What I heard is that AMD is going to support FRED. Both LSTAR and CSTAR have no function when FRED is enabled, so maybe just do NOT write to them? Thanks! Xin
On Wed, Sep 20 2023 at 04:33, Li, Xin3 wrote: >> > +static inline void fred_syscall_init(void) { >> > + /* >> > + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL >> > + * and SYSENTER, and ERETU is the only legit instruction to return to >> > + * ring 3, as a result there is _no_ need to setup the SYSCALL and >> > + * SYSENTER MSRs. >> > + * >> > + * Note, both sysexit and sysret cause #UD when FRED is enabled. >> > + */ >> > + wrmsrl(MSR_LSTAR, 0ULL); >> > + wrmsrl_cstar(0ULL); >> >> That write is pointless. See the comment in wrmsrl_cstar(). > > What I heard is that AMD is going to support FRED. > > Both LSTAR and CSTAR have no function when FRED is enabled, so maybe > just do NOT write to them? Right. If AMD needs to clear it then it's trivial enough to add a wrmsrl_cstar(0) to it.
On September 20, 2023 1:18:14 AM PDT, Thomas Gleixner <tglx@linutronix.de> wrote: >On Wed, Sep 20 2023 at 04:33, Li, Xin3 wrote: >>> > +static inline void fred_syscall_init(void) { >>> > + /* >>> > + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL >>> > + * and SYSENTER, and ERETU is the only legit instruction to return to >>> > + * ring 3, as a result there is _no_ need to setup the SYSCALL and >>> > + * SYSENTER MSRs. >>> > + * >>> > + * Note, both sysexit and sysret cause #UD when FRED is enabled. >>> > + */ >>> > + wrmsrl(MSR_LSTAR, 0ULL); >>> > + wrmsrl_cstar(0ULL); >>> >>> That write is pointless. See the comment in wrmsrl_cstar(). >> >> What I heard is that AMD is going to support FRED. >> >> Both LSTAR and CSTAR have no function when FRED is enabled, so maybe >> just do NOT write to them? > >Right. If AMD needs to clear it then it's trivial enough to add a >wrmsrl_cstar(0) to it. Just to clarify: the only reason I added the writes here was to possibly make bugs easier to track down. There is indeed no functional reason.
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index d960b7276008..4cb36e241c9a 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -2105,6 +2105,23 @@ static inline void idt_syscall_init(void) X86_EFLAGS_AC|X86_EFLAGS_ID); } +static inline void fred_syscall_init(void) +{ + /* + * Per FRED spec 5.0, FRED uses the ring 3 FRED entrypoint for SYSCALL + * and SYSENTER, and ERETU is the only legit instruction to return to + * ring 3, as a result there is _no_ need to setup the SYSCALL and + * SYSENTER MSRs. + * + * Note, both sysexit and sysret cause #UD when FRED is enabled. + */ + wrmsrl(MSR_LSTAR, 0ULL); + wrmsrl_cstar(0ULL); + wrmsrl_safe(MSR_IA32_SYSENTER_CS, (u64)GDT_ENTRY_INVALID_SEG); + wrmsrl_safe(MSR_IA32_SYSENTER_ESP, 0ULL); + wrmsrl_safe(MSR_IA32_SYSENTER_EIP, 0ULL); +} + /* May not be marked __init: used by software suspend */ void syscall_init(void) {