From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME Date: Tue, 15 Nov 2016 08:32:50 -0600 Message-ID: References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003513.3280.12104.stgit@tlendack-t1.amdoffice.net> <20161115121035.GD24857@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20161115121035.GD24857-zLv9SwRftAIdnm+yROfE0A@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: Joerg Roedel Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , 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, Jonathan Corbet , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Ingo Molnar , Andrey Ryabinin , Rik van Riel , Arnd Bergmann , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Paolo Bonzini List-Id: linux-efi@vger.kernel.org On 11/15/2016 6:10 AM, Joerg Roedel wrote: > On Wed, Nov 09, 2016 at 06:35:13PM -0600, Tom Lendacky wrote: >> +/* >> + * AMD Secure Memory Encryption (SME) can reduce the size of the physical >> + * address space if it is enabled, even if memory encryption is not active. >> + * Adjust x86_phys_bits if SME is enabled. >> + */ >> +static void phys_bits_adjust(struct cpuinfo_x86 *c) >> +{ > > Better call this function amd_sme_phys_bits_adjust(). This name makes it > clear at the call-site why it is there and what it does. Will do. > >> + u32 eax, ebx, ecx, edx; >> + u64 msr; >> + >> + if (c->x86_vendor != X86_VENDOR_AMD) >> + return; >> + >> + if (c->extended_cpuid_level < 0x8000001f) >> + return; >> + >> + /* Check for SME feature */ >> + cpuid(0x8000001f, &eax, &ebx, &ecx, &edx); >> + if (!(eax & 0x01)) >> + return; > > Maybe add a comment here why you can't use cpu_has (yet). > Ok, will do. Thanks, Tom