Message ID | 20231003062458.23552-2-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:2a8e:b0:403:3b70:6f57 with SMTP id in14csp1898474vqb; Mon, 2 Oct 2023 23:54:52 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFFbatBFzueynrgM0r9Yfrmw8ZkxYKsSgArY2darEYN28+5e7z7kRyu5VrFm7AUmo8gA7vV X-Received: by 2002:a05:6358:7057:b0:15a:e6ac:ee5d with SMTP id 23-20020a056358705700b0015ae6acee5dmr1123526rwp.17.1696316092505; Mon, 02 Oct 2023 23:54:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696316092; cv=none; d=google.com; s=arc-20160816; b=f7V0THQHhRjtZi+nRDL0TO8w7x+Qb3N+HDWfFkfQi6l9SpHDCpsidtVq9V9D6cN7zN v0BYxIe7kacU9OthujG9gpxlARPPZ7pj8VRscycsImeu7386BhF4XTdbXatVdU/41XVi IMs8zOzA/lM+tqkt2E4BDy4EMxF1hi5WvyRWF/PH17RB/sdXQuyYCUXrfizdMikZSdje OkwM3U2hd3SjvftFV+lq4aqymjGGBwmdOOOqx6V4YhlOEgAn3nbHrgoQ7F3pa55xCKbq ojw03X9ftfU1cjwn81EkpNeJOwaXq5uRwDc8DQxLfY2Z9SXYmlAJ64zlQ9sjuhMc2g0Q XGtQ== 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=m41IHhIqcT3QTi5OQH6Wl04uozSE0BREiOIXnwM2WFI=; fh=Tb1p8S3iOxe/kX/WSNC3xEJzSVgGJ5DaxSrKb+pzH+4=; b=jy3DQoKhUx2bPQ6ehsjOzG0WbLo7VKtRKaDkjfakqvwOLeHU798qqYDUA3lppT83XP K18302H6lrErZx6sXC6FIuyHmLNBcNqfWz7ExgHeY8Tk3H+9R+hWRUhlIWcy9Ud4yJ5j qmQs41pSoOxhvdfZosXX8hhYWE/kgNp/92XExEujObtu7n3KVT+TpezYWR4EGcp7zVln p/6izdLp8+W7HJYnPVyKYgYUfdyvcXXuGKDPbnYhDlhgTJL6WUDq54fHomkv+z5QYG0I JpsTKm2BAvzkn4iS0r8S6gwV2DPVgm/DFuh4KJxocv3BHAFHkXtFeN8VVC7VnBL3b9hp HIfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W42Fi3B0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 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 snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id fc15-20020a056a002e0f00b00690d42ec31bsi869129pfb.369.2023.10.02.23.54.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Oct 2023 23:54:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W42Fi3B0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 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 snail.vger.email (Postfix) with ESMTP id 609E38129AF4; Mon, 2 Oct 2023 23:54:51 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230359AbjJCGyo (ORCPT <rfc822;pusanteemu@gmail.com> + 18 others); Tue, 3 Oct 2023 02:54:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230433AbjJCGyk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 3 Oct 2023 02:54:40 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9794FAC; Mon, 2 Oct 2023 23:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696316077; x=1727852077; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=5bEJT87B98JS6iQ6LlrNVmLBQuK2BkIiNY3V5ZdVNuo=; b=W42Fi3B0qrpu+FUCrOq9rp/2juU+nc3VMgeLLeJRP6sXaRK8GVR/ktzl Vj1t97gTM6GOhhMa4Epl13W11wo1o/SyiGz8gqKoBFPd0CR6IvXwcG3XX tCKcYhQpn6l5IKVQYz5BQrIgLqC5F7SWvAozUHTeerTDPM+zBikjV0kPS bL4c0wBJdTEDRmBOXQDHbwQkvywasog2rrNYWdRrCIlmSNyn0efwUmHPR YJNceZuxidQSm/UXmLz3OtyZ2Remw7oER/FYjUc/oM6eC3aBicaQCVg+g Eu9YVOHF/yx5bMmjdEDVguUi9KIJMr+UfUoHYTfCzI0sK8OHk/PnhaF7Q A==; X-IronPort-AV: E=McAfee;i="6600,9927,10851"; a="367857912" X-IronPort-AV: E=Sophos;i="6.03,196,1694761200"; d="scan'208";a="367857912" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Oct 2023 23:54:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10851"; a="1081900894" X-IronPort-AV: E=Sophos;i="6.03,196,1694761200"; d="scan'208";a="1081900894" Received: from unknown (HELO fred..) ([172.25.112.68]) by fmsmga005.fm.intel.com with ESMTP; 02 Oct 2023 23:54:34 -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, nik.borisov@suse.com Subject: [PATCH v12 01/37] x86/cpufeatures: Add the cpu feature bit for WRMSRNS Date: Mon, 2 Oct 2023 23:24:22 -0700 Message-Id: <20231003062458.23552-2-xin3.li@intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231003062458.23552-1-xin3.li@intel.com> References: <20231003062458.23552-1-xin3.li@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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 (snail.vger.email [0.0.0.0]); Mon, 02 Oct 2023 23:54:51 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778716343044092176 X-GMAIL-MSGID: 1778716343044092176 |
Series |
x86: enable FRED for x86-64
|
|
Commit Message
Li, Xin3
Oct. 3, 2023, 6:24 a.m. UTC
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 <shan.kang@intel.com> Signed-off-by: Xin Li <xin3.li@intel.com> --- arch/x86/include/asm/cpufeatures.h | 1 + tools/arch/x86/include/asm/cpufeatures.h | 1 + 2 files changed, 2 insertions(+)
Comments
On Mon, Oct 02, 2023 at 11:24:22PM -0700, Xin Li wrote: > Subject: Re: [PATCH v12 01/37] x86/cpufeatures: Add the cpu feature bit for WRMSRNS ^^^^ For all your text: s/cpu/CPU/g > 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 <shan.kang@intel.com> > Signed-off-by: Xin Li <xin3.li@intel.com> > --- > arch/x86/include/asm/cpufeatures.h | 1 + > tools/arch/x86/include/asm/cpufeatures.h | 1 + > 2 files changed, 2 insertions(+) It looks to me like you can merge the first three patches into one as all they do is add that insn support. Then, further down in the patchset, it says: + if (cpu_feature_enabled(X86_FEATURE_FRED)) { + /* WRMSRNS is a baseline feature for FRED. */ but WRMSRNS is not mentioned in the FRED spec "Document Number: 346446-005US, Revision: 5.0" which, according to https://www.intel.com/content/www/us/en/content-details/780121/flexible-return-and-event-delivery-fred-specification.html is the latest. Am I looking at the wrong one? > diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.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 Model Specific Register instruction */ /* "" Non-serializing WRMSR */ is more than enough. And now I'm wondering: when you're adding a separate CPUID bit, then the above should be + if (cpu_feature_enabled(X86_FEATURE_WRMSRNS)) { + /* WRMSRNS is a baseline feature for FRED. */ I see that you're adding a dependency: + { X86_FEATURE_FRED, X86_FEATURE_WRMSRNS }, which then means you don't need the X86_FEATURE_WRMSRNS definition at all and can use X86_FEATURE_FRED only. So, what's up? Thx.
> Then, further down in the patchset, it says: > > + if (cpu_feature_enabled(X86_FEATURE_FRED)) { > + /* WRMSRNS is a baseline feature for FRED. */ > > but WRMSRNS is not mentioned in the FRED spec "Document Number: > 346446-005US, Revision: 5.0" which, according to > > https://www.intel.com/content/www/us/en/content-details/780121/flexible- > return-and-event-delivery-fred-specification.html > > is the latest. > > Am I looking at the wrong one? No. tglx asked for it: https://lkml.kernel.org/kvm/87y1h81ht4.ffs@tglx/ > > And now I'm wondering: when you're adding a separate CPUID bit, then the > above should be > > + if (cpu_feature_enabled(X86_FEATURE_WRMSRNS)) { > + /* WRMSRNS is a baseline feature for FRED. */ Because we are doing wrmsrns(MSR_IA32_FRED_RSP0, ...) here, and X86_FEATURE_WRMSRNS doesn't guarantee MSR_IA32_FRED_RSP0 exists. Or I missed something? > > I see that you're adding a dependency: > > + { X86_FEATURE_FRED, X86_FEATURE_WRMSRNS }, > > which then means you don't need the X86_FEATURE_WRMSRNS definition at all > and can use X86_FEATURE_FRED only. > > So, what's up? FRED just gets the honor to introduce WRMSRNS and its first usage: https://lkml.kernel.org/kvm/b05e3092-8ba3-f4e1-b5a3-2125944936fd@zytor.com/ Another patch set should replace WRMSR with WRMSRNS, with SERIALIZE added when needed. Sorry for the late response, it was a long weekend in the US. Thanks! Xin
On Tue, Nov 14, 2023 at 12:43:38AM +0000, Li, Xin3 wrote: > No. tglx asked for it: > https://lkml.kernel.org/kvm/87y1h81ht4.ffs@tglx/ Aha "According to the CPU folks FRED systems are guaranteed to have WRMSRNS - I asked for that :). It's just not yet documented." so I'm going to expect that to appear in the next FRED spec revision... > Because we are doing > wrmsrns(MSR_IA32_FRED_RSP0, ...) > here, and X86_FEATURE_WRMSRNS doesn't guarantee MSR_IA32_FRED_RSP0 exists. > > Or I missed something? Well, according to what I'm hearing and reading so far: FRED means WRMSRNS FRED means MSR_IA32_FRED_RSP0 and if you had to be precise, the code should do: if (cpu_feature_enabled(X86_FEATURE_FRED)) { if (cpu_feature_enabled(X86_FEATURE_WRMSRNS)) wrmsrns(MSR_IA32_FRED_RSP0, (unsigned long)task_stack_page(task) + THREAD_SIZE); else wrmsr(MSR_IA32_FRED_RSP0, (unsigned long)task_stack_page(task) + THREAD_SIZE); } but apparently FRED implies WRMSRNS - not documented anywhere currently - so you can save yourself one check. But your version checks FRED if it can do WRMSRNS while there's a separate WRMSRNS flag and that made me wonder... > Another patch set should replace WRMSR with WRMSRNS, with SERIALIZE added > when needed. I sense someone wants to optimize MSR writes ... :-) Thx.
> and if you had to be precise, the code should do: > > if (cpu_feature_enabled(X86_FEATURE_FRED)) { > if (cpu_feature_enabled(X86_FEATURE_WRMSRNS)) > wrmsrns(MSR_IA32_FRED_RSP0, (unsigned > long)task_stack_page(task) + THREAD_SIZE); > else > wrmsr(MSR_IA32_FRED_RSP0, (unsigned > long)task_stack_page(task) + THREAD_SIZE); > } This is exactly what tglx wanted to avoid. And I love the idea "baseline", especially we have a ton of CPU features. > > > Another patch set should replace WRMSR with WRMSRNS, with SERIALIZE > > added when needed. > > I sense someone wants to optimize MSR writes ... :-) :-)
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.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 Model Specific Register instruction */ #define X86_FEATURE_AMX_FP16 (12*32+21) /* "" AMX fp16 Support */ #define X86_FEATURE_AVX_IFMA (12*32+23) /* "" Support for VPMADD52[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/include/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 Model Specific Register instruction */ #define X86_FEATURE_AMX_FP16 (12*32+21) /* "" AMX fp16 Support */ #define X86_FEATURE_AVX_IFMA (12*32+23) /* "" Support for VPMADD52[H,L]UQ */ #define X86_FEATURE_LAM (12*32+26) /* Linear Address Masking */