From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.161.199]) by kanga.kvack.org (Postfix) with ESMTP id BAD3E6B0260 for ; Wed, 31 Aug 2016 11:09:27 -0400 (EDT) Received: by mail-yw0-f199.google.com with SMTP id i184so105038758ywb.1 for ; Wed, 31 Aug 2016 08:09:27 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0049.outbound.protection.outlook.com. [104.47.40.49]) by mx.google.com with ESMTPS id n187si17782554oif.79.2016.08.31.06.26.15 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 06:26:16 -0700 (PDT) Subject: Re: [RFC PATCH v2 04/20] x86: Secure Memory Encryption (SME) support References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223610.29880.21739.stgit@tlendack-t1.amdoffice.net> From: Tom Lendacky Message-ID: <386eadac-b6eb-747e-65e7-1ffa4cfd7210@amd.com> Date: Wed, 31 Aug 2016 08:26:01 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski Cc: kasan-dev , "linux-efi@vger.kernel.org" , linux-arch , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , iommu@lists.linux-foundation.org, "linux-doc@vger.kernel.org" , Jonathan Corbet , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Konrad Rzeszutek Wilk , "linux-mm@kvack.org" , Matt Fleming , Alexander Potapenko , "linux-kernel@vger.kernel.org" , Dmitry Vyukov , Arnd Bergmann , Joerg Roedel , Andrey Ryabinin , "H. Peter Anvin" , X86 ML , kvm list On 08/30/2016 09:57 AM, Andy Lutomirski wrote: > On Aug 30, 2016 6:34 AM, "Tom Lendacky" wrote: >> >> On 08/25/2016 08:04 AM, Thomas Gleixner wrote: >>> On Mon, 22 Aug 2016, Tom Lendacky wrote: >>> >>>> Provide support for Secure Memory Encryption (SME). This initial support >>>> defines the memory encryption mask as a variable for quick access and an >>>> accessor for retrieving the number of physical addressing bits lost if >>>> SME is enabled. >>> >>> What is the reason that this needs to live in assembly code? >> >> In later patches this code is expanded and deals with a lot of page >> table manipulation, cpuid/rdmsr instructions, etc. and so I thought it >> was best to do it this way. > > None of that sounds like it needs to be in asm, though. > > I, at least, have a strong preference for minimizing the amount of asm > in the low-level arch code. I can take a look at converting it over to C code. Thanks, Tom > > --Andy > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org