From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752852AbdICCfE (ORCPT ); Sat, 2 Sep 2017 22:35:04 -0400 Received: from mail-bn3nam01on0047.outbound.protection.outlook.com ([104.47.33.47]:63095 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752816AbdICCfA (ORCPT ); Sat, 2 Sep 2017 22:35:00 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=brijesh.singh@amd.com; Cc: brijesh.singh@amd.com, Borislav Petkov , "linux-kernel@vger.kernel.org" , X86 ML , "linux-efi@vger.kernel.org" , linuxppc-dev , kvm list , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , 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: Andy Lutomirski 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> <8155b5b2-b2b3-bc8f-33ae-b81b661a2e38@amd.com> From: Brijesh Singh Message-ID: <870ff11e-2ba0-22ce-51d5-450124ae1111@amd.com> Date: Sat, 2 Sep 2017 21:34:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [70.112.153.56] X-ClientProxiedBy: DM5PR06CA0066.namprd06.prod.outlook.com (10.168.110.156) To SN1PR12MB0158.namprd12.prod.outlook.com (10.162.3.145) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bfbe000d-c6d4-4fb8-c1a2-08d4f2745bdc 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:SN1PR12MB0158; X-Microsoft-Exchange-Diagnostics: 1;SN1PR12MB0158;3:ZAHiTRYd+fFcA/OkZ5tR+V6hbrr+PXAC7FJJFfTmKePohT6KrmsYpas1B0fxXYZFOeW9p7zlumlz4+qWplqnGP0qubxG7xF3llH2FBLt3TjPnJgL2mFNHw30XvlkQwD8+/Pt5fh8vN1Sx/POuiO64VfDTr3ntnTgEO1yKmbiOb2cjyFyUgv8gbR/N0EtvDfcy8N6U8pYRr+GcWJ0gKJBk/lPhFs4DW60xueiXla1bC8KHSx3MgEd9egJ9NM8b6uN;25:lxRDTZf4OM8bb7HG9OjxujA20TfN9I/CWOipEacu8TQYVPofOlJVzWq9FuqrKaKrR3+MXhM+5xHFMj2fivfHWQ4WooyFjLlB1Bgk1xFHoD/vORayYLFbG+vI0n7m4dxfUmXkIf81F7vbeFGkehOTk5SByXWhzzBfkQyZp2kDwU3fcXVbKoMuQyT10hOGezUPiSQV4hFVXpV+B55NgGdwcC8I8YyP9dYImpOoj6Zndr5E6ILhZMKenuNcVYZvO/bwnXlQu/lWsGUdCmEY2mrgciaMK8EKFuBVT4WEMG4ETloqLLoFlIy0/YGjqE9U0hItBzNY3RCV3gAKALT/zcyCeQ==;31:o+OY1OqvNqBau3kN6AluzxHN0bhzlVjBbxC3HTAjadhP208xyxUQx+PoHPjuFRke1bsSpDN8ZPIuf6c7v2oA2qtym5AXgmLhwutSbZarPsD/9wLs/BxJzrbU+Ji6ky367E1vKdLpI5Uub1/pYmYYTAKfRR3afNL/WN03UKYNcfyco5GGex81wlk7QvrVyWD7OdnNpZCjoetJHz1pFbOxl71RPr5ZHXJY/PHqgFOSciw= X-MS-TrafficTypeDiagnostic: SN1PR12MB0158: X-Microsoft-Exchange-Diagnostics: 1;SN1PR12MB0158;20:3vQZlayUZGZSrV1d7hbfUc6QARMjJzFtxaYylLJBTb9dTpN5Tab0Bi1kn+Y/NHSKShaFXIUINAEgNTAb4Lc/FmT+p4uFomzK7BqaGS8f3/s7wJHtgb+mLmH+IFWqTqNkFqZ8pcOq+23ZsIJatUKBCh86rZiZZDyZGugmLRh+3JPh2Y0Tf3ylqotFkFan2DH7jLyH4IPUgPjZtkPmxPe5wgQqL1VV4jdukuyVYlxwz1gmxm3Q/c8b9WUtOsgxh+IFYYSLWZ5eg7d1r0RmgGZMVt+GmVQltuZ1ilTKR31nNEN3FeD1z7J28mNYO4XeQsgC8ldYdbastXjJfQtk+QF2sifnIPA6oRsA49hNOWcROPnBkA69ExlFmjtLHw933ewTq24qb/qlV10JNwtLVL8x0yK2MheoXGmZGue3iw4iIPu4pigwOVshyfcgBTF10dspqyrC3AYx7+UQcEVy8/0Hdbr+2xEd2aRXmAebkhs0nuApIXsapWNrTZA+v3fFkWUZ;4:bawbfKeUH8yCgpOjkcIseOJdIoY0JEfJgt9tcO73phrVgizmkdj2jmj6sA616Anr5t4ZZohOdROeFn8qCiFxxLoIJDW/uxCoE+QfoUe2kYpeIyxFGRA1W4FSfC4zILrrI9ANLFtB67gvVVOKD/j12YfWlYMPhg9/44/Z0FrVEIZZVFUFKxhgwMxQhER5Y13TtFra6TwMlY0D6mpuCens8xK+FriGlYgyz1wdGsnwaPjDIpbSpsiTNKoNId1+o1266xSsP4O2S3l7AOUdu8uYs/785tFCwf71fNiPNvqWzf0= X-Exchange-Antispam-Report-Test: UriScan:(767451399110); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:SN1PR12MB0158;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SN1PR12MB0158; X-Forefront-PRVS: 041963B986 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(377454003)(189002)(24454002)(199003)(51914003)(478600001)(65826007)(229853002)(6486002)(6506006)(6512007)(110136004)(6916009)(33646002)(6246003)(53936002)(31686004)(42186005)(2950100002)(7736002)(305945005)(5660300001)(3846002)(93886005)(53546010)(4001350100001)(97736004)(31696002)(8676002)(81156014)(81166006)(8936002)(83506001)(25786009)(86362001)(7406005)(7416002)(6116002)(68736007)(50986999)(4326008)(2906002)(106356001)(101416001)(189998001)(54356999)(105586002)(76176999)(65806001)(65956001)(66066001)(64126003)(50466002)(54906002)(23676002)(47776003)(36756003)(230700001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR12MB0158;H:Brijeshs-MacBook-Pro.local;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjEyTUIwMTU4OzIzOk95ZE02L1NSclh6bk9JYVN6cjV4dWwyVklE?= =?utf-8?B?SGVZREpPaHliU3l3MkZrelNVbk51L1lwTXR0b3k0NW1JamF3ampMYlhzU080?= =?utf-8?B?S2g4ZkhPRUh2dDAxK3BoY0YwRHNyNWUzZXN2bC9ZOEozSEtqUDFOT1BOMEVU?= =?utf-8?B?bC9LeVFOclM2VVIyNFNoenJTRzJQQTJlcFptSDlVYVNsb3o5SXd4aUVxUGVn?= =?utf-8?B?bnlMOTlmYWdOb041c2N6eVJ0WmVlS2hQZDhNdGNtZkpnQkVKUU1RVHFlZWtt?= =?utf-8?B?TjJMaFZHZmMrNlA2QlJCSjJMcm8rUGsyZ1dEQmw3MVo1MDg1WjBwc0ZyM1VS?= =?utf-8?B?ZVpjRk9EZ2NUZXVIV2JCaDRZNmZqMGlOWEF1TlJhMmM5MVpqb2UwN2pGMjY5?= =?utf-8?B?V1EwQS9WZ3YzQmxOVWFrTzFYR1pPWnJjcUFOUWZFOUlmaHM2QmMrRGh6eVRj?= =?utf-8?B?cVY1eEdQQ3BGVTVWZVVlMkI5dit0cHczT1BYdFdNZ1RsdzVrdXA5NjhuaG5R?= =?utf-8?B?S1gwbEVuSzFzZlQycnJBTEVkWlVpYUVaOFVMdXNQeGtxV3craWpnRGZLUGkv?= =?utf-8?B?elI1YzlIWkl4SVkwQlFuaFIxYzg5elRoa2xuRTE5TkdjVldnaTRWYzZFUXRD?= =?utf-8?B?NHZRbVE5Y1dZVXEyZnREQWZVWW1wOGdFWERleUZVZXdUeVBtSGEvSGNxc1E5?= =?utf-8?B?L0Y1OTNIRlBjSGRhNGhKQ0Y2Tm9aVGlqRVhGT3dsUG9NeGhCdWh6dXNhOVZY?= =?utf-8?B?MUptSForcW42d2cwTldIbXpaVGQ4TzBRRmNUa1J4aHkwZm5tcFBuVFN0VlBX?= =?utf-8?B?VkFVbFUzMzQ2YTRCVXEvWXJqSWU4c0c1SkdLYTNNbURoSTZ5OGowMERISFFk?= =?utf-8?B?QUE1d0V2Z2hmTGpTV1lKVzU0VkVIRmJzTlJyc2xUQ2h5NU5pSmNabGdDUXVx?= =?utf-8?B?MmsyaEk0SW9vSWNDbHU2Ym02cDduWmVTZHUvbkFGaWVPY05VZzFUN2l5ZHVU?= =?utf-8?B?M2xSTG85c215dlNPck5lSVU3MjZNQk45aWs5TTRseDN5MU02WDFlYzRkZEtW?= =?utf-8?B?cUJna2MwMTRHYmJYd1FrOGk1N210ejRkOGxKcDVMNk0xaVh3amQ2dnZXYm5x?= =?utf-8?B?Z3B4YzdaUHVHM0lWdTJjYWRGOEE0b2ZSR0tJaVpqWVRTVHpZaGVHTVl4V09S?= =?utf-8?B?TWNMVW9VQVl5MlRMd0xTSFd1enJDRHpxcGFPMFJXTGJRNjJxK3BSYkdPZFVE?= =?utf-8?B?dS9TNzMyME9TZG9jcTJEL2F2aldQbjZ5TytvQ2l0OWlkUS9lYk1xcHRqU25W?= =?utf-8?B?TEt2ZDl1MFFjMXVJVlMycmpLSnVDMGhYdmFMY0V4U3RZeW9NNmVCWEdtV3JD?= =?utf-8?B?VjVFalNEaHJkWWJHeU05RnhXU1NTUkwzTGZIa0VDWnFwK2h2SXJTWnpzOEc2?= =?utf-8?B?cnRkNDJMdXBXbko3aFo0TEY3VTVYdVJVMkN4RlV2dUVlWWNrQVcreCtPbkRC?= =?utf-8?B?eWpyazkydXNFdmtkZDJpVGY4SWZuVXB1aWpReFR4TjlLakFWTExCRnZkSFdi?= =?utf-8?B?dmJiQ0M1dXIrMkpQV3dPUHd6NHQyQ3FmdW56Wk5WM3YzRzJCcmFkbTB1Qm5F?= =?utf-8?B?SVBmcG5KT3NkMUprZU9OTXdKaCtUa0JQeEYyTzVaelJEV3kxV1hHZmVUa1l4?= =?utf-8?B?ODMxcEorSUtmU2pvOWw4WmxsakZRVlNNaG5EVGVDdnUzTjZGK2EyU3lON0xw?= =?utf-8?B?T1MyM0RZaFBDVTlob0xrTVZxcFFYOVMzOWoxc2NWaGRldU1PVXJ3bktVaEpH?= =?utf-8?B?RGwvcWFuY0VZSW94aVQrWlJ0UDFpbERCUmVrRmtMYndKNVI3enJhQ3FxVkxk?= =?utf-8?B?SDdqSCtSZHlXTmNhaWdQT1hzYTBNM3NiR25lYzZabGdORStmaWJWT1A1SEhG?= =?utf-8?B?TllTLzJpbXN3PT0=?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR12MB0158;6:W+FQorda+U841zC5pv0tDaUmVMpzNCI1uE4usRfS07VIa68BNjDQITOp1EhD0LDAyfHMJnZNZ03om3ZWFwh+dmnlclQ91EqhwEIqgIhBg44BYqm3dNKCY63aI1dy97c/NleRTA4wZi8r1g4REmOdGErbi2kN8L5tX2HYFWjtIA6IoO7naUDUjK5CwsrXitK1whGrZbGZF99HC+OWrkRp/VpZC9KscqbpW2eOSeqhHHBh8KI8TSCUvxHOnKwL3gFZ9mxZwhk3WHeGIU7Qp42jI9PrdH9h/gReQmobafHRmDojtIUDG4igUUCH/DAuMluQJhTYP8zdE9Yi4VUgftl4Bg==;5:JYS+pVcQChNTQTQrafiu9hS0LaimFvWwn8pcac69Uk8gb4arbaBcTMl9F380nrG0JsGo5LNgDlWWYap+WiSDJMPjN5p0dXTAvFY0eoi68qNLXaGatBM4B4d782ktpxl9JqPI64UPUTROZLFm7RBD1Q==;24:hVFgEEoosjNM0Dkri2BeA9wvMJKpwLLXvnvtabY0VLZOYpGWE6JsAXwIDRxaEbREr1aSTBFks555VwRnsIfC7dqBbM63tqBw6RTASc/LU9s=;7:HDyvB2HnDDXHGR1nBaBUMGtVyhLbCdmUkpi3jC7ZE8GWPIoSLfgQ2/HQNZF9SHdPdfBq86ag8V8HKT3o9VMxKBz96Rh2LwUYvSlmnZuEbUXABcKCzT22jEqP4VjGLO49s2ylE516B4OXETwV8G/7M4+EDGuOtf8Vo6YU21hF1lXhsyEZ9Dz1ckWUqD973U6gQ6x+PMIov+Qlda47ZF2mloN+p4zJ960na75/Yei4WPo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;SN1PR12MB0158;20:+tXq9yRERUJwSbSDpOlR2BlAlqZHEcc22wAIBeKpWx5xbXozUDI54ioizvmY7+8Wc7P6zH46ravV2TBgxhQf5kFZ3JV3qREwYlWP/fcLWAqCgSznsr8RRk835sYdLnQdPzfpvIopWbaiUH7Mndk0P15XubH9CIVzpLFZuMZDG7CAwHHbNEifZ2JKUTyDEU0JP6W6pl/Z3/Yb/2WLuibpK+/VELe4BRczuLi5Al/mm+NUfoKMPOVngfW7oVaZWL+M X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Sep 2017 02:34:50.8811 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB0158 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/1/17 10:21 PM, Andy Lutomirski wrote: > On Fri, Sep 1, 2017 at 3:52 PM, Brijesh Singh wrote: >> 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 > Shouldn't this be called DEFINE_PER_CPU_UNENCRYPTED? ISTM the "HV > shared" bit is incidental. Thanks for the suggestion, we could call it DEFINE_PER_CPU_UNENCRYPTED. I will use it in next rev. -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: Sat, 2 Sep 2017 21:34:48 -0500 Message-ID: <870ff11e-2ba0-22ce-51d5-450124ae1111@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> <8155b5b2-b2b3-bc8f-33ae-b81b661a2e38@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski Cc: brijesh.singh-5C7GfCeVMHo@public.gmane.org, Borislav Petkov , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , X86 ML , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linuxppc-dev , kvm list , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Tony Luck , Piotr Luc , Tom Lendacky , Fenghua Yu , Lu Baolu , Reza Arbab , David Howells , Matt Fleming , "Kirill A . Shutemov" , Laura Abbott List-Id: linux-efi@vger.kernel.org On 9/1/17 10:21 PM, Andy Lutomirski wrote: > On Fri, Sep 1, 2017 at 3:52 PM, Brijesh Singh wrote: >> 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 > Shouldn't this be called DEFINE_PER_CPU_UNENCRYPTED? ISTM the "HV > shared" bit is incidental. Thanks for the suggestion, we could call it DEFINE_PER_CPU_UNENCRYPTED. I will use it in next rev. -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: Sat, 2 Sep 2017 21:34:48 -0500 Message-ID: <870ff11e-2ba0-22ce-51d5-450124ae1111@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> <8155b5b2-b2b3-bc8f-33ae-b81b661a2e38@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: brijesh.singh-5C7GfCeVMHo@public.gmane.org, Borislav Petkov , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , X86 ML , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linuxppc-dev , kvm list , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Tony Luck , Piotr Luc , Tom Lendacky , Fenghua Yu , Lu Baolu , Reza Arbab , David Howells , Matt Fleming , "Kirill A . Shutemov" , Laura Abbott Return-path: In-Reply-To: Content-Language: en-US Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org On 9/1/17 10:21 PM, Andy Lutomirski wrote: > On Fri, Sep 1, 2017 at 3:52 PM, Brijesh Singh wrote: >> 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 > Shouldn't this be called DEFINE_PER_CPU_UNENCRYPTED? ISTM the "HV > shared" bit is incidental. Thanks for the suggestion, we could call it DEFINE_PER_CPU_UNENCRYPTED. I will use it in next rev. -Brijesh