From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753336AbcKUI2D (ORCPT ); Mon, 21 Nov 2016 03:28:03 -0500 Received: from mail.skyhub.de ([78.46.96.112]:37427 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752072AbcKUI2A (ORCPT ); Mon, 21 Nov 2016 03:28:00 -0500 Date: Mon, 21 Nov 2016 09:27:54 +0100 From: Borislav Petkov To: Tom Lendacky Cc: linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, iommu@lists.linux-foundation.org, Rik van Riel , Radim =?utf-8?B?S3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Larry Woodman , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov Subject: Re: [RFC PATCH v3 11/20] x86: Add support for changing memory encryption attribute Message-ID: <20161121082754.at6lhjhekbzjgyhc@pd.tnic> References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003655.3280.57333.stgit@tlendack-t1.amdoffice.net> <20161117173945.gnar3arpyeeh5xm2@pd.tnic> <6f1a16e4-5a84-20c0-4bd3-3be5ed933800@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6f1a16e4-5a84-20c0-4bd3-3be5ed933800@amd.com> User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 19, 2016 at 12:48:27PM -0600, Tom Lendacky wrote: > Should I move this functionality into the sme_set_mem_* functions or > remove the sme_set_mem_* functions and use the set_memory_* functions > directly. The latter means calculating the number of pages, but makes > it clear that this works on a page level while the former keeps > everything the mem_encrypt.c file (and I can change that to take in a > page count so that it is clear about the page boundary usage). A user of that interface doesn't care, right? All she wants to do is pass in an address and size and the code will figure out everything. And I think address and size is the simplest two args you can pass. numpages can be calculated from it. As you do in sme_set_mem_*. And you need to do it all in pageattr.c because it uses the cpa wankery in there so you probably want to define int set_memory_dec(unsigned long addr, size_t size) int set_memory_enc(unsigned long addr, size_t size) there which both simply call __set_memory_enc_dec(unsigned long addr, size_t size, bool enc) and it goes and figures out everything, builds the cpa_data and does the mapping. That looks very simple and clean to me. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [RFC PATCH v3 11/20] x86: Add support for changing memory encryption attribute Date: Mon, 21 Nov 2016 09:27:54 +0100 Message-ID: <20161121082754.at6lhjhekbzjgyhc@pd.tnic> References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003655.3280.57333.stgit@tlendack-t1.amdoffice.net> <20161117173945.gnar3arpyeeh5xm2@pd.tnic> <6f1a16e4-5a84-20c0-4bd3-3be5ed933800@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <6f1a16e4-5a84-20c0-4bd3-3be5ed933800-5C7GfCeVMHo@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, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 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, 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, Paolo Bonzini List-Id: linux-efi@vger.kernel.org On Sat, Nov 19, 2016 at 12:48:27PM -0600, Tom Lendacky wrote: > Should I move this functionality into the sme_set_mem_* functions or > remove the sme_set_mem_* functions and use the set_memory_* functions > directly. The latter means calculating the number of pages, but makes > it clear that this works on a page level while the former keeps > everything the mem_encrypt.c file (and I can change that to take in a > page count so that it is clear about the page boundary usage). A user of that interface doesn't care, right? All she wants to do is pass in an address and size and the code will figure out everything. And I think address and size is the simplest two args you can pass. numpages can be calculated from it. As you do in sme_set_mem_*. And you need to do it all in pageattr.c because it uses the cpa wankery in there so you probably want to define int set_memory_dec(unsigned long addr, size_t size) int set_memory_enc(unsigned long addr, size_t size) there which both simply call __set_memory_enc_dec(unsigned long addr, size_t size, bool enc) and it goes and figures out everything, builds the cpa_data and does the mapping. That looks very simple and clean to me. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.