From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932673AbcKOQGc (ORCPT ); Tue, 15 Nov 2016 11:06:32 -0500 Received: from mail-bn3nam01on0074.outbound.protection.outlook.com ([104.47.33.74]:43072 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751665AbcKOQGZ (ORCPT ); Tue, 15 Nov 2016 11:06:25 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Subject: Re: [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME To: Borislav Petkov References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003513.3280.12104.stgit@tlendack-t1.amdoffice.net> <20161115121035.GD24857@8bytes.org> <20161115121456.f4slpk4i2jl3e2ke@pd.tnic> <20161115153338.a2cxmatnpqcgiaiy@pd.tnic> CC: Joerg Roedel , , , , , , , , , , Rik van Riel , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Konrad Rzeszutek Wilk , Paolo Bonzini , Larry Woodman , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov From: Tom Lendacky Message-ID: Date: Tue, 15 Nov 2016 10:06:16 -0600 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161115153338.a2cxmatnpqcgiaiy@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: DM5PR17CA0043.namprd17.prod.outlook.com (10.173.128.157) To DM5PR12MB1145.namprd12.prod.outlook.com (10.168.236.140) X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;2:nxoSN6QprBwyiOLCcmfN8ZdUKZAs6LXRq//Y/qR/842yU+nlii+DB+A2jIqLEAf+qFzEO3ZZ6Q3MaFuN6w/0bvEBFBjFDgq4wJw8TjZwJf2ECStThkwh/swS1WWyO90dSzMXmdKV3weJGQRnhQmznZtii67YsJAlvyvPAqJD2cI=;3:/0Gpk+xswxp6w19gkibE9lxVi3kS3jdoTyE5q1hNwlBIaPsEU1ASs7d/MPO440HFDIyfi2O/4Vh/3iX2BB8oZQZVc7IT1gbnpqqDEtWzzzMFnlTaKvs2LMDsjvZAPBGAOwhxxOoCFl7Khm51A0MC7At69OurAT7b7RLEg+r0Zvc=;25:0FJJtDgEBnA2aTSjm493hHA+QlOFTDPPZLEa6Y+arVTPE/0c/0SavtBdHpItPOGkNQTwmAIppME3RTwkbLeJwex1Di222pKYik46d6gAzWcE1Eki6xXI6TnR7FYGtCdewJ8Hb6/pE/WGtDiDFyazcBRFJ906yEVAHKYoTMOQ4qQSIdefZLG6JDzi/sarYrmMy4lE+YmeRFClKCHL0nrhU6mvLVt9HIiI89vJQ87iXTgZZfzBXhakKjKysyqCpQ2wxp6oM2U7Ir+mcvbwyijiKkh6k0pbMkkdT8c0YbHmH9NwP3uk31G00WpVew3tpi5aKDP23SsSZJhFoJu9EWDbNdU6rwI9XVuQj8yOPNht4tRbtXQY9qqGHftsMWDkPHrTNA1RAiHpyt4PoAowswXDeSLv39iiVHk9uekO9g8rxl2mg71f6T0+2q3BpCJuSAT8 X-MS-Office365-Filtering-Correlation-Id: 9db96375-f659-4b69-0fa4-08d40d7156e8 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR12MB1145; X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;31:N3GuB9vbndIYuJMSNwLzfv0qSHqLqvjQY/VoTStiU0hcAH3AYx6Ef/Wz4b1Qoc10fWnXDXw0i5IM8JmV3LQfgU8ec0LZwZNcptih1/irCAHHm2kAhN2G7OG8et7CmUdipsKKzd+LJVqsnUxueK8v0AiuowWgxt+wMhQM4mDfb3yK1Vha0VDDkFqZ4I2uQKfBTU0X+rTPwEOhX9d2TJngoUI5YLesEL73tej841crMmZeJ3lo3JxQAL14CVr3r1H4;20:3bI3sAWDRjzlO0H1oIExk+yG4JaGI2K/xtVaElK1V9h7HixSl4DtxfIabPd2dg9OFGXY1gtqp7rNZ2QSLFnkLjEmnkyT8hdIaim0Sksscu8+6adlprkZQov4L3o2b+4G7kUlIm1uKrq5PC8mlk7MLzUCB11KjLBAE5ooBoMKuSYT1epwTde0Vc0uTducvmC7s40j7MfVetCQs1t9H34lpR8dMybejRo05BrvWfkA6BsZWAi80a1WBLYNFHStnBEtErrzxEIJuHtW8jY7z4puOnD+KAXlOxE+yxWfokux2cflC5jofFtY+cg3Q2i5LSeipwjxdfNbaiqVJa3SNyH0QxSClqVaYs0wYsT19snpJPhl6phEZTRvU4z7gicR0PWHMz8Tup1UYWoqtG2HW3l58Pjq3tEJvvDCRThhuFvtyI8fe+YOhwcSOmUvapX9oG/lMWaM5p0em+EMZ83F9WC5lNm+EUAbR65HtUCT0XacssexnWCT9k6QjBZpBAcVHZUs X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6061324);SRVR:DM5PR12MB1145;BCL:0;PCL:0;RULEID:;SRVR:DM5PR12MB1145; X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;4:PZbF82ES7tk0Pl4jbLgdPuzmNwWACF4VUZdDTpCfumaooEa5Essdwgpw11vT9KTOIsuCkfdiOMN21ba9yrJkZBiwb0DlWMckT0BjGSRln/Wo4TVUwqQZ+uL3/Ili4Nu4jKZhdKFruxV4BhaU7qbhT1NNT9v1D7j8NoqIyBXUWjwm8OnrCxw+uqd3aHHg+vR5W/Urh5LNFKeYYvkz1erffejU4WNRfY4IOnQGzuzTsRmt0htVcpSxV8JXC+iLkVb0+NWO/U4gAdpsEOq3lLvA0W03uV+uvT0UHJmwbzR0BHLE+NXza5e7VDz0HkJRok71PvKx/cYRi8sstfAxZ4uOH5KoUrjK6VkRCkb/zUJmNLuCZFB5byvyFV/jGgAb2VLcB3nl6QUCBcanAD9Sp0ruGTUQ+kXnU70KVokK34Dsj4iuKL9hC5NQOXXEaxoTMBRf X-Forefront-PRVS: 012792EC17 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(189002)(377454003)(199003)(24454002)(51344004)(65806001)(101416001)(81156014)(189998001)(47776003)(66066001)(50986999)(76176999)(50466002)(81166006)(4001350100001)(97736004)(23676002)(33646002)(36756003)(106356001)(64126003)(105586002)(93886004)(42186005)(31696002)(92566002)(31686004)(77096005)(65956001)(54356999)(86362001)(6666003)(6116002)(83506001)(6916009)(2950100002)(7416002)(68736007)(3846002)(2906002)(110136003)(65826007)(4326007)(229853002)(230700001)(5660300001)(7736002)(8676002)(7846002)(305945005)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:DM5PR12MB1145;H:[10.236.64.222];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjEyTUIxMTQ1OzIzOnlCRFR4ZGt6L3ZvWWEwWXc4ZXdYdnh1MTZQ?= =?utf-8?B?SU5YSXFzdFBzQlIzdlB4eUsrQlRkZDU3NFowRUQ0NDRpa1Jrc3NkakRmT09F?= =?utf-8?B?NnlsS1VJa3Q4bXczU09ERGJ5UFF1ZVowTXlOcHJhUWVrNEdDUjBGZkgyV3h3?= =?utf-8?B?dXJDcWJrcnY0SnBlZndLbDNkakZlQ3A0QzZiZnE2QTQ1YkM2OTFwWG1qVHN2?= =?utf-8?B?VE5JbTYrOFJPeEM1dmR1UjFZKzUyUEFDNUJJNXlOZjFaWG1Cbjd3cE54NWM3?= =?utf-8?B?R0dYVXRlYVhJM0M1b0pHMmZEb2xmbENQUVFLVDJVTGt0elhlVlhyeUZqTFA5?= =?utf-8?B?U0xIWFVVSHZDOWFWTG9lVUVsUHN3SUJQdktIZWVxR0YyWWNIMEtQUmZZUnlR?= =?utf-8?B?cnNnNlVsTHJ2MkkrZk1hN2xaeEV4bnNZSFhDaTBEaGp0a2U5enA5VXlQbzJU?= =?utf-8?B?aG9BQlhEdS9yVVhEb0wxVEtRL3R4dTlKaW9kaE1BM01qOThNOWk3ZEhqUXdU?= =?utf-8?B?THVlMjlCV1RQS01WNU9XdVV5aUhyMC84RERSMXpnemNSUjZvZmMrM1RJUzd2?= =?utf-8?B?bWlPWXBJZk0xQW1VaE9rR0hBNGdoaEN4S3FsZm5BV2pJRjIxeC9ORkVHVjMy?= =?utf-8?B?S1MxKzNGMWRiM0Z5aGNGczRvWDFNK2JXd0E3WHdxbmhSVit1cE1zYUdlVGIw?= =?utf-8?B?OFR1VE1lY2NLQ1VCTUhYVmVXR0dzcTY3c012NUltSXlOUzNWOGkrMGNhRW5p?= =?utf-8?B?QlV0d1M3YkcyNHFkN2RjazZjb1JhajVnUjRHbVR2MlZlZzkzMWxYRnFmdWZY?= =?utf-8?B?eG1Ibm15OFlnOCtPbXZHR05PTXo4OXVlbzBWaGxkV3dhWkZqV2t2RElrQXNN?= =?utf-8?B?ZUQ2Q3NRTmRITVdYWCtYZ1pHU05VWGJjOENUVno4dXBIZDZBWjJ3VXVuTms4?= =?utf-8?B?SjVTK0RhNGtEQnNmVXA3KzRkampxQStWY1UzMFhIbkZYYncrbEFPdUE1aHly?= =?utf-8?B?SlRucDg1Z2szWllNaFhGdHpESnBwR2FwQThma0xEa1hOMmE5b29WSFUwazFr?= =?utf-8?B?Q0ZyNk9RR2lKQXdaL3VuY3Bya3l1V3RHMStTaURHNlBRaFh6UnJ1a0lIVVFv?= =?utf-8?B?UVhSSUpLMERMYTdXV1F3clJiQXlEY0pabkFqYUJtcHRaMnJsMm1Pb1A4SFB0?= =?utf-8?B?UmdrRWgrT09wZ2VWQVIrNHFKK1VqT3FBYjErTTV5UXo5T3pZdkVoaWhLLy9w?= =?utf-8?B?S3BKMDRKOE5UVms0eElKL25lbHNVbVU3SVBKMjFIWnd0NTdVU1VEOGxCMTQw?= =?utf-8?B?Y1RXY1QyR2o3em9iblJwUEtueDVDOWp0Uzdwb1hFazhOdWxSaXB6ZGJzRXBC?= =?utf-8?B?N012UjFVN0E4M0ZkQnVaaU5IL1pMYnBZek45SEJ3ODR0bm1xSVk5RVNSRGl0?= =?utf-8?B?RDNtMkt2cVk3S1lOVGJhK1JvZWs5WHgzUEdTbVZxV3RISXZ2N3FiT09hMy9z?= =?utf-8?B?YzRuZFNQWUR4cmxJS2hLclp6VGhGeHdqR3ZFMUZ3cStMcHRnSVZWYlRuU0Vy?= =?utf-8?B?aU5IaFFYS05TNFVuYTRvSjNvRDA0MnlrMXNZLzZkQ2kvZmJ2U0U0Z3hadEtu?= =?utf-8?B?a2gyTVY5Q2tRdXZUOER0RFg4R0MxeTdoQlFHK0tJaEVOdXpjZldzazN1dThh?= =?utf-8?B?R0xTZktJa2diSUw4R2tRMlZDM2l6Q0lhSTdMOTZ5cGNubWVOZmFXVm1vVTRY?= =?utf-8?B?ZXY2b0VUZWZqY25lSW5hL3UzbGhNQjBoV2JHTldodmEwQUdiTUI0SGRxOWFi?= =?utf-8?B?REpmZjBTMklMUmZUd3IvelNKUjN1NnpSZmVpNlQzRUVkV2c9PQ==?= X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;6:dOrj+NnvF1IJgc0nGcs9bAJTmoOXMVqMCtAtMaNnJjuQCxaDXXU7qct85mDXkbf53o20suM3NuKPR9dYVTedxrfFZVv8p+x64oQn6HQ5iLRy2ar/dEEMF2qvkkWW65kyPoWqk1ky8Dlf7CZBGsLOiC22KqGByTfbFWBHuyUke2vEek2MYnL8WyV2Y1mUxyK0r9CaskQ425bkj17+HW8MiOCsDAIeAYibUXne+jexziLAiL8khURvvKo6BBSet74eBkkyb1MJ2NaClhnrjUKs5er59Ryl56jm5R+A3QysDsbY2G6y7oFE0e1eahepLEaAB01m4R0Xr18s7/EMh3EhvxDqsNP2cI+S71fIZaKSCThOO4LN7r6sePHO3+ipoGEQ;5:q9iEqwfanIFa6TJ4jlrpnXd1fNChJeweFLwHrTCj6M2xtmDh5cAovuiK12j/mB0WtgSVMedOO6zdDy9xt7mfRVowpAY0vUzHQ9+aYAowaraNYHievKIzy3FYO4RZSFI+48AyTSbRTyi5WK1EE+7y4kVDWHtwuxudMQ+MvEwGJr0=;24:l7ftwNPuaAonSG/9p9f+P+4HsIrhzEHDkghUZnMioUb70MjM3RbFEqGy3FrSWE/iY/W8o3Wq+YZQGIhjCuORj9Bkwqn+tB4FouiEtGDXvGQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;7:dmKkk4fUCxROGz9aVltDpQPZo8mo0fKml4/aiEYkjDplyTcTx6VZa7FcFBIfGb+WQ4F9XaAJwoeAQNNetKtHFPrAmfypD7ox13MHKf22qUnFpo8Gv0Yz1N1o+ETeazGEGNqgzD01uLHI5pf3kVItAnikaEnyE4RFLz1xC54p+ltjNdWdXBOfrZfb7Tab8bm5/p/bDYPUVVK+EQZOcbnBkMAVFVwuDbvJadb2TkIaOsyHdos5S3twt16kZHA3BIO5f1jnxrspvd3u5C3BFyh5/2yNm0qZbhfjR3IKtNCtKdZkrMJDQay/+X82OLcEmL3z1uWG/RF+pEQ/u/GJ+e2EVnpoCjA6iOc2z+KLy/CBZFs=;20:O7YYhkzTYEMkDAPp3nqvm7lwBA9RNU5zDgaTrk7VVM6rLGgRoDmqxwHf+jZ5YS02bI5FaXVk+cKe4/MZhULwYj5fZXlkMik39ZN4K5CqMj3M9J9OpH3kqn8xmDNXZCLaoRbyhBlp/j+8TtDOD+cPk0u4+f52mKlxlotB1Mo9yMp9VmHrIxvkQX5iWrgxCqcMJVL/GBJ33HbAsiliPhd0bk/SRG/B17l+eZ7gJS2g6ZTiwF/OCLVhFj+SNj8XVBiU X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2016 16:06:19.5407 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1145 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/15/2016 9:33 AM, Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 08:40:05AM -0600, Tom Lendacky wrote: >> The feature may be present and enabled even if it is not currently >> active. In other words, the SYS_CFG MSR bit could be set but we aren't >> actually using encryption (sme_me_mask is 0). As long as the SYS_CFG >> MSR bit is set we need to take into account the physical reduction in >> address space. > > But later in the series I see sme_early_mem_enc() which tests exactly > that mask. Yes, but that doesn't relate to the physical address space reduction. Once the SYS_CFG MSR bit for SME is set, even if the encryption bit is never used, there is a physical reduction of the address space. So when checking whether to adjust the physical address bits I can't rely on the sme_me_mask, I have to look at the MSR. But when I'm looking to decide whether to encrypt or decrypt something, I use the sme_me_mask to decide if that is needed. If the sme_me_mask is not set then the encrypt/decrypt op shouldn't be performed. I might not be grasping the point you're trying to make... Thanks, Tom > > And in patch 12 you have: > > + /* > + * If memory encryption is active, the trampoline area will need to > + * be in un-encrypted memory in order to bring up other processors > + * successfully. > + */ > + sme_early_mem_dec(__pa(base), size); > + sme_set_mem_unenc(base, size); > > What's up? > > IOW, it all sounds to me like you want to have an sme_active() helper > and use it everywhere. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME Date: Tue, 15 Nov 2016 10:06:16 -0600 Message-ID: References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003513.3280.12104.stgit@tlendack-t1.amdoffice.net> <20161115121035.GD24857@8bytes.org> <20161115121456.f4slpk4i2jl3e2ke@pd.tnic> <20161115153338.a2cxmatnpqcgiaiy@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20161115153338.a2cxmatnpqcgiaiy-fF5Pk5pvG8Y@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: Borislav Petkov Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , 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 11/15/2016 9:33 AM, Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 08:40:05AM -0600, Tom Lendacky wrote: >> The feature may be present and enabled even if it is not currently >> active. In other words, the SYS_CFG MSR bit could be set but we aren't >> actually using encryption (sme_me_mask is 0). As long as the SYS_CFG >> MSR bit is set we need to take into account the physical reduction in >> address space. > > But later in the series I see sme_early_mem_enc() which tests exactly > that mask. Yes, but that doesn't relate to the physical address space reduction. Once the SYS_CFG MSR bit for SME is set, even if the encryption bit is never used, there is a physical reduction of the address space. So when checking whether to adjust the physical address bits I can't rely on the sme_me_mask, I have to look at the MSR. But when I'm looking to decide whether to encrypt or decrypt something, I use the sme_me_mask to decide if that is needed. If the sme_me_mask is not set then the encrypt/decrypt op shouldn't be performed. I might not be grasping the point you're trying to make... Thanks, Tom > > And in patch 12 you have: > > + /* > + * If memory encryption is active, the trampoline area will need to > + * be in un-encrypted memory in order to bring up other processors > + * successfully. > + */ > + sme_early_mem_dec(__pa(base), size); > + sme_set_mem_unenc(base, size); > > What's up? > > IOW, it all sounds to me like you want to have an sme_active() helper > and use it everywhere. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) by kanga.kvack.org (Postfix) with ESMTP id 3C98D6B0298 for ; Tue, 15 Nov 2016 11:06:35 -0500 (EST) Received: by mail-it0-f69.google.com with SMTP id q186so6537688itb.0 for ; Tue, 15 Nov 2016 08:06:35 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0063.outbound.protection.outlook.com. [104.47.32.63]) by mx.google.com with ESMTPS id 32si16194051ios.116.2016.11.15.08.06.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 08:06:33 -0800 (PST) Subject: Re: [RFC PATCH v3 04/20] x86: Handle reduction in physical address size with SME References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003513.3280.12104.stgit@tlendack-t1.amdoffice.net> <20161115121035.GD24857@8bytes.org> <20161115121456.f4slpk4i2jl3e2ke@pd.tnic> <20161115153338.a2cxmatnpqcgiaiy@pd.tnic> From: Tom Lendacky Message-ID: Date: Tue, 15 Nov 2016 10:06:16 -0600 MIME-Version: 1.0 In-Reply-To: <20161115153338.a2cxmatnpqcgiaiy@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Borislav Petkov Cc: Joerg Roedel , 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 , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Konrad Rzeszutek Wilk , Paolo Bonzini , Larry Woodman , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov On 11/15/2016 9:33 AM, Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 08:40:05AM -0600, Tom Lendacky wrote: >> The feature may be present and enabled even if it is not currently >> active. In other words, the SYS_CFG MSR bit could be set but we aren't >> actually using encryption (sme_me_mask is 0). As long as the SYS_CFG >> MSR bit is set we need to take into account the physical reduction in >> address space. > > But later in the series I see sme_early_mem_enc() which tests exactly > that mask. Yes, but that doesn't relate to the physical address space reduction. Once the SYS_CFG MSR bit for SME is set, even if the encryption bit is never used, there is a physical reduction of the address space. So when checking whether to adjust the physical address bits I can't rely on the sme_me_mask, I have to look at the MSR. But when I'm looking to decide whether to encrypt or decrypt something, I use the sme_me_mask to decide if that is needed. If the sme_me_mask is not set then the encrypt/decrypt op shouldn't be performed. I might not be grasping the point you're trying to make... Thanks, Tom > > And in patch 12 you have: > > + /* > + * If memory encryption is active, the trampoline area will need to > + * be in un-encrypted memory in order to bring up other processors > + * successfully. > + */ > + sme_early_mem_dec(__pa(base), size); > + sme_set_mem_unenc(base, size); > > What's up? > > IOW, it all sounds to me like you want to have an sme_active() helper > and use it everywhere. > -- 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