From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bl2nam02on0082.outbound.protection.outlook.com ([104.47.38.82]:36496 "EHLO NAM02-BL2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727484AbeH2TbA (ORCPT ); Wed, 29 Aug 2018 15:31:00 -0400 Cc: brijesh.singh@amd.com, x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org, Tom Lendacky , Thomas Gleixner , Borislav Petkov , "H. Peter Anvin" , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Subject: Re: [PATCH v2 2/3] x86/mm: add .data..decrypted section to hold shared variables To: Sean Christopherson References: <1535494377-25600-1-git-send-email-brijesh.singh@amd.com> <1535494377-25600-3-git-send-email-brijesh.singh@amd.com> <20180829150314.GA32493@linux.intel.com> From: Brijesh Singh Message-ID: <0de361d4-1d1e-0584-f9d4-41bf5936e2be@amd.com> Date: Wed, 29 Aug 2018 10:33:24 -0500 MIME-Version: 1.0 In-Reply-To: <20180829150314.GA32493@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 08/29/2018 10:03 AM, Sean Christopherson wrote: > On Tue, Aug 28, 2018 at 05:12:56PM -0500, Brijesh Singh wrote: >> kvmclock defines few static variables which are shared with hypervisor >> during the kvmclock initialization. >> >> When SEV is active, memory is encrypted with a guest-specific key, and >> if guest OS wants to share the memory region with hypervisor then it must >> clear the C-bit before sharing it. Currently, we use >> kernel_physical_mapping_init() to split large pages before clearing the >> C-bit on shared pages. But the kernel_physical_mapping_init fails when >> called from the kvmclock initialization (mainly because memblock allocator >> was not ready). >> >> The '__decrypted' can be used to define a shared variable; the variables >> will be put in the .data.decryption section. This section is mapped with >> C=0 early in the boot, we also ensure that the initialized values are >> updated to match with C=0 (i.e perform an in-place decryption). The >> .data..decrypted section is PMD aligned and sized so that we avoid the >> need to split the large pages when mapping this section. > > What about naming the attribute (and section) '__unencrypted' instead > of '__decrypted'? The attribute should be a property describing how > the data must be accessed, it shouldn't imply anything regarding the > history of the data. Decrypted implies that data was once encrypted, > whereas unencrypted simply states that the data is stored in plain > text. All data that has been decrypted is also unencrypted, but the > reverse does not hold true. > During the initial SEV/SME patch review cycle we had some discussion about using decrypted vs unencrypted. At that time the consensus was that a memory range mapped with C=0 should be referred as 'decrypted'. Having said so, I do see your point and I am not oppose to calling it 'unencrypted' if others agrees to it. Tom and Boris, thoughts ?