Received: by 10.213.65.68 with SMTP id h4csp805011imn; Thu, 22 Mar 2018 08:57:11 -0700 (PDT) X-Google-Smtp-Source: AG47ELuD9sACrGLbY8svlgHqEuK914d/39YbxNIWemzpc54cuNB/pG6RksRACnXazIoMprpBIXia X-Received: by 10.101.100.200 with SMTP id t8mr983588pgv.358.1521734230937; Thu, 22 Mar 2018 08:57:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521734230; cv=none; d=google.com; s=arc-20160816; b=tcJzGhltD5xlpsO5AsyXwkvrOhgVZnaTThhyma+x+88mh6WPjQgOSLGas2qkjIzGte afucHcJ5yUIagIYtWEVu/aiC7jHwG6n6l6m2BpCqzcxZAjbcHbH3abSy1M3dB4U0pdw0 TDCSnZ9CU9L2A58QHoEecGg9Z9M98xjVLGmm8vWXKoi0xMd9oQS4Do/Cmr9VVu8/ukwt cb9SexeLjro2YceqrFpw0yamSYEVE2BZaO1uPvZaGXhz5rkR5zQKi1SXM8Mkhh9fQN1M +qP1fVBXr7SwPsfOiGeEVaA1/0zowRO8ZFyrO051ymYGNlMHKgkt80hl5JYM1CodUsJn 73RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from :arc-authentication-results; bh=krnMKjeYGRmWLM5itRb98FYMEtPbAc5MUhs1cAMSP64=; b=VllFYke8hFAhoLoHTdCYtlP8ufOPgJJ7nda0CJv9F1ABde7XBQKodhz3QyvRtIa9C7 tTvumrbSvnK5KESO/fpFuB1W2exjSkPUEZPbCtyYwPkqFLzsRNZBqHnbmxtQXPw4Vrov R4vzp1n2Zt4I6BBQPH5Dn5adndZrJZAlW6uTJhT/rdH8rC/+PmAna0rqzNCr1FlEB0Ls mZ5gA62Z7bzZtQ0h7Cky4J0hJlpuibOvIF+r1UiQDRCjkd/VelE61GNvjHsdKa7b3v9f Rac0tAV+hgDB6KaOVSQ4luoNDhM1lQvvPrCAL9z/0TvhrAwP3XEx9E2non52Uh6tX96d lyEA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k80si5246445pfh.137.2018.03.22.08.56.56; Thu, 22 Mar 2018 08:57:10 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751873AbeCVPz4 (ORCPT + 99 others); Thu, 22 Mar 2018 11:55:56 -0400 Received: from foss.arm.com ([217.140.101.70]:39496 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751669AbeCVPzw (ORCPT ); Thu, 22 Mar 2018 11:55:52 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9F9291529; Thu, 22 Mar 2018 08:55:52 -0700 (PDT) Received: from localhost (e105922-lin.cambridge.arm.com [10.1.207.29]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 43AC63F24A; Thu, 22 Mar 2018 08:55:52 -0700 (PDT) From: Punit Agrawal To: "Kirill A. Shutemov" Cc: Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky , Dave Hansen , Kai Huang , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC, PATCH 07/22] x86/mm: Mask out KeyID bits from page table entry pfn References: <20180305162610.37510-1-kirill.shutemov@linux.intel.com> <20180305162610.37510-8-kirill.shutemov@linux.intel.com> Date: Thu, 22 Mar 2018 15:55:50 +0000 In-Reply-To: <20180305162610.37510-8-kirill.shutemov@linux.intel.com> (Kirill A. Shutemov's message of "Mon, 5 Mar 2018 19:25:55 +0300") Message-ID: <87woy414vt.fsf@e105922-lin.cambridge.arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kirill, A flyby comment below. "Kirill A. Shutemov" writes: > MKTME claims several upper bits of the physical address in a page table > entry to encode KeyID. It effectively shrinks number of bits for > physical address. We should exclude KeyID bits from physical addresses. > > For instance, if CPU enumerates 52 physical address bits and number of > bits claimed for KeyID is 6, bits 51:46 must not be threated as part > physical address. > > This patch adjusts __PHYSICAL_MASK during MKTME enumeration. > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/kernel/cpu/intel.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > index c770689490b5..35436bbadd0b 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -580,6 +580,30 @@ static void detect_tme(struct cpuinfo_x86 *c) > mktme_status = MKTME_ENABLED; > } > > +#ifdef CONFIG_X86_INTEL_MKTME > + if (mktme_status == MKTME_ENABLED && nr_keyids) { > + /* > + * Mask out bits claimed from KeyID from physical address mask. > + * > + * For instance, if a CPU enumerates 52 physical address bits > + * and number of bits claimed for KeyID is 6, bits 51:46 of > + * physical address is unusable. > + */ > + phys_addr_t keyid_mask; > + > + keyid_mask = 1ULL << c->x86_phys_bits; > + keyid_mask -= 1ULL << (c->x86_phys_bits - keyid_bits); > + physical_mask &= ~keyid_mask; You could use GENMASK_ULL() to construct the keyid_mask instead of rolling your own here. Thanks, Punit > + } else { > + /* > + * Reset __PHYSICAL_MASK. > + * Maybe needed if there's inconsistent configuation > + * between CPUs. > + */ > + physical_mask = (1ULL << __PHYSICAL_MASK_SHIFT) - 1; > + } > +#endif > + > /* > * Exclude KeyID bits from physical address bits. > *