From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752649AbdIAWwY (ORCPT ); Fri, 1 Sep 2017 18:52:24 -0400 Received: from mail-bn3nam01on0079.outbound.protection.outlook.com ([104.47.33.79]:19767 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752563AbdIAWwV (ORCPT ); Fri, 1 Sep 2017 18:52:21 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=brijesh.singh@amd.com; Cc: brijesh.singh@amd.com, linux-kernel@vger.kernel.org, x86@kernel.org, linux-efi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , Tony Luck , Piotr Luc , Tom Lendacky , Fenghua Yu , Lu Baolu , Reza Arbab , David Howells , Matt Fleming , "Kirill A . Shutemov" , Laura Abbott , Ard Biesheuvel , Andrew Morton , Eric Biederman , Benjamin Herrenschmidt , Paul Mackerras , Konrad Rzeszutek Wilk , Jonathan Corbet , Dave Airlie , Kees Cook , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Tejun Heo , Christoph Lameter Subject: Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables To: Borislav Petkov References: <20170724190757.11278-1-brijesh.singh@amd.com> <20170724190757.11278-17-brijesh.singh@amd.com> <20170829102258.gxk227js4yw47qi3@pd.tnic> <0810a732-9c77-a543-ffeb-7fd2d8f46266@amd.com> <20170830174655.ehrnmynotmp7laka@pd.tnic> From: Brijesh Singh Message-ID: <8155b5b2-b2b3-bc8f-33ae-b81b661a2e38@amd.com> Date: Fri, 1 Sep 2017 17:52:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170830174655.ehrnmynotmp7laka@pd.tnic> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: DM3PR12CA0083.namprd12.prod.outlook.com (2603:10b6:0:57::27) To DM2PR12MB0155.namprd12.prod.outlook.com (2a01:111:e400:50ce::18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ffd2bd8e-50a5-41dd-671b-08d4f18c1864 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DM2PR12MB0155; X-Microsoft-Exchange-Diagnostics: 1;DM2PR12MB0155;3:lK8acYPyhRuhTj5P5DFLzfzLmtnibWWH/YzppKl6iRov24nc6uZxGmn/uAXzuRU8EkgveLVY7JLNaOUXiH/shmMFrF+chPfpx+HLHUalNSBypTi55/f/j/uEsLXwKFaDembW8L/pUa0QKDlo0uS5v8MJYVXjX6+U+bigUo5RHohQCFLgGzT2Y2UH9n4KjmwdnRAe5uq/Xv7Zske7Mt7UH3olTj0jbaUeVNDvRu1Mpx9P5D0A9n2TXKS7TVjlyQg+;25:Z/d2rLki+EE0JQ2aD2DWfdboZeKTshi6zz1iGehvarFD3eij1kT47JhOm6d6JKVonrS5thsUGFYqa5Qdsjp3nSuNadVnx4HtzP5+Z3inT7e7zGvU2cufbuCcufghcu6ZxM/Tc/xWOTA1UHl4oipjIpQPHIRV8g3FusXa9or/5zUQT9mzCAdvKQ3aLLOT8cOGDrS6GZFBKcwqlTX+DrrxFYV3T+xGu3eh95iCorJsbHD1T70wk+u/SFGmWD4Li6VlFuVEWFP3vtD0gtDHXsKuahPF3+vkg5Ez6KlSQfjhcCkiB+GuFbie6DqKsSJ6DC+1dgu363FEVU1Wz+5NXHa3ng==;31:jSmXpPiXDaRyCAVtFgCtX7zUwH7h+hIgr7gG5xP+oUpqeC/A0q2KhHXTIDAjUDZWzBW04Sj96Z6XlcUxafU8kM/WGznWP/3Z4RGieftL49tky2A8Bnrk50a+8r3dQoO8cn0kY6pedaQcbco5LjDBN907K0/uKraq8D+tO2vOFTJvwbofBalE6m0KZAwaXimNK3lvzfOMwEA9yGzYivcseZvD5YyaFHtQww9/0X49FV8= X-MS-TrafficTypeDiagnostic: DM2PR12MB0155: X-Microsoft-Exchange-Diagnostics: 1;DM2PR12MB0155;20:j254hFHemGMyc+chweWTWh4LGNzFwq/PS2vDSiLMemSUEnFnad2dRYonbOoJB/jShosn/RIYHss+jdeWLyYyju+Wc8MTv4jWFIv6zQuklnwFOKCu3ZxYhDnOh5X6WBE8nOvvUi35H1Fn6JfRpq1aEhwv3VrBAxA1q6M+alxod0JxsEjG9PK+DYEwOt0+WbdI7cEhe8mS1ihJnkOGfsukkcT2cauh1e+DZBi/e5kX9cL2SmbixYnNJmBrh/1hSm9WXhAkWMfa6A90f1k5eX0EoY6V9totEOHCKf7WkfPxJmYvp9zNUY/fbtYZbuJDS+qpcF4v4IFmzoqLBSz1/g5Fcu0Ri2/CYZOgOySb+xHjU99KI1aaa7ymW6gFYE8n9KwnswnEOmY9ZoOO/6ehMCn3irNfdHK2wDo1LvyIDEsyW3ANctZFQbHrofKBMJw3x7/2lz7fQLUcVpC9wG3228m6gmppPhQzhy6TltJ0Xn/2bAk4tu4v8m4cKusyUOd0hr6M;4:MHmbUzcpCe/9j535uq2vc6hfoMts+RV+Hgu/sbFgvz/iFQjApgYLEcP72CkzafPK1i2ehTAZ1IIF7uplkrbAh9QjDcXQOaHY0MWGUbfBJJljQjgxcVZTV49t4iYJbJSVQmVFghwMdXXknZJPpUi7wpEJDA7h0fakErDOABj8dR4TN7HfHsSfXD48aLl0oAN8lt4y8g3I30nh7uPSlKemFzgVopEUvYy+olTDKByzpCyA0rC6/qw/cHzdWqey0XY7 X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DM2PR12MB0155;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DM2PR12MB0155; X-Forefront-PRVS: 0417A3FFD2 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(39860400002)(199003)(24454002)(189002)(377454003)(31686004)(6916009)(2950100002)(6666003)(33646002)(54906002)(189998001)(65826007)(2906002)(53546010)(76176999)(83506001)(86362001)(4326008)(305945005)(93886005)(50986999)(25786009)(478600001)(54356999)(101416001)(68736007)(7736002)(6486002)(77096006)(42186005)(50466002)(31696002)(106356001)(110136004)(53936002)(230700001)(7406005)(23676002)(7416002)(105586002)(6246003)(5660300001)(6116002)(47776003)(66066001)(65806001)(65956001)(64126003)(8936002)(36756003)(97736004)(3846002)(229853002)(81156014)(8676002)(4001350100001)(81166006);DIR:OUT;SFP:1101;SCL:1;SRVR:DM2PR12MB0155;H:[10.236.136.62];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTJQUjEyTUIwMTU1OzIzOm8yN2owZVIzREhMZUQ1dDhqUnA4KzJzYm1r?= =?utf-8?B?OW1NamY3eVl4a1d5NDhxRXZRQVoycVdPN2NEdGJBNWVLQXJIWFpQTWloVENB?= =?utf-8?B?RVFmQ25jTklFLysyd0E4TWdNWU5pVzlJQ29Zb1NkS2dab0p6WnIxS3VOU3J0?= =?utf-8?B?b2JMQi8xU2ZzdTYvVFlwRUc4Qzk1bVYrZ1BOeHAxWnZBZ2grR3pzbXJsbmVT?= =?utf-8?B?QjlpaEk5YXd5VkJnZnd4NmpwZkNCSGg5KzEvNFNGVXdQQzRMeXAyWEMxZFB2?= =?utf-8?B?S2Y0WGxzM1Qzb2VySlVsS0tyR2NLY1VQcjNrdkZJMTNoQ1paS0xZZUVvSUM5?= =?utf-8?B?NnZEZHUwbUxRc0htVnlPcXlmUnVUODVOTlAvRHF3clJYYkVnYjZBOE1kRFE4?= =?utf-8?B?STRXSlZhZXhFRjY0YnFIam5nbGg0U1l2a3BHblVGdDZHUGlUOVVLTG1BQnN1?= =?utf-8?B?bUtOYmtzeUxjRDVhOXdMdEtGUzQwbmtHZ0JZV0ZoaWM0ejFqWXBQTldXVHV6?= =?utf-8?B?NEIzUTV1dEswR05JY0dMOG15Uy84QytnakVUQm1lY0ZBbGdpV3hnUTJsVjNV?= =?utf-8?B?dWVJN3NzNDMrR0dsZ1BDeHJWWUc1SXkwSk81WC9aRmk0blhHcUExSW1PZkJD?= =?utf-8?B?My8yaExJY1ZSWEE3cjFuWjYrd24va2lZUWtQdkcwemc0NlA0Rkg1WWtTMzZG?= =?utf-8?B?L3Nkb1FjbjVVbHRsYzJSeUtPbHRiWGNKdEhYV0E1eWVpMTNqRWYwQmx4c1NI?= =?utf-8?B?QjJvNkM3YTM4Wi9VU2JCYThYZDlieWwzWFpjbTJPSTcvMlB6WDlSN2ppQ0Jz?= =?utf-8?B?ckU2OGVsMkMvbEFUR0tOaEdmTVlpdXJ6cVpSTUVZS2NObFRQc3NEZlZwQndJ?= =?utf-8?B?dnJRK3lhSkFGK1FlbUR2NC9WWW5HOHYzcS9peGJuamd3KzExU1plbnF1QlVm?= =?utf-8?B?aVlycEUxS3FacXA4YXUwQUp0Zm95UWpSUjVoVWFJTUF5UkxWWlErWXVzTHFD?= =?utf-8?B?c3Z2Z0NhNEJ1UkV6clo2Q0RLM2lUSDhKTCtSdlUwR0dnejcwUEd5cm9NWk9S?= =?utf-8?B?VTdHUm1YWkNPYVlOemFZcjZDN2RxcHhic3pZdVJUM3dPNi81MHZMZU9kSUtJ?= =?utf-8?B?YXNKWFZLTVBEeWs2RlMrR2JzNUMvN1YzQnU5T0JvRGp6QVJCS3VNN3RaYnd4?= =?utf-8?B?TG90TUQyMEtOMkdqS2VTSGswY0o2ODArYjBRN3ErRHQrQVZGQ2hnVjMvMWcx?= =?utf-8?B?Z1I4SzMwR0Y3T1JyV1dlVExkL1gwRk9uMkVVaG83SjFUM0tzcFJNNU5SVkVr?= =?utf-8?B?S1pjTldBc29oRnhFRzRZWjBLa0xUOWVmNlo0dFp2TUF3T1p4eGwvQXJrMDVw?= =?utf-8?B?YnJuYndvdHhIR0FKclM1OEg2blIxTDdFODZZWi9UU0daaklFaS9ZNnQwYUI0?= =?utf-8?B?VXRDblBTWkRWMkJXUGtKK1RIUFBybERva3JTa2pyU0hEbDZQU1o1ZmJlN0Z1?= =?utf-8?B?emhBNjd4U3FmalhzVEtFTTc2KzVFWVpqemhzaVlNem9saEJ6RGdUN2N4dUhC?= =?utf-8?B?dHdCT1Yyb3VQZGdTWDdrY05OSVYrYURXMWhQckNhTURpY0cwS3NZWWc0U2NY?= =?utf-8?B?aTN6R29EYzE4aXZxUlBYbDdRWEtQWTZZd2c5WXlURlhlVEE4czd6Tk5nY1l2?= =?utf-8?B?dWQyS2VhVnB6Uk1keWV3enNYK3E2b09PT2t4RUszUEFPdkNPR3JJekhRTTRX?= =?utf-8?B?Y20zdUdNYS9tM29aMUUyN2hoSjFNK0VPYmZ4QWZkb1Z4dzNTUDh6SVFyZHdj?= =?utf-8?B?c1l5YmpCY0NnSHo0Zy9UL3NsdStoaTM0RklQQ3RmZkZLZ1J3WWZqOEpBblhV?= =?utf-8?B?N1BOeUhDZkEzSlcvYU1VOVNuazdGUlZ4bzJBUnladnp2KzE1OVpwbWJGV1hh?= =?utf-8?B?WEt1QnJ3YmtBPT0=?= X-Microsoft-Exchange-Diagnostics: 1;DM2PR12MB0155;6:FSTv30/I7dQ267Mhccmtv3umF2qGXfbYZT087cCb6tvVnmneuP5a5aqjaGMmuJBlzII+mnVdha4G1akGmksXV2zoeF3FHuLuDa0KF46je/8Rt8UWNbyJD3Xl/M/NSLBOwSv4768djQjyhSXNix4CCxCXnINczzan2TUeoPyt1bZ1TMnzY1aouIJYnw+6ED54n5z27Oe0rnE1lesg9+JrncQ++vnlijK6+hzr4IMcfPqt5JOGVJEmDuPHv8VGjOJdrKsjwGHe3qbAXQS2PBWgi4aorq87UbovcYVNGAc2yispQoHdP2APb6zk3d2+tFcokQ7MoQkawbu3LUjdj4317Q==;5:xvQUBmJA8DxgmUMPRjrq0dY7ywEscfWru0Hn4XNdDmaAyRa8Vip2/+y+/dRfdNmFAJlGPcgP/aGdc0E+P/HMdqmvvkuEa7c1+6yxvq5KtrPn61fCvWj6VfbImJ4tDCfHpMXNyR6Vg9l+zpbxiGT4oA==;24:0UYD1An/4A1TAcg3263O1pnlZqgfcRmvRuT17DXA3jdcFuuFduVxjSVW8izmDibmIdnPrkJbq3XdFo8Eg4iiSG2oLucr8Mwvz6AQ+jUJKns=;7:/0/aNrcOOh+uMklZMHCBpjKtpaI+Oche1iRBAV6aLScliC2moSThxM4Z5z1swVsws0i97tkrva+KLBPch0VC0CQ59Hg+aXuoMBDkDl5o7fC31xe+wA4hj4IUusDv30RxsnS30EzLqczfkxqj4fF85Zh9/gHCyWh7eGeRhyI4aw4H0jb1uyJEA7iwtqY1xr7YsDOmE3q6wR8TV0sOuut8gv28Vi+s4EkuA6L5JRQWJ+Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM2PR12MB0155;20:D7engVtsmi+8sz9UAmx6w/i/uRvsKbom0k2Ot7QUMyvxpgfvl+P1gdtpQvfDOz4m2Yykz/q/Vj9l/TjBEhcnyL/T+hVfawwHQwN133/p6hRN+hB/VBThiR9BzxaPZoCzFRKkhpfnT9+euYwSpX1rYPOmZAuNazMKdgSYu7xY2yOmmVaCnMm9Zymi9+y8ec0BRXtPnzvZWj2erHKSyoGAGRgcboygf8lpbYJMAYSJZIdWHdmfDCjh3ii+epq8qr5i X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Sep 2017 22:52:16.2095 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR12MB0155 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Boris, On 08/30/2017 12:46 PM, Borislav Petkov wrote: > On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: >> I was trying to avoid mixing early and no-early set_memory_decrypted() but if >> feedback is: use early_set_memory_decrypted() only if its required otherwise >> use set_memory_decrypted() then I can improve the logic in next rev. thanks > > Yes, I think you should use the early versions when you're, well, > *early* :-) But get rid of that for_each_possible_cpu() and do it only > on the current CPU, as this is a per-CPU path anyway. If you need to > do it on *every* CPU and very early, then you need a separate function > which is called in kvm_smp_prepare_boot_cpu() as there you're pre-SMP. > I am trying to implement your feedback and now remember why I choose to use early_set_memory_decrypted() and for_each_possible_cpu loop. These percpu variables are static. Hence before clearing the C-bit we must perform the in-place decryption so that original assignment is preserved after we change the C-bit. Tom's SME patch [1] added sme_early_decrypt() -- which can be used to perform the in-place decryption but we do not have similar routine for non-early cases. In order to address your feedback, we have to add similar functions. So far, we have not seen the need for having such functions except this cases. The approach we have right now works just fine and not sure if its worth adding new functions. Thoughts ? [1] Commit :7f8b7e7 x86/mm: Add support for early encryption/decryption of memory -Brijesh From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brijesh Singh Subject: Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables Date: Fri, 1 Sep 2017 17:52:13 -0500 Message-ID: <8155b5b2-b2b3-bc8f-33ae-b81b661a2e38@amd.com> References: <20170724190757.11278-1-brijesh.singh@amd.com> <20170724190757.11278-17-brijesh.singh@amd.com> <20170829102258.gxk227js4yw47qi3@pd.tnic> <0810a732-9c77-a543-ffeb-7fd2d8f46266@amd.com> <20170830174655.ehrnmynotmp7laka@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170830174655.ehrnmynotmp7laka@pd.tnic> Content-Language: en-US Sender: kvm-owner@vger.kernel.org To: Borislav Petkov Cc: brijesh.singh@amd.com, linux-kernel@vger.kernel.org, x86@kernel.org, linux-efi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , Tony Luck , Piotr Luc , Tom Lendacky , Fenghua Yu , Lu Baolu , Reza Arbab , David Howells , Matt Fleming , "Kirill A . Shutemov" , Laura Abbott , Ard Biesheuvel , Andrew Morton List-Id: linux-efi@vger.kernel.org Hi Boris, On 08/30/2017 12:46 PM, Borislav Petkov wrote: > On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: >> I was trying to avoid mixing early and no-early set_memory_decrypted() but if >> feedback is: use early_set_memory_decrypted() only if its required otherwise >> use set_memory_decrypted() then I can improve the logic in next rev. thanks > > Yes, I think you should use the early versions when you're, well, > *early* :-) But get rid of that for_each_possible_cpu() and do it only > on the current CPU, as this is a per-CPU path anyway. If you need to > do it on *every* CPU and very early, then you need a separate function > which is called in kvm_smp_prepare_boot_cpu() as there you're pre-SMP. > I am trying to implement your feedback and now remember why I choose to use early_set_memory_decrypted() and for_each_possible_cpu loop. These percpu variables are static. Hence before clearing the C-bit we must perform the in-place decryption so that original assignment is preserved after we change the C-bit. Tom's SME patch [1] added sme_early_decrypt() -- which can be used to perform the in-place decryption but we do not have similar routine for non-early cases. In order to address your feedback, we have to add similar functions. So far, we have not seen the need for having such functions except this cases. The approach we have right now works just fine and not sure if its worth adding new functions. Thoughts ? [1] Commit :7f8b7e7 x86/mm: Add support for early encryption/decryption of memory -Brijesh From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brijesh Singh Subject: Re: [RFC Part1 PATCH v3 16/17] X86/KVM: Provide support to create Guest and HV shared per-CPU variables Date: Fri, 1 Sep 2017 17:52:13 -0500 Message-ID: <8155b5b2-b2b3-bc8f-33ae-b81b661a2e38@amd.com> References: <20170724190757.11278-1-brijesh.singh@amd.com> <20170724190757.11278-17-brijesh.singh@amd.com> <20170829102258.gxk227js4yw47qi3@pd.tnic> <0810a732-9c77-a543-ffeb-7fd2d8f46266@amd.com> <20170830174655.ehrnmynotmp7laka@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: brijesh.singh@amd.com, linux-kernel@vger.kernel.org, x86@kernel.org, linux-efi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andy Lutomirski , Tony Luck , Piotr Luc , Tom Lendacky , Fenghua Yu , Lu Baolu , Reza Arbab , David Howells , Matt Fleming , "Kirill A . Shutemov" , Laura Abbott , Ard Biesheuvel , Andrew Morton Return-path: Received: from mail-bn3nam01on0079.outbound.protection.outlook.com ([104.47.33.79]:19767 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752563AbdIAWwV (ORCPT ); Fri, 1 Sep 2017 18:52:21 -0400 In-Reply-To: <20170830174655.ehrnmynotmp7laka@pd.tnic> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: Hi Boris, On 08/30/2017 12:46 PM, Borislav Petkov wrote: > On Wed, Aug 30, 2017 at 11:18:42AM -0500, Brijesh Singh wrote: >> I was trying to avoid mixing early and no-early set_memory_decrypted() but if >> feedback is: use early_set_memory_decrypted() only if its required otherwise >> use set_memory_decrypted() then I can improve the logic in next rev. thanks > > Yes, I think you should use the early versions when you're, well, > *early* :-) But get rid of that for_each_possible_cpu() and do it only > on the current CPU, as this is a per-CPU path anyway. If you need to > do it on *every* CPU and very early, then you need a separate function > which is called in kvm_smp_prepare_boot_cpu() as there you're pre-SMP. > I am trying to implement your feedback and now remember why I choose to use early_set_memory_decrypted() and for_each_possible_cpu loop. These percpu variables are static. Hence before clearing the C-bit we must perform the in-place decryption so that original assignment is preserved after we change the C-bit. Tom's SME patch [1] added sme_early_decrypt() -- which can be used to perform the in-place decryption but we do not have similar routine for non-early cases. In order to address your feedback, we have to add similar functions. So far, we have not seen the need for having such functions except this cases. The approach we have right now works just fine and not sure if its worth adding new functions. Thoughts ? [1] Commit :7f8b7e7 x86/mm: Add support for early encryption/decryption of memory -Brijesh