Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4006379imm; Mon, 18 Jun 2018 07:42:16 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ3ZYcZQAibZPfnRvukqcTbkOipZqX1byKCLQVHHLL4qPkG+0STOqELyone40ivdCpCHWtr X-Received: by 2002:a63:7c55:: with SMTP id l21-v6mr11502191pgn.352.1529332935995; Mon, 18 Jun 2018 07:42:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529332935; cv=none; d=google.com; s=arc-20160816; b=I0pyeRbREkbuTg9iXlKVGLUDKrFOZosPoJTF4fjPHJahk8a0ACEaxw/Htc8WjSKzFM xvxizZ2V1XObnlFHNojULu9vQ17u2flTTtySZCMve2Q7tNUQXsdViwBHd/AqZ25G9LDU c+VIIxsNHL9ElfJrRBxi3D+xV4U/MjR6yM/ZZ84MWSPEdzftD2wM8a2TRsJL2AzOjC5w 9ahgIA6eP5Lkm6rBg8bXxhwlJ8YTKGgezjiLKI2DVRD9uzAaFunK5Dhs0geYcw9de//H 9YX/1icBKSQBeZJxR1su2Nw8Irecjb4xmCWGeZ+Yq6ajybD688IzkP7SCVtS7OXnZjfC LHlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=1a5drbszJKUW2+kDHscxnFF9f0LEPpa663PhG5KFAY0=; b=sSwNCwVff34AxtQ+2qsAmxa31AbPhb7k+3ahRbehe9nsQCxaM3DSHj0p2ESdYJ1Zhq Igpm0Unz/2ihAHuPOs7ohKQBlE30nvPVKNE05nZ9+GN13aUvXmSdZA6fwYQlh7g+6u3E RRW+nZxPvR7NhRvnZcZBISyEh/9Ox9suX+H+578NjnYpFwKlwJjWVyBieZ+r7HgKF/p9 SpMMjnI9sxdXcI7w2ONz/fOt3xqg2TiPHyNNBWqnsev9cXGlOquotUzFrNUKM2t4B0S0 bD+dofLj633W8Ei9pPNpzcxV3sjU4v+2pJAor4Yq8p84nvJjmCFTY4AEpB5fabv8VJjT g+xg== 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 t66-v6si11940446pgc.6.2018.06.18.07.42.01; Mon, 18 Jun 2018 07:42:15 -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 S935125AbeFROlK (ORCPT + 99 others); Mon, 18 Jun 2018 10:41:10 -0400 Received: from mga11.intel.com ([192.55.52.93]:11442 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934367AbeFROlJ (ORCPT ); Mon, 18 Jun 2018 10:41:09 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jun 2018 07:41:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,239,1526367600"; d="scan'208";a="58212199" Received: from black.fi.intel.com ([10.237.72.28]) by FMSMGA003.fm.intel.com with ESMTP; 18 Jun 2018 07:41:05 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 9B3E4FA; Mon, 18 Jun 2018 17:41:06 +0300 (EEST) Date: Mon, 18 Jun 2018 17:41:06 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky , Kai Huang , Jacob Pan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv3 16/17] x86/mm: Handle encrypted memory in page_to_virt() and __pa() Message-ID: <20180618144106.2gga6w55zbbnnjhb@black.fi.intel.com> References: <20180612143915.68065-1-kirill.shutemov@linux.intel.com> <20180612143915.68065-17-kirill.shutemov@linux.intel.com> <20180618133455.aumn4wihygvds543@black.fi.intel.com> <48fe7072-e92d-959a-67f7-ded82124f79f@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48fe7072-e92d-959a-67f7-ded82124f79f@intel.com> User-Agent: NeoMutt/20170714-126-deb55f (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 18, 2018 at 01:59:18PM +0000, Dave Hansen wrote: > On 06/18/2018 06:34 AM, Kirill A. Shutemov wrote: > > On Wed, Jun 13, 2018 at 06:43:08PM +0000, Dave Hansen wrote: > >>> diff --git a/arch/x86/include/asm/mktme.h b/arch/x86/include/asm/mktme.h > >>> index efc0d4bb3b35..d6edcabacfc7 100644 > >>> --- a/arch/x86/include/asm/mktme.h > >>> +++ b/arch/x86/include/asm/mktme.h > >>> @@ -43,6 +43,9 @@ void mktme_disable(void); > >>> void setup_direct_mapping_size(void); > >>> int sync_direct_mapping(void); > >>> > >>> +#define page_to_virt(x) \ > >>> + (__va(PFN_PHYS(page_to_pfn(x))) + page_keyid(x) * direct_mapping_size) > >> > >> This looks like a super important memory management function being > >> defined in some obscure Intel-specific feature header. How does that work? > > > > No magic. It overwrites define in . > > It frankly looks like magic to me. How can this possibly work without > ensuring that asm/mktme.h is #included everywhere on every file compiled > for the entire architecture? asm/mktme.h is included from asm/page.h. It is functionally identical other architectures. > If we look at every definition of page_to_virt() on every architecture > in the kernel, we see it uniquely defined in headers that look rather > generic. I don't see any precedent for feature-specific definitions. I do. m68k and microblaze have different definitions of the macro depending on CONFIG_MMU. On arm64 it depends on CONFIG_SPARSEMEM_VMEMMAP. > > arch/arm64/include/asm/memory.h:#define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET)) > > arch/hexagon/include/asm/page.h:#define page_to_virt(page) __va(page_to_phys(page)) > > arch/m68k/include/asm/page_mm.h:#define page_to_virt(page) ({ \ > > arch/m68k/include/asm/page_no.h:#define page_to_virt(page) __va(((((page) - mem_map) << PAGE_SHIFT) + PAGE_OFFSET)) > > arch/microblaze/include/asm/page.h:# define page_to_virt(page) __va(page_to_pfn(page) << PAGE_SHIFT) > > arch/microblaze/include/asm/page.h:# define page_to_virt(page) (pfn_to_virt(page_to_pfn(page))) > > arch/nios2/include/asm/page.h:#define page_to_virt(page) \ > > arch/riscv/include/asm/page.h:#define page_to_virt(page) (pfn_to_virt(page_to_pfn(page))) > > arch/s390/include/asm/page.h:#define page_to_virt(page) pfn_to_virt(page_to_pfn(page)) > > arch/xtensa/include/asm/page.h:#define page_to_virt(page) __va(page_to_pfn(page) << PAGE_SHIFT) > > *If* you do this, I think it 100% *HAS* to be done in a central header, > like x86's page.h. We need a single x86 macro for this, not something > which can and will change based on #include ordering and Kconfig. I don't agree. asm/mktme.h included from the single header -- asm/page.h -- and has clear path to linux/mm.h where the default page_to_virt() is defined. I don't see a reason to move it out of feature-specific header. The default page_to_virt() is perfectly fine without MKTME. And it will be obvious on grep. -- Kirill A. Shutemov