Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2041156ybi; Sun, 16 Jun 2019 20:14:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqze7oda53AQF/Jqyi6m9P7P94kqZqNcnVFEZJSU4sMxC1gfjNPBhfgnWxbrDMYIUyUMX+ZT X-Received: by 2002:a62:cdc8:: with SMTP id o191mr42001729pfg.74.1560741294334; Sun, 16 Jun 2019 20:14:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560741294; cv=none; d=google.com; s=arc-20160816; b=rNNxUDHbOthHlxBxI/bAoaPVJjD0TnC8+xrARxkv8NBe1xxEqTk/nLY2qvcmx8W87L DF81O9KrURK4Bjgzk4/Fh5ICD65sT+JCqwId0xt2a8q6YcFs996XEWAhyuNyQ+3QLKtI v1hA7M8ytJkBPRUV5crzTH3N1ivQ8UHExS1qUCHcgDoE1nSCDQi4tpfAIK7BuJ5TPKdI fTGMygah452choTQql0YjD5m1dWufZJkWiMmcGFvpu2/cBnl7JkmGJaSqxSrLGc978Sq DwcwkAr59Oh75HfwUU+8mjPvUVkmeHal/CMHrZwP7ijdrdmkoJEJeuVVGs9ESfYKRCnO vD3g== 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; bh=Mz784ipIwNxejQsE2+n+M8MeNShXZD+sx5XSxzLueo8=; b=XtkOADLUfooS9QLNCZg9m7KBtV+K3RPD0T6ubnwuXyVT7X3gZ/TcrY8TJeEgSyWenb WWNBmyx0jaHQOe4nDPYlie/fd3LmCa300bMPb0f7yYqjRs1TpTjGbsNcInvyu4bN8a1o zn5clERmMlOhMRt9BkHk0/iXWnesxOCIreNa6Zfz9TwfJSqY2DtHqdqq9Gedkq7IE/1B 7uXLHfve7wX8QjXtl6k/ZxDxjkEBFy2mFkRkFpb4oTU5qVg3IVVPnQFSWgmdi3uU6lq0 2Tlb42T/zyeDyig5Jua4DXQ3A3Ph4X9xAtIC+elfT395ohqULxg7dOfAY66IhLYwhcb6 Yorw== 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 g31si9046431plb.241.2019.06.16.20.14.39; Sun, 16 Jun 2019 20:14:54 -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 S1727554AbfFQDOe (ORCPT + 99 others); Sun, 16 Jun 2019 23:14:34 -0400 Received: from mga03.intel.com ([134.134.136.65]:11096 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727383AbfFQDOe (ORCPT ); Sun, 16 Jun 2019 23:14:34 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jun 2019 20:14:33 -0700 X-ExtLoop1: 1 Received: from khuang2-desk.gar.corp.intel.com ([10.255.91.82]) by fmsmga004.fm.intel.com with ESMTP; 16 Jun 2019 20:14:30 -0700 Message-ID: <1560741269.5187.7.camel@linux.intel.com> Subject: Re: [PATCH, RFC 49/62] mm, x86: export several MKTME variables From: Kai Huang To: Peter Zijlstra , "Kirill A. Shutemov" Cc: Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Andy Lutomirski , David Howells , Kees Cook , Dave Hansen , Jacob Pan , Alison Schofield , linux-mm@kvack.org, kvm@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 17 Jun 2019 15:14:29 +1200 In-Reply-To: <20190614115647.GI3436@hirez.programming.kicks-ass.net> References: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> <20190508144422.13171-50-kirill.shutemov@linux.intel.com> <20190614115647.GI3436@hirez.programming.kicks-ass.net> 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 Fri, 2019-06-14 at 13:56 +0200, Peter Zijlstra wrote: > On Wed, May 08, 2019 at 05:44:09PM +0300, Kirill A. Shutemov wrote: > > From: Kai Huang > > > > KVM needs those variables to get/set memory encryption mask. > > > > Signed-off-by: Kai Huang > > Signed-off-by: Kirill A. Shutemov > > --- > > arch/x86/mm/mktme.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/arch/x86/mm/mktme.c b/arch/x86/mm/mktme.c > > index df70651816a1..12f4266cf7ea 100644 > > --- a/arch/x86/mm/mktme.c > > +++ b/arch/x86/mm/mktme.c > > @@ -7,13 +7,16 @@ > > > > /* Mask to extract KeyID from physical address. */ > > phys_addr_t mktme_keyid_mask; > > +EXPORT_SYMBOL_GPL(mktme_keyid_mask); > > /* > > * Number of KeyIDs available for MKTME. > > * Excludes KeyID-0 which used by TME. MKTME KeyIDs start from 1. > > */ > > int mktme_nr_keyids; > > +EXPORT_SYMBOL_GPL(mktme_nr_keyids); > > /* Shift of KeyID within physical address. */ > > int mktme_keyid_shift; > > +EXPORT_SYMBOL_GPL(mktme_keyid_shift); > > > > DEFINE_STATIC_KEY_FALSE(mktme_enabled_key); > > EXPORT_SYMBOL_GPL(mktme_enabled_key); > > NAK, don't export variables. Who owns the values, who enforces this? > Both KVM and IOMMU driver need page_keyid() and mktme_keyid_shift to set page's keyID to the right place in the PTE (of KVM EPT and VT-d DMA page table). MKTME key type code need to know mktme_nr_keyids in order to alloc/free keyID. Maybe better to introduce functions instead of exposing variables directly? Or instead of introducing page_keyid(), we use page_encrypt_mask(), which essentially holds "page_keyid() << mktme_keyid_shift"? Thanks, -Kai