From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-dm3nam03on0056.outbound.protection.outlook.com ([104.47.41.56] helo=NAM03-DM3-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dPWz5-0002R1-Mz for kexec@lists.infradead.org; Mon, 26 Jun 2017 16:35:33 +0000 Subject: Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place References: <20170616184947.18967.84890.stgit@tlendack-t1.amdoffice.net> <20170616185619.18967.38945.stgit@tlendack-t1.amdoffice.net> <20170623100013.upd4or6esjvulmvg@pd.tnic> <20170626154543.fsuxfhxidytgo2ia@pd.tnic> From: Tom Lendacky Message-ID: Date: Mon, 26 Jun 2017 11:34:49 -0500 MIME-Version: 1.0 In-Reply-To: <20170626154543.fsuxfhxidytgo2ia@pd.tnic> Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Borislav Petkov Cc: linux-efi@vger.kernel.org, Brijesh Singh , Toshimitsu Kani , linux-doc@vger.kernel.org, Matt Fleming , x86@kernel.org, linux-mm@kvack.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Alexander Potapenko , "H. Peter Anvin" , Larry Woodman , linux-arch@vger.kernel.org, kvm@vger.kernel.org, Jonathan Corbet , Joerg Roedel , "Michael S. Tsirkin" , kasan-dev@googlegroups.com, Ingo Molnar , Andrey Ryabinin , Dave Young , Rik van Riel , Arnd Bergmann , Konrad Rzeszutek Wilk , Andy Lutomirski , Boris Ostrovsky , Dmitry Vyukov , Juergen Gross , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, xen-devel@lists.xen.org, iommu@lists.linux-foundation.org, Thomas Gleixner , Paolo Bonzini On 6/26/2017 10:45 AM, Borislav Petkov wrote: > On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote: >> Normally the __p4d() macro would be used and that would be ok whether >> CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the >> paravirt ops path I have to use native_make_p4d(). > > So __p4d is in !CONFIG_PARAVIRT path. > > Regardless, we use the native_* variants in generic code to mean, not > paravirt. Just define it in a separate patch like the rest of the p4* > machinery and use it in your code. Sooner or later someone else will > need it. Ok, will do. > >> True, 5-level will only be turned on for specific hardware which is why >> I originally had this as only 4-level pagetables. But in a comment from >> you back on the v5 version you said it needed to support 5-level. I >> guess we should have discussed this more, > > AFAIR, I said something along the lines of "what about 5-level page > tables?" and whether we care. My bad, I took the meaning of that question the wrong way then. Thanks, Tom > >> but I also thought that should our hardware ever support 5-level >> paging in the future then this would be good to go. > > There it is :-) > >> The macros work great if you are not running identity mapped. You could >> use p*d_offset() to move easily through the tables, but those functions >> use __va() to generate table virtual addresses. I've seen where >> boot/compressed/pagetable.c #defines __va() to work with identity mapped >> pages but that would only work if I create a separate file just for this >> function. >> >> Given when this occurs it's very similar to what __startup_64() does in >> regards to the IS_ENABLED(CONFIG_X86_5LEVEL) checks. > > Ok. > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec