Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4538638imm; Mon, 30 Jul 2018 17:09:09 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcwjjbxEfogxOXLKilmwtRZUpFWWXDf0akRHLKJWlXVIMBFdQEtnc7nKxzUqFTWXmL1TNa/ X-Received: by 2002:a63:1c5f:: with SMTP id c31-v6mr18463606pgm.321.1532995749115; Mon, 30 Jul 2018 17:09:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532995749; cv=none; d=google.com; s=arc-20160816; b=aS4YKAI3C39H/PqBZ4maOPwqfJaJMVc08Kk6QT5Uhb/ibKnCoHR9C5259//+PXWB1e /d+R+XlymslHMQ++z411/C7X3AazpLJiTp2QX+iySOCJtQu5vXx9+Ti7l1bwf2Q2XPWT rxosuyAgo/z1tuZBlq+ngI1n2SvkLEcdSnMmDUuNzsdv+52iorREUmZeE16GTQpDQLxk KwF/v/lys5Ho6OLJZaMF5cXmFB449pGmTHDBy29HMknimE+Mi+YEHERmzxKBCc0NAgRP qr10WL963ftrjZ1GV8XKCmM4nb6iWvleHDPh5xj+vPjnM6HOdFT3yB5Ph7URSBQxWVH5 C4+Q== 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 :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=9PGsiJNhyMYI8wBm+CD7nJSkJtfteUwZfpJoGnj64dM=; b=mrgiQIX9k3uofn3hoGZ3MNp0cmR+3o0v9el1yVg9X7LlB24rXM6+NtKdQyWwjYK6XJ jm77KHAoendw+mWHN4sJRns7ofByxRVTcLVjWkEd4WonnjyOic+qkj51eyt2O4gLB1GH T3TQG+P15+78FYaO+OD7jhM2xoBVbWC4yVO9pzQPuZ35gvkTfaFBXprQXMzWimeHsWhB 00WPeZSSOtsAC809UQvFoJxKojIspcldLR69ETyd+1NhaYQ4yJtaLMpnmtvKIzhgYW7D o2B+mzuD2bYICevb/M6Go3a/PFUFK+YwZium6YC4fK8k88LQniwhSguENRK0prxllN4H rJ+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id o189-v6si11893816pga.577.2018.07.30.17.08.53; Mon, 30 Jul 2018 17:09:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1732101AbeGaBpd (ORCPT + 99 others); Mon, 30 Jul 2018 21:45:33 -0400 Received: from mga14.intel.com ([192.55.52.115]:31170 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732038AbeGaBpd (ORCPT ); Mon, 30 Jul 2018 21:45:33 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2018 17:08:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,425,1526367600"; d="scan'208";a="68768493" Received: from khuang2-desk.gar.corp.intel.com ([10.254.180.23]) by FMSMGA003.fm.intel.com with ESMTP; 30 Jul 2018 17:08:04 -0700 Message-ID: <1532995683.27283.12.camel@linux.intel.com> Subject: Re: [PATCHv5 08/19] x86/mm: Introduce variables to store number, shift and mask of KeyIDs From: Kai Huang To: "Kirill A. Shutemov" , Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky Cc: Dave Hansen , Jacob Pan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Date: Tue, 31 Jul 2018 12:08:03 +1200 In-Reply-To: <20180717112029.42378-9-kirill.shutemov@linux.intel.com> References: <20180717112029.42378-1-kirill.shutemov@linux.intel.com> <20180717112029.42378-9-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) 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 Tue, 2018-07-17 at 14:20 +0300, Kirill A. Shutemov wrote: > mktme_nr_keyids holds number of KeyIDs available for MKTME, excluding > KeyID zero which used by TME. MKTME KeyIDs start from 1. > > mktme_keyid_shift holds shift of KeyID within physical address. > > mktme_keyid_mask holds mask to extract KeyID from physical address. Sorry to bring this up, but AMD SME already introduced sme_me_mask, and __sme_{set/clr} in linux/mem_encrypt.h, should we try to merge MKTME and SME to have common variables, and reuse mem_encrypt.h? IMHO sme_me_mask is sort of equivalent to'keyID=1'. And w/ different names for SME and MKTME, in other components which want to use memory encryption (ex, DMA API), we have to have explict code to distinguish MKTME and SME IMO, which is not good. Thanks, -Kai > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/include/asm/mktme.h | 16 ++++++++++++++++ > arch/x86/kernel/cpu/intel.c | 12 ++++++++---- > arch/x86/mm/Makefile | 2 ++ > arch/x86/mm/mktme.c | 5 +++++ > 4 files changed, 31 insertions(+), 4 deletions(-) > create mode 100644 arch/x86/include/asm/mktme.h > create mode 100644 arch/x86/mm/mktme.c > > diff --git a/arch/x86/include/asm/mktme.h > b/arch/x86/include/asm/mktme.h > new file mode 100644 > index 000000000000..df31876ec48c > --- /dev/null > +++ b/arch/x86/include/asm/mktme.h > @@ -0,0 +1,16 @@ > +#ifndef _ASM_X86_MKTME_H > +#define _ASM_X86_MKTME_H > + > +#include > + > +#ifdef CONFIG_X86_INTEL_MKTME > +extern phys_addr_t mktme_keyid_mask; > +extern int mktme_nr_keyids; > +extern int mktme_keyid_shift; > +#else > +#define mktme_keyid_mask ((phys_addr_t)0) > +#define mktme_nr_keyids 0 > +#define mktme_keyid_shift 0 > +#endif > + > +#endif > diff --git a/arch/x86/kernel/cpu/intel.c > b/arch/x86/kernel/cpu/intel.c > index bf2caf9d52dd..efc9e9fc47d4 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -573,6 +573,9 @@ static void detect_tme(struct cpuinfo_x86 *c) > > #ifdef CONFIG_X86_INTEL_MKTME > if (mktme_status == MKTME_ENABLED && nr_keyids) { > + mktme_nr_keyids = nr_keyids; > + mktme_keyid_shift = c->x86_phys_bits - keyid_bits; > + > /* > * Mask out bits claimed from KeyID from physical > address mask. > * > @@ -580,10 +583,8 @@ static void detect_tme(struct cpuinfo_x86 *c) > * and number of bits claimed for KeyID is 6, bits > 51:46 of > * physical address is unusable. > */ > - phys_addr_t keyid_mask; > - > - keyid_mask = GENMASK_ULL(c->x86_phys_bits - 1, c- > >x86_phys_bits - keyid_bits); > - physical_mask &= ~keyid_mask; > + mktme_keyid_mask = GENMASK_ULL(c->x86_phys_bits - 1, > mktme_keyid_shift); > + physical_mask &= ~mktme_keyid_mask; > } else { > /* > * Reset __PHYSICAL_MASK. > @@ -591,6 +592,9 @@ static void detect_tme(struct cpuinfo_x86 *c) > * between CPUs. > */ > physical_mask = (1ULL << __PHYSICAL_MASK_SHIFT) - 1; > + mktme_keyid_mask = 0; > + mktme_keyid_shift = 0; > + mktme_nr_keyids = 0; > } > #endif > > diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile > index 4b101dd6e52f..4ebee899c363 100644 > --- a/arch/x86/mm/Makefile > +++ b/arch/x86/mm/Makefile > @@ -53,3 +53,5 @@ obj-$(CONFIG_PAGE_TABLE_ISOLATION) + > = pti.o > obj-$(CONFIG_AMD_MEM_ENCRYPT) += mem_encrypt.o > obj-$(CONFIG_AMD_MEM_ENCRYPT) += mem_encrypt_identity.o > obj-$(CONFIG_AMD_MEM_ENCRYPT) += mem_encrypt_boot.o > + > +obj-$(CONFIG_X86_INTEL_MKTME) += mktme.o > diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c > new file mode 100644 > index 000000000000..467f1b26c737 > --- /dev/null > +++ b/arch/x86/mm/mktme.c > @@ -0,0 +1,5 @@ > +#include > + > +phys_addr_t mktme_keyid_mask; > +int mktme_nr_keyids; > +int mktme_keyid_shift;