Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1461931ybh; Thu, 23 Jul 2020 09:24:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzwl29SnVTcNigBaiEpnSLgfm9AcSoM9PCUv86Q2GNLzgfpOqgSHa3uxVjXg3odB+cXGnQ X-Received: by 2002:a50:ccc7:: with SMTP id b7mr5141631edj.9.1595521495297; Thu, 23 Jul 2020 09:24:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595521495; cv=none; d=google.com; s=arc-20160816; b=DhqKJ3aDa0DJvvAYqBst+FLIumO4VkFDLgE8bu2vffPEg+fXEOc09JYC2nF0qccnyn hSzQW342v0FR6bIMXcNzYLKtYKO6KQZMOTGusmCHWLFvn54K4dWWsOb2CJ+5KRpmBoPE fg7P5BUnYD4h5ymiqnXA+3B+qyMLU9AzqHfU3KRzSwpOTta3O3yEGpn2W4msROKUEl5l sUUaEnTejzCbddN5NAdNYQegK8K5/jrOR6I9BE1YTs1Ea42Csk8q/JSI6R8RtTvpnnjE KAlG+CB3LIMZRhmvJWGnzcXQTMY+1sqi4agnQVC+loz6TPhHUw0NUML0MEnSSrE6I61l gc+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:ironport-sdr:ironport-sdr; bh=AsaV7+f6sZBnwIjk9aJWWz0EsWLHmpKgPPuGawLTJMA=; b=dqPKVH8am/wafDX5Io1s/ykhzd6oL7RpknfXogtay5Shcjenp0mbXq2prdkNSlBv+J 4fBRb9yJC+nlzPinsRS0zYoNrTiLMGndWY4//ChjVKWKs91bI8bK2sS7xLlOmzN5uYP0 inqC/OFOKJkl0jJYa8nEQQgNwU0rULnsD6Tq5ZP9xOnoE5rdETMtnhrdjYzmaAMKeabD 40mJC4jL6rqGDZwwwrSV5didRCSdLQ2bFglZIDbiRWFFGTw9l1NjpJT3aGQRUYPS9GjH oHgppG5vy7fI+2+ziOvS2CEhle0BujpeQg1LKgltE2Nq32/rAxUnDnTPjZQ97mt39pQv 7mlw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bq6si2254530ejb.108.2020.07.23.09.24.32; Thu, 23 Jul 2020 09:24:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729782AbgGWQWQ (ORCPT + 99 others); Thu, 23 Jul 2020 12:22:16 -0400 Received: from mga11.intel.com ([192.55.52.93]:24631 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726632AbgGWQWQ (ORCPT ); Thu, 23 Jul 2020 12:22:16 -0400 IronPort-SDR: z5N4fbWKImmiwnK71WXZ2HciV2+Fi7Ne4dFvWX4g0NZstESE075S9iwvLaNEWnJbUkyR3aDGFn Tsf5zY0DKn0g== X-IronPort-AV: E=McAfee;i="6000,8403,9691"; a="148496987" X-IronPort-AV: E=Sophos;i="5.75,387,1589266800"; d="scan'208";a="148496987" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jul 2020 09:22:15 -0700 IronPort-SDR: OJt4vWrnoAP6pK5ymUZfgjDLP5rmH9XKLAPLTI79wcTcZb9YrBtgh2IIbZMntAMNwYvSx0bkCH eLMX9JaGcUSA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,387,1589266800"; d="scan'208";a="363096816" Received: from yyu32-desk.sc.intel.com ([143.183.136.146]) by orsmga001.jf.intel.com with ESMTP; 23 Jul 2020 09:22:14 -0700 Message-ID: <2590914945c04d7758f54a9c51dfc6b82924b4e6.camel@intel.com> Subject: Re: [PATCH v10 03/26] x86/fpu/xstate: Introduce CET MSR XSAVES supervisor states From: Yu-cheng Yu To: Sean Christopherson Cc: x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang Date: Thu, 23 Jul 2020 09:21:16 -0700 In-Reply-To: <20200723161039.GE21891@linux.intel.com> References: <20200429220732.31602-1-yu-cheng.yu@intel.com> <20200429220732.31602-4-yu-cheng.yu@intel.com> <20200723161039.GE21891@linux.intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 (3.32.4-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-07-23 at 09:10 -0700, Sean Christopherson wrote: > On Wed, Apr 29, 2020 at 03:07:09PM -0700, Yu-cheng Yu wrote: > > diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h > > index 12c9684d59ba..47f603729543 100644 > > --- a/arch/x86/include/asm/msr-index.h > > +++ b/arch/x86/include/asm/msr-index.h > > @@ -885,4 +885,22 @@ > > #define MSR_VM_IGNNE 0xc0010115 > > #define MSR_VM_HSAVE_PA 0xc0010117 > > > > +/* Control-flow Enforcement Technology MSRs */ > > +#define MSR_IA32_U_CET 0x6a0 /* user mode cet setting */ > > +#define MSR_IA32_S_CET 0x6a2 /* kernel mode cet setting */ > > +#define MSR_IA32_PL0_SSP 0x6a4 /* kernel shstk pointer */ > > +#define MSR_IA32_PL1_SSP 0x6a5 /* ring-1 shstk pointer */ > > +#define MSR_IA32_PL2_SSP 0x6a6 /* ring-2 shstk pointer */ > > +#define MSR_IA32_PL3_SSP 0x6a7 /* user shstk pointer */ > > +#define MSR_IA32_INT_SSP_TAB 0x6a8 /* exception shstk table */ > > + > > +/* MSR_IA32_U_CET and MSR_IA32_S_CET bits */ > > +#define MSR_IA32_CET_SHSTK_EN 0x0000000000000001ULL > > Can we drop the MSR_IA32 prefix for the individual bits? Mostly to yield > shorter line lengths, but also because it's more or less redundant info, > and in some ways unhelpful as it's hard to quickly differentiate between > "this is an MSR index" and "this is a bit/mask for an MSR". Agree! > > My vote would also be to use BIT() or BIT_ULL(). The SDM defines the flags > by their (decimal) bit number. Manually converting the bits to masks makes > it difficult to check for correctness. > > E.g. > > #define CET_SHSTK_EN BIT(0) > #define CET_WRSS_EN BIT(1) > #define CET_ENDBR_EN BIT(2) > #define CET_LEG_IW_EN BIT(3) > #define CET_NO_TRACK_EN BIT(4) > #define CET_WAIT_ENDBR BIT(5) I will change them. > > > +#define MSR_IA32_CET_WRSS_EN 0x0000000000000002ULL > > +#define MSR_IA32_CET_ENDBR_EN 0x0000000000000004ULL > > +#define MSR_IA32_CET_LEG_IW_EN 0x0000000000000008ULL > > +#define MSR_IA32_CET_NO_TRACK_EN 0x0000000000000010ULL > > +#define MSR_IA32_CET_WAIT_ENDBR 0x00000000000000800UL > > +#define MSR_IA32_CET_BITMAP_MASK 0xfffffffffffff000ULL > > This particular define, the so called BITMAP_MASK, is no longer used in the > IBT series. IMO it'd be better off dropping this mask as it's not clear > from the name that this is really nothing more than a mask for a virtual > address, e.g. at first glance (for someone without CET knowledge) it looks > like bits 63:12 hold a bitmap as opposed to holding a pointer to a bitmap. I will remove this. Thanks, Yu-cheng