From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [RFC PATCH v4 08/28] x86: Extend the early_memremap support with additional attrs Date: Mon, 20 Feb 2017 16:43:54 +0100 Message-ID: <20170220154354.ggb7yzpjotmbrd5a@pd.tnic> References: <20170216154158.19244.66630.stgit@tlendack-t1.amdoffice.net> <20170216154348.19244.11884.stgit@tlendack-t1.amdoffice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170216154348.19244.11884.stgit-qCXWGYdRb2BnqfbPTmsdiZQ+2ll4COg0XqFh9Ls21Oc@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Tom Lendacky Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Brijesh Singh , Toshimitsu Kani , Radim =?utf-8?B?S3LEjW3DocWZ?= , Matt Fleming , x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, Alexander Potapenko , "H. Peter Anvin" , Larry Woodman , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jonathan Corbet , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Ingo Molnar , Andrey Ryabinin , Rik van Riel , Arnd Bergmann , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, "Michael S. Tsirkin" , Paolo Bonzini List-Id: linux-mm.kvack.org On Thu, Feb 16, 2017 at 09:43:48AM -0600, Tom Lendacky wrote: > Add to the early_memremap support to be able to specify encrypted and early_memremap() Please append "()" to function names in your commit messages text. > decrypted mappings with and without write-protection. The use of > write-protection is necessary when encrypting data "in place". The > write-protect attribute is considered cacheable for loads, but not > stores. This implies that the hardware will never give the core a > dirty line with this memtype. By "hardware will never give" you mean that WP writes won't land dirty in the cache but will go out to mem and when some other core needs them, they will have to come from memory? > Signed-off-by: Tom Lendacky > --- > arch/x86/Kconfig | 4 +++ > arch/x86/include/asm/fixmap.h | 13 ++++++++++ > arch/x86/include/asm/pgtable_types.h | 8 ++++++ > arch/x86/mm/ioremap.c | 44 ++++++++++++++++++++++++++++++++++ > include/asm-generic/early_ioremap.h | 2 ++ > mm/early_ioremap.c | 10 ++++++++ > 6 files changed, 81 insertions(+) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index a3b8c71..581eae4 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -1417,6 +1417,10 @@ config AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT > If set to N, then the encryption of system memory can be > activated with the mem_encrypt=on command line option. > > +config ARCH_USE_MEMREMAP_PROT > + def_bool y > + depends on AMD_MEM_ENCRYPT Why do we need this? IOW, all those helpers below will end up being defined unconditionally, in practice. Think distro kernels. Then saving the couple of bytes is not really worth the overhead. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.