From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751202AbdCQO6O (ORCPT ); Fri, 17 Mar 2017 10:58:14 -0400 Received: from mail-sn1nam02on0088.outbound.protection.outlook.com ([104.47.36.88]:44869 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751065AbdCQO46 (ORCPT ); Fri, 17 Mar 2017 10:56:58 -0400 Authentication-Results: davemloft.net; dkim=none (message not signed) header.d=none;davemloft.net; dmarc=none action=none header.from=amd.com; Subject: Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page To: Borislav Petkov , Brijesh Singh References: <148846752022.2349.13667498174822419498.stgit@brijesh-build-machine> <148846761276.2349.4899767672892365544.stgit@brijesh-build-machine> <20170307145954.l2fqy5s5h65wbtyz@pd.tnic> <413f12e9-818a-745d-374b-3dbc439e972c@amd.com> <0a7de265-1352-6327-ef3a-4287bfca732d@amd.com> CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , From: Tom Lendacky Message-ID: Date: Fri, 17 Mar 2017 09:55:55 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0a7de265-1352-6327-ef3a-4287bfca732d@amd.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: BN6PR15CA0005.namprd15.prod.outlook.com (10.172.204.143) To CY4PR12MB1143.namprd12.prod.outlook.com (10.168.164.135) X-MS-Office365-Filtering-Correlation-Id: 0596eed6-c00d-484d-3f3c-08d46d45bc11 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081);SRVR:CY4PR12MB1143; X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;3:N8KiS5d3mR6VWRECNeaaGUyCCj6P7C6l8otPKDWf4zvcSO7OhtNTjpVi3RQtMRfDobjofj5rnmtRJTzhFpHRY4om2QH6zWw0v+nZjQn470jciOXbxwBBArIRqK2Zf25OihG/b75sdST5i8l/llkHjwXbj/bGksbd5DgcyRnlnGWaD0d6IB73qsfWrnStqspjpPB9bIaYIq6kIhu8l5ZhHLZ+/D5AK0mMUp4vzUeyfMdOWZpJmMQcemEySoQ4EZXuQ+wgSp5CddXx+eNRGL1ZoK8oN8xNe8ex6cYp6ePVYVI=;25:Hm1sO4kDjOrVMUYq3Fq1ovvUQfAyAWDZERl5txoW61yR/2Lncq2zo2GQgWWCD1I+k+hYyjOA+MVEoG9DO5O4PZHTOq+Hg+rbZW+gidihRvwiL7oepMx7Baw+YcIyzmbzvNhmGhX7NC3XhNw6P/UArNiKZT9kUBgyFryZJfAl5qw3SFJDBK1EGVt+fu3VkVOOxt+75A3ZC0Q1+ldDxA33ITwHJ2omJNi0HKd5HmgSBRhANge7hWUhPUj/OX8LP/233rUb6w9RIDXm5ce08AsPqkaEdJU2LjGp85g2ah/jVp+qcb27wEbACXh42CQIrFEs8opPOWnfu5TMQsscUBMkytQ0/UeqMm3VEtSr+gnmZhLafY3bo2gRU42RmtoXrcdeRbXFGnNfVGREvmi1wK1undphfu3Mf2zMRaRJSEY5W5q4Bi5uSyhqv8vRYozmM3dB559F3uyaJQ7wE7IAOREkXQ== X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;31:Wv6r0TKOqjKLeZDOzoJRd0sbYbTlsKNJCMUtx++JCseDC0zu2sOsDAndYujijSgp2ZjkoIoicA30zNKm9ExlJZtwTMESyvVzc2D+Sfgtmj3aGuWQz3HOVuJh3S1FFXU2M3VsUDnikn7jvrGyzpMPJ/mG/zydyE/UZ02FwUGVyTHYgDbatKVA50sLkIRfHzhbOwIrGmkMAdrhcRzGoBBgDsgiy7SXJd6+8iXGHiJtoyY=;20:yEnyagxswgCify4Gmi6L7YZE6vC3Rfh1OnZuoUEN1a0DB3RO7i0rfpId7HBoMCFIoqz9XnUQjU3ViRGdPEk0ZHnSN6O6ebrbE0CujB37T36BZa4k3qUO+Vo0S793ZTV3DYaE2z5+tlccIbv9cJz2SvDE4n+Bs9zrGeKIVAC0J5oeeZdoqroPwtALXb8qwIgBuyaVufD39IuwRF57rGMfAuWV3iuQyXDBaHMxGWpRpSpMcWL/G65/PZ428WFdPKQfaCuK0RsLc1rVG4MsDxE3dLOf3IitzZMT1vfuUzSv4YXmalUL7bxfam2obmyhE8iDGckqb5evNBrwBFhN2GoNw59xL3kFCQvmhpF7HjC15+FoqTjZJsortnvhWII9wWVeG1wutkr9VXFZQe3ruQrlcwt5TBs1mnRtP7ZeY0eu1D8VZZ2wC8qGr7apawShAv3rTFGoneI2xfe38ZxD6kQL6af2cY4kgQ2ddbpV4w1rRAcPnEZ0Ao1PU/nvKwN8GMUw X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(767451399110); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(20161123564025)(6072148);SRVR:CY4PR12MB1143;BCL:0;PCL:0;RULEID:;SRVR:CY4PR12MB1143; X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;4:0cI3qKvcaSCGBwRT/RcHnqREeVr8NOZ2YKoZ7V72Y8Hr3u6Kh5EMdjx4N9s8z7aP0nNDYAq6laIAe3tQ7AvV6VSklFodmq5ZKHRMr1ZdMb0exvgKT0AscicFSmwJNPJwIzKzdAPfUyq3fKNiOccNG1zVTylZHlN31GIYrvo8N4jLPunkaHXwISYNBuf1RT5wWQDty3OLmx057YDBVFuKjivj0u79UlAOJbeqD2TK9x3pczRY9lbFrPjtCzhq7B4FVeYZq0gzVc23WMowRDVcLM9Em/OfnyOhTJZ4ZHtS0SgzxAKCpA+kLjxXLvLtB6ZY06guxbqR5nnd4ZxaFw1djMAEGeyoL4ArbWng1un+j4/fv3B9TQjn74O1onXk15SIqBd/BqLX1rftGckRX8iAPH9kd0kyby5e20eoClr/Fxz+KEJNWx2tf+5IntxblA0aJ8mGxKJVjWheJlgZ2c5FjFCMDWPfC/m/hfAkMNzQrkH5PWU5W8C/gZ44oqntPP1pmLPjUqNQ9d2/4FD8Vb8O4VG0PLnaMkMY09STyG7B/9HZVuV7LjunUxUzFn/fBGCUpVr6nZcap3JEg1h54sPlZqw6lGfFGdHq/LQ1IPZdlY+8AiO/8oZZVicobslE4x1DRGDUuMBGyki2AIeFte3aSGE+JFbFnvs1ew5mGN3o7mQ= X-Forefront-PRVS: 0249EFCB0B X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(377454003)(24454002)(305945005)(7736002)(6116002)(83506001)(81166006)(6246003)(25786008)(23676002)(33646002)(36756003)(53546008)(2906002)(2950100002)(189998001)(6666003)(230700001)(54906002)(6486002)(38730400002)(6636002)(77096006)(7406005)(31696002)(7416002)(8676002)(86362001)(65956001)(47776003)(66066001)(4326008)(93886004)(229853002)(50466002)(3846002)(76176999)(53936002)(50986999)(54356999)(31686004)(5660300001)(42186005)(4001350100001)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:CY4PR12MB1143;H:[10.236.64.195];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTRQUjEyTUIxMTQzOzIzOnRYZnZNQVlMY0ErUHE1SVJRaFYvOUcwQit0?= =?utf-8?B?OHN4MGw0cGUzTnUrS0l1RG1BZkNWOW1RcE1aRDNnYUZGWVhVbWF1ckV3UHRI?= =?utf-8?B?cnNnYXZlRlE4UXIwREk2OVJGcUFXRkF1ZHczdjBnNXMrRFh1K1lHRFQrdU9R?= =?utf-8?B?T3FnNnUrWjJ0TzhUN2JVbVpZQWFRR0pRWDM2TTBaUVRFMGtjT1dSTWpjdWJE?= =?utf-8?B?RkNUTU10eWttNkRwOGhzU1NXWDFZNVVFdUZvY3gzUlhPQVdnd2lCQmFmdm8z?= =?utf-8?B?MlpEU0JHL0JWSm8ra1U5N1hlcXNBYzk2a2hWQ2FhQ09UK0NISmVyQjJMaEpy?= =?utf-8?B?dm1HdE1nU0NpdGxJZ2NXZFdsdXk1MjhEdTUxd0Jkb1c1WGsyWWw4M3pCM0pp?= =?utf-8?B?SmRYOEJlcGhGTVNwb25VdFpoLzVoTGdYTGpiaGxwSDVyaVpncGJLc2xENUh2?= =?utf-8?B?enR2SWF6SlVldmM4R09zdGR4SExYbyswN0R4RU9OZC9uZ1Z6amZBVkVpYmRS?= =?utf-8?B?b3FuZjFCcG51MDlJR080RThOQjltUGxHTk1OdUZENDg4a3JWaGNtaklNdEJy?= =?utf-8?B?QWFCVGRLRnhZNzI1RHB6WXVEd1pvOTQwdHpsS0RmVzlBZjlLdEpFZmRaQ2VS?= =?utf-8?B?bHZNOUFOVUw2b3Bya2FGbEJMVmNaajZ2M2NjMUtJWTNCdDQranJYRnMyc3or?= =?utf-8?B?SE9JMU02QjRPM2FNRitoRkxkWEc3TjJKellmOEZqTUlGcEVIYWNhK09JSXZR?= =?utf-8?B?QlZTa3FaUGhkUnRSWFRMZzRYMVd5WUFBK0dHUU14VnBXSFo5L0ZidklERkZY?= =?utf-8?B?blY3ZGRxOG1tZll5MmtaM1htVFcxUjRFNEFyYytLY1ducVBiNVFvaEhUaHQr?= =?utf-8?B?TjlHMVZtQW5tU3pLQnNUYmI4QW5kbmkySlROcTRmK0xJM1p1bm5TamY0TktH?= =?utf-8?B?OURXdmVwT0xhVHVuaXpuRTYxbk1sS3Y4UVVPVVYwRml6eTZGV2YwUjd4V0FD?= =?utf-8?B?MG9qd0lBWFRPWDRTYnhiMTFHWm1YQnBERXIrUVFVemdLQTN4b1hPRkZiQjZG?= =?utf-8?B?aUlKdENDYTcyRmJGWEg2Nm5IQkFMWXJUQWd1QnpqR0NuWm9vTE80MldCKzdF?= =?utf-8?B?aHdFd1pPMUxJV1lOTHhaTGUvZjhZTEhvSHZFWTlGQlE4YWlVeU5NNHlOUWZW?= =?utf-8?B?cDNiYldiKzYzVXBza2svVlo1VktXQmVwRTZGSk1MY1BOdjRyeGoyV1Zkd1lH?= =?utf-8?B?NGhPWENqd0JXZWlhcXFpUG5DZVJ1RUFlbFR3WVRDWEtRUjIzU2pOV05pVWJu?= =?utf-8?B?ZnVQUVFoWXJHVHR5cjBDQ1oyYzZJK0pad3ovaFpieVkvdWxWSmdGOFExNTJx?= =?utf-8?B?cVVqQ2h2NmpVS2NTZm1rSnRyQmFuK3ZxejAyeG9oRHRXVENwZldXVW4zSFJi?= =?utf-8?B?enlweWNjVUFKNDZXZW5vclRsNFlRVGZLanpPUjk0RU9qb2dPUlVyempFV2ly?= =?utf-8?B?cTgzOUpQczlzQmxma3ZYcDVxREdzaTFGOVVOVDcrWDZqU3AxbDh1NnZrM3hv?= =?utf-8?B?YXNYcllaaSt3UHgwVHE4UEhtcVZyazArSTUrdWxXa0REU0JGTmFtYW40OG1N?= =?utf-8?B?c2trWHZ5YXAzdE1Idk9kK2QzNTJMSXR2dnltblBpZzhtOFJ1RjArM1Z1TVl5?= =?utf-8?B?OGFwbHFYaWZGYVdNMjYwSC80Qm5Bc3R3SHFnQTdNckRqNDdGUTJWeTQ5TzFI?= =?utf-8?B?RFE3MGRweEIzS2s1Qm1CUT09?= X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;6:Z6n1yNcS0900VrXvazGQAetUcuzu20OcFaI2w3GKN93812sdVYVMj/6acdrqj7n8v2kfiVnATZG3pgr/zMEs4cy6xyIuF6aWqiJC/GSpRwnksMQQ68D6fKn3bAvE6135/p3T7IxTZt+W4mNOWjctE15NCmqyMmMQmTDyGqBWD2fLvx29IgcQ3gp0+goOr9sMs1U5fyYiLXdEgKvNnwPRPFFRFmIYr5/IEE+2OYlAV4zFEqgLmj/9b0zd8j07qv/leVIY2bX68vTP4e10k3KJv5vqtglGJatJN0NJiP6Qiu9qIoWqhe4ezZT2VFS9afKZbQUF8hKeCfRQ0Y+SHlXbd8T5trsds8XPdBbArBGkDCOVjgpLBM/xWZwt4EHj0NVbpXhm/i06nlcesCy1KmhgXe6ooimbkp1oGyQE1w4AJBM=;5:NqxlFs0cxqYw8HXHnf/AfzY905q7qWtP9Q7qVy9DeQBN4RXaePhR47VCuoS6Y8pLx0lwvby2Z3uf8TsmbkUaZG6g6sKFddSynweJEr4pGyV+qlkDQdBgTPFeGlnlpr8McRCKnyEQXpizvSbeaP7ZEw==;24:mcZE9UBxvBrTRo6q9g0lQvavnv/TyuKgmhm+65XDKIz5quv36B0d4A5fXoHeWHXIdapmDAaP8irJs+Q1s+jxZsXFLrJ1kR73lJ87FVrx0n4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;CY4PR12MB1143;7:10faJ2Y1ho8/0tUV8hRaItfulonHeaQzBRS+/58ttIhMLtGo73TG0IwoFGVS/9Ur5cVui/10du/fYTLdHKxj4/iMYmvMLB/5pRSfRdjSGj6m+bIh00wF0Zb9qezrsAoz1xwSySKrN9BBo+aNzMuG2q7DA/RaLSZzSgx30d9jNnP/hGG/9VOIyg8x75/+BJNGBysfElQQP0353DE8NcnFTPXkTWtuzFaLJuexXrVdxtqaPWSm+r7gkgBcnRODL0Kfx9Ey6gAAtJdxDDXaxb4Lz7Q4+6QO9NkAzpgVSsnSxUXO7mTcN77vCWEBFaFtkTCKVsFBtFjMmVua69/teLAnTw==;20:0GvRaE9gehr2dxAywKi6lNMdhgBKER8hbBEgAIUZah80JfGr70f52P47997Lyp9D0x+h1y+3Ehph/ccJBtxZYWaygg8hmI13Egg/vufT60ndhjYwm+5sCiR9cSjnry3W6AXKqpt8XeCvILJA5zywdcnwo7gqwRGe9ORwOQmHY99aVcJRdSlC/Ro+LtLip8ksQPHs5UR/Di2zgG2ZDlIOyaAi6zbWP8rTzQwqe6Dxne6cw17F/YTjhNQB1hNYKZIS X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Mar 2017 14:55:58.4883 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1143 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/17/2017 9:32 AM, Tom Lendacky wrote: > On 3/16/2017 3:04 PM, Tom Lendacky wrote: >> On 3/7/2017 8:59 AM, Borislav Petkov wrote: >>> On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: >>>> From: Tom Lendacky >>>> >>>> In order for memory pages to be properly mapped when SEV is active, we >>>> need to use the PAGE_KERNEL protection attribute as the base >>>> protection. >>>> This will insure that memory mapping of, e.g. ACPI tables, receives the >>>> proper mapping attributes. >>>> >>>> Signed-off-by: Tom Lendacky >>>> --- >>> >>>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c >>>> index c400ab5..481c999 100644 >>>> --- a/arch/x86/mm/ioremap.c >>>> +++ b/arch/x86/mm/ioremap.c >>>> @@ -151,7 +151,15 @@ static void __iomem >>>> *__ioremap_caller(resource_size_t phys_addr, >>>> pcm = new_pcm; >>>> } >>>> >>>> + /* >>>> + * If the page being mapped is in memory and SEV is active then >>>> + * make sure the memory encryption attribute is enabled in the >>>> + * resulting mapping. >>>> + */ >>>> prot = PAGE_KERNEL_IO; >>>> + if (sev_active() && page_is_mem(pfn)) >>> >>> Hmm, a resource tree walk per ioremap call. This could get expensive for >>> ioremap-heavy workloads. >>> >>> __ioremap_caller() gets called here during boot 55 times so not a whole >>> lot but I wouldn't be surprised if there were some nasty use cases which >>> ioremap a lot. >>> >>> ... >>> >>>> diff --git a/kernel/resource.c b/kernel/resource.c >>>> index 9b5f044..db56ba3 100644 >>>> --- a/kernel/resource.c >>>> +++ b/kernel/resource.c >>>> @@ -518,6 +518,46 @@ int __weak page_is_ram(unsigned long pfn) >>>> } >>>> EXPORT_SYMBOL_GPL(page_is_ram); >>>> >>>> +/* >>>> + * This function returns true if the target memory is marked as >>>> + * IORESOURCE_MEM and IORESOUCE_BUSY and described as other than >>>> + * IORES_DESC_NONE (e.g. IORES_DESC_ACPI_TABLES). >>>> + */ >>>> +static int walk_mem_range(unsigned long start_pfn, unsigned long >>>> nr_pages) >>>> +{ >>>> + struct resource res; >>>> + unsigned long pfn, end_pfn; >>>> + u64 orig_end; >>>> + int ret = -1; >>>> + >>>> + res.start = (u64) start_pfn << PAGE_SHIFT; >>>> + res.end = ((u64)(start_pfn + nr_pages) << PAGE_SHIFT) - 1; >>>> + res.flags = IORESOURCE_MEM | IORESOURCE_BUSY; >>>> + orig_end = res.end; >>>> + while ((res.start < res.end) && >>>> + (find_next_iomem_res(&res, IORES_DESC_NONE, true) >= 0)) { >>>> + pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT; >>>> + end_pfn = (res.end + 1) >> PAGE_SHIFT; >>>> + if (end_pfn > pfn) >>>> + ret = (res.desc != IORES_DESC_NONE) ? 1 : 0; >>>> + if (ret) >>>> + break; >>>> + res.start = res.end + 1; >>>> + res.end = orig_end; >>>> + } >>>> + return ret; >>>> +} >>> >>> So the relevant difference between this one and walk_system_ram_range() >>> is this: >>> >>> - ret = (*func)(pfn, end_pfn - pfn, arg); >>> + ret = (res.desc != IORES_DESC_NONE) ? 1 : 0; >>> >>> so it seems to me you can have your own *func() pointer which does that >>> IORES_DESC_NONE comparison. And then you can define your own workhorse >>> __walk_memory_range() which gets called by both walk_mem_range() and >>> walk_system_ram_range() instead of almost duplicating them. >>> >>> And looking at walk_system_ram_res(), that one looks similar too except >>> the pfn computation. But AFAICT the pfn/end_pfn things are computed from >>> res.start and res.end so it looks to me like all those three functions >>> are crying for unification... >> >> I'll take a look at what it takes to consolidate these with a pre-patch. >> Then I'll add the new support. > > It looks pretty straight forward to combine walk_iomem_res_desc() and > walk_system_ram_res(). The walk_system_ram_range() function would fit > easily into this, also, except for the fact that the callback function > takes unsigned longs vs the u64s of the other functions. Is it worth > modifying all of the callers of walk_system_ram_range() (which are only > about 8 locations) to change the callback functions to accept u64s in > order to consolidate the walk_system_ram_range() function, too? The more I dig, the more I find that the changes keep expanding. I'll leave walk_system_ram_range() out of the consolidation for now. Thanks, Tom > > Thanks, > Tom > >> >> Thanks, >> Tom >> >>>