From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature Date: Thu, 16 Feb 2017 21:06:08 +0100 Message-ID: <20170216200608.xli5fybhh3mhlujw@pd.tnic> References: <20170216154158.19244.66630.stgit@tlendack-t1.amdoffice.net> <20170216154236.19244.7580.stgit@tlendack-t1.amdoffice.net> <20170216181355.bjxo2h6vlhukz4ih@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: 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 01:42:13PM -0600, Tom Lendacky wrote: > I realize it's a bit more code and expands the changes but I thought it > would be a bit clearer as to what was going on this way. And then the > follow on patch for the physical address reduction goes in nicely, too. Well, the code from the next patch should go to AMD-specific place like arch/x86/kernel/cpu/amd.c anyway, where you don't have to do vendor checks. > If you prefer I stay with the scattered feature approach and then clear > the bit based on the MSR at the end of init_amd() I can do that. I'm > not attached to either method. Yes please. We should keep the shole X86_FEATURE machinery from exploding in size. Especially if CPUID_0x8000001f is not a leaf we're going to be adding the majority of its bits, to warrant a separate ->x86_capability array element. [If it does later, we can always move it to a separate element. ] Thanks. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.