From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424551AbcFMPQe (ORCPT ); Mon, 13 Jun 2016 11:16:34 -0400 Received: from mail-bn1on0073.outbound.protection.outlook.com ([157.56.110.73]:5440 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1423555AbcFMPQ2 (ORCPT ); Mon, 13 Jun 2016 11:16:28 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear To: Matt Fleming References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> <20160426225740.13567.85438.stgit@tlendack-t1.amdoffice.net> <20160510134358.GR2839@codeblueprint.co.uk> <20160510135758.GA16783@pd.tnic> <5734C97D.8060803@amd.com> <57446B27.20406@amd.com> <20160525193011.GC2984@codeblueprint.co.uk> <5746FE16.9070408@amd.com> <20160608100713.GU2658@codeblueprint.co.uk> <57599668.20000@amd.com> <20160613120322.GA2658@codeblueprint.co.uk> CC: Borislav Petkov , Leif Lindholm , Mark Salter , Daniel Kiper , , , , , , , , , , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov , Ard Biesheuvel From: Tom Lendacky Message-ID: <575ECE3C.5030600@amd.com> Date: Mon, 13 Jun 2016 10:16:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160613120322.GA2658@codeblueprint.co.uk> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: BLUPR0401CA0007.namprd04.prod.outlook.com (10.162.114.145) To BN3PR1201MB1107.namprd12.prod.outlook.com (10.165.77.19) X-MS-Office365-Filtering-Correlation-Id: 09ec7907-a105-4a41-c1de-08d3939daf9b X-Microsoft-Exchange-Diagnostics: 1;BN3PR1201MB1107;2:15tQatasU+4joyodIb3/DgsmAh9pQY9iBN8/Cg3vHKb2bfZx57R4APnXpyUwR79L+BbBCfu28Y1tEMR58TZZ93Vc2RxlZ5EPLLfHvW/wKyPcMyAwwhkfefjH5B0K1uALOMD/Alpo2Ap5HD6vj7A6fqkLo30cytP2LAvgpi9105yCu45GzDXmn44VKcoA8oll;3:+ArzVtzBfWTZegK7FKQOO3dzYDaKIIhS/EqKso0B7atLma27Xf8LOJ1Phv8WvIIqzRktwmA4EFrFPijXue3KndsE7/PxSUAjTurkZGviSThLXxWnnzkH0HoIIMGI4F1i X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR1201MB1107; X-Microsoft-Exchange-Diagnostics: 1;BN3PR1201MB1107;25:aqvZTlrzcQSnll0wswz8vW7w1NQATRDebDmhtsnapb9jYvWdchr9kLu8bBfzJRvE+qb0RH3CjBNivjvOJ75ZXevOBV5tC67ZYNUeuZKuO73r2CYy4epGRaZd2xWtC/TXqYrOE63/DnOp7wZIf4lXJ/X1N4NthTeiWhSwja4yM59nbaICTFHITUlXf+YGieeF8cBWAngRUiycdjJ4mQetlbt+f/rsxmbvXAgZsuQ2nBQrwaBj2sBB1H3jDZpxg2nh8CSmPfKok3oi76QeWIMp2AWHOcaWcyL+YExQuYmNKN9BHAzJ9bI1KCFtHDnJnxtDund/8D9zi3AYSEhPTom9hVqSKJAXPtc6GbsRMwrpotVzDsYNIuONlPhPh/qdXMoVjFD0jw2LcL1fM2CTleLWBU7IRTKGe4cKSisX0BmlMuxR1xzHQKnzRzTpZAca0dljoYEhplKfHDsOo+3QnzCiRvJtsh57pvzQVpet/uFBSU8KNKOuBheC/s8cuVRVf25BH5OMP680BGtzcVrQN786h9Uhqa5B5beEzpqm6tyYWT5iLELE80Lnb+uVoARdwKVWZcvdIQctGUUj6HW/jlWsEjLvd1fGL+XEsjCZ+0h/abqKnR4r3wbEFkDb5Tjqsr15rPobsXRCeDX6Il3ysnLlPrJscEaIi17pat7v8hPkdNBYB7feppDrNg4DEIS0S4C0rLESpbwUeW72s8w86J0nSavNL1lVuLqhVhUCyQAtEvg= X-Microsoft-Exchange-Diagnostics: 1;BN3PR1201MB1107;20:MRjDPLRZR1QhWtK1b5XpBux/soUXmfHziGtA0qtMWsHeGyn6Z92B8zpVLW0FED5Kf0XPATAtEbInD1J5HeGqPfbDSuXJJVuAqpQ1GshJ56y9lyQyzx1rV/bXQRlc2qFCYKBW6PB1DEMZsZACTuZso2CUyn540b+k/BYDYglVnWmN6Ru62aotjMPLLOdaRtNTeK0VfjnJMGgrXV/guAzLDlhT0CZdMhOdp/ryMtODIgTpJQi/vs/nt2cHtS6vks/lnEy+ak+r/EyJYv+fkZ8943ZggKu/8gQVJ1zVbUDuWRGvcklxTU8afTJJX4xmeZesbquYnVfjDGAxwWRX9328wouCbe1f9IZNQHNDT6D+DVzJfS5CLxDqPxO3OGTCaYlmKSan20TN/h/AzM+dtTN74PQET7uTtCUm3JgzDl73HzQeo8VbHoh9YfRfrlleVeKCbkKw1wePLiVD851m//MUvDlir/uowe6NAggTZLCZ5ADntF1aFpzvKivXlXpMaL4h;4:LvMu8rhpWWYg89otk2U1k8dN0nq2Ek7SVTRC1UZw9uNjXT565UWKc70ROFELtISkJQb2rQqQOLUfCH/wj9+5lSWU7l2iy9wRWCT/jDmJmLhsLn9nUlh2W65OER5I/E81rCmY5ZRbPIpzfgJmU4NFn72BGy4WTHyonT5iHTELXyO89bomBLIy8hT5gidnPKFkqqmzB/4ESXlmbnmUSM/Bl9T43TNmM2OLyZI2Fy1pdKt8czn5o5QaIgBAwh4cv0lc0I9vjezyaqWJdKkTIWiHZHSKsXLS1XaPYHFJP2nffhDgDtI2B4VG1efvNhj8tuYSaMrwghCKJWlPaUqM1JxS7vOmzBg0vFpAZZi+19BLnkojcRzn4UgnUXFPao2knIbV5m5Rj3daWsKyTQUd8afKOQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:BN3PR1201MB1107;BCL:0;PCL:0;RULEID:;SRVR:BN3PR1201MB1107; X-Forefront-PRVS: 0972DEC1D9 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(189002)(377454003)(199003)(24454002)(93886004)(86362001)(8676002)(2950100001)(33656002)(59896002)(77096005)(36756003)(81166006)(50466002)(189998001)(106356001)(105586002)(81156014)(92566002)(3846002)(5008740100001)(4001350100001)(5004730100002)(42186005)(66066001)(65806001)(65956001)(65816999)(54356999)(110136002)(87266999)(50986999)(586003)(6116002)(101416001)(68736007)(64126003)(4326007)(2906002)(83506001)(23746002)(80316001)(47776003)(97736004)(76176999)(230700001)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN3PR1201MB1107;H:[10.236.18.82];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;CAT:NONE;LANG:en;CAT:NONE; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;BN3PR1201MB1107;23:qv0eDOkwLoT5CzGiEniIvz2fu4Ued8i3AAF?= =?Windows-1252?Q?11bOjskU1P6OkjnHb5CPQ03kA5ojh9ALqVJ2Gzu+K3G4yj0P1q9R7NNc?= =?Windows-1252?Q?/lRynktWezaNSPm2nXAZpxGOVwRKNjY/6rwbFMcNUU7X0K8q7lt/pmWC?= =?Windows-1252?Q?1VtBa0UdPv+/gpklC4cxdzVfZRo3uCOoNQ845+OumKkKY7YilOMVZSRu?= =?Windows-1252?Q?hQFUL896EPKRKlD7l2LPRXNoZ4p/uJFu0IdQYj7WF+TzzgW2Bz2RwNaY?= =?Windows-1252?Q?uURNAG3oVpNrjUAJXKW0xUKRh2MLiWAfaow+K1r12nKeJw0ErVUC5q2A?= =?Windows-1252?Q?wmC09fW1xRPWf+j5BtzMMBqWfqp7nMBx0Kw+Ls66S2NOsDasNy3aOcJy?= =?Windows-1252?Q?DYy040yWZLtr7MURFGvne3PBIn9/HwDJuE6rneB/kDhsVFWG+/Ej0Q/9?= =?Windows-1252?Q?XEg5CJQdFYa3ZQ/VG8cXnE47Ljx4cUJmiXgjnJolHAkAggaAVkOGtNri?= =?Windows-1252?Q?/WPuCDfUYiMGMv7U+qjfSrGGckvkY2K+D/G/TxWDH6VrdqyYTts6u0ri?= =?Windows-1252?Q?arPr1cXnDICwoSsBvcCkSn23KOBJDPGVmOp9Q34l3lJ68Ft7152XTED8?= =?Windows-1252?Q?blZLZYpIhRnBSha3eq569EwoYMmxLNLdnqBa5QFVdMyZbtT9EyLQnCQA?= =?Windows-1252?Q?zw2bhibqc/HNkZfCxxqg61X7HxWyqE0ksEd/sA0kUmNKCG/vNmZRhgy+?= =?Windows-1252?Q?XHrSzV5Ea0yfKhrZXN/6qQLW9RfRE4A+yEu2vk76i7mMX5NFQXjI07Mv?= =?Windows-1252?Q?zrtYBUeh3nRHmBDFRf0Zax4GIx3N4AiWyOZ2jc133hxdniafCmm2fIxl?= =?Windows-1252?Q?xSNLj9rgBQ7wCq65T637tyRVv+aAxyEv+oOTtZLr/4bw5XocnfD6h5KA?= =?Windows-1252?Q?lQMn+zR5HPl6tAwiZIDCouMmrW49vkQO2Fp9xE0mF8+V0vchiO6JKTTB?= =?Windows-1252?Q?qDP1hOLS1m0dP2+O/3F0g2y0khxPBz1owt5jv11IIrhYF9K+51oYCIqu?= =?Windows-1252?Q?UKBer5Wn/TCewY5jKawzQGs4HKWas9+qvXrvQOEFok+7Y1H//JuPjEk2?= =?Windows-1252?Q?H/5Skf5mGg+xW5sF9OKqYYSgfiFj3fbBM4M+SXyqkqU2u9KrlhBqjBFc?= =?Windows-1252?Q?TQZaPdTj5uiq+JT7J2qCMEi5akf7OmOEYy3nhTBkCMKi0w7GJ+2SU11W?= =?Windows-1252?Q?+L3ag/p9ybERCISb7reYwtjff9hzTxCBCKTl2Yv1gf5torOPuwokXvEv?= =?Windows-1252?Q?bFabWW+tmv1uP4Af5Tdmk/Xj8lRM5RIa+rCb/SId7tCGmwg9DUV2Sfg9?= =?Windows-1252?Q?T9f5StegQzqYK?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR1201MB1107;6:pxYTHEbPo5QdjNgP2dz0o/BXK5gBpeh4x/h5jcDXB2Ved4lZatycVJMOUDLTdjy1CwdQT12Gb4Ofp43ryr8jka7hl2ddKXM9XtsjbtWyTPngTGcMrPto5UIf//V9rAsKVOWOdB4bNJG6DNJzPdVOE0LR7Ks4CUfg8PBssHkPTV9qN+WB6t+tKmq8iCWcj3E8hf+Xgw0n6b8kDNnhkKEVP2Iff7VF/s8sQd7pET6HNc3sVV3pQncSmghBShLvXt12RyJ0MBfjWLkH6c2Gt3ptK06VOKZYUbNBIQw54uq7d3QVz3zbGRDk90Md7+VK+QC4gyJVjua2+zG4bS+wvs2BPA==;5:4dvMGgv46FTzV7RpVWpD4wMDsRTizABM2kiqn6Wozna9NIt0F3o8XiBJpNMl5O6WpYvK+MqXt2o5kgwbU7ExhZCUmLtBCRpDiPspIEkhQbMGQ5UcPnS3MeAUMcVS4jbMcRAril51gMec8PmumIzbIQ==;24:TBaDK+puG9DYaafsctj+lZAUyWa7EWmYw3vZcEojIntNrovQY4pKk0J4h0QLq5/YWrN3IopUc1gnV8zi4chpPtT87iCwEbusc+O5G2Cz2nA=;7:bqVEZQX219gm8RxePfX2Ug2vojHTmYqq1aLJq4A8Zqn8TFSWkKXrVgqG++8FSA3qvQQ4XjjWlCpd2DqezYDEZfjnvtPdZOvetHKLe+2JLPXHV/rNERH1T3IOJdxXo7cu/cQWcXiDOaREFlaa72peFS9zj1MY71nbnx/F5fHg1pttzjK5g2o30cRTN96nagwjqgq/vppMJTxr4SB/C3xoVuCb/dBcHc/grA1w8RxIJZg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BN3PR1201MB1107;20:Jab8gxyAHSfjRglQ8OpJnTVZuQ/Iar5siqNNDUJ80L1urTjf0n5/+zkKmYPIhWXWd5TjzxBWpYJqhRyzdL9+sC4LKs0qcpT2SoW9pk28lzDvwrlzBYiklZs7Gp5qLk9BIj8pUwhHhzQpJAbRjFFhX3nXace773q6TYawh4xTAXe6xfq2swFzv+Zt7BxXZ+vOSh8Pzf0YTJkE7N4CPSLMBLQto26bL6kWTGTzlMSKprGx8V7Ssf8Ph0k+vK360rwJ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2016 15:16:24.0209 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR1201MB1107 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/13/2016 07:03 AM, Matt Fleming wrote: > On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote: >> >> So maybe something along the lines of an enum that would have entries >> (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could >> be added later as needed. > > Sure, that works for me, though maybe BOOT_DATA would be more > applicable considering the devicetree case too. > >> Would you then want to allow the protection attributes to be updated >> by architecture specific code through something like a __weak function? >> In the x86 case I can add this function as a non-SME specific function >> that would initially just have the SME-related mask modification in it. > > Would we need a new function? Couldn't we just have a new > FIXMAP_PAGE_* constant? e.g. would something like this work? Looking forward to the virtualization support (SEV), the VM will be completely encrypted from the time it is started. In this case all of the UEFI data will be encrypted and I would need to insure that the mapping reflects that. When I do the SEV patches, I can change the FIXMAP #define to add some logic to return a value, so I think the FIXMAP_PAGE_ idea can work. Thanks, Tom > > --- > > enum memremap_owner { > KERNEL_DATA = 0, > BOOT_DATA, > }; > > void __init * > early_memremap(resource_size_t phys_addr, unsigned long size, > enum memremap_owner owner) > { > pgprot_t prot; > > switch (owner) { > case BOOT_DATA: > prot = FIXMAP_PAGE_BOOT; > break; > case KERNEL_DATA: /* FALLTHROUGH */ > default: > prot = FIXMAP_PAGE_NORMAL; > > } > > return (__force void *)__early_ioremap(phys_addr, size, prot); > } > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear Date: Mon, 13 Jun 2016 10:16:12 -0500 Message-ID: <575ECE3C.5030600@amd.com> References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> <20160426225740.13567.85438.stgit@tlendack-t1.amdoffice.net> <20160510134358.GR2839@codeblueprint.co.uk> <20160510135758.GA16783@pd.tnic> <5734C97D.8060803@amd.com> <57446B27.20406@amd.com> <20160525193011.GC2984@codeblueprint.co.uk> <5746FE16.9070408@amd.com> <20160608100713.GU2658@codeblueprint.co.uk> <57599668.20000@amd.com> <20160613120322.GA2658@codeblueprint.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160613120322.GA2658@codeblueprint.co.uk> Sender: kvm-owner@vger.kernel.org To: Matt Fleming Cc: Borislav Petkov , Leif Lindholm , Mark Salter , Daniel Kiper , 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, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov Ard Biesheuvel List-Id: linux-efi@vger.kernel.org On 06/13/2016 07:03 AM, Matt Fleming wrote: > On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote: >> >> So maybe something along the lines of an enum that would have entries >> (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could >> be added later as needed. > > Sure, that works for me, though maybe BOOT_DATA would be more > applicable considering the devicetree case too. > >> Would you then want to allow the protection attributes to be updated >> by architecture specific code through something like a __weak function? >> In the x86 case I can add this function as a non-SME specific function >> that would initially just have the SME-related mask modification in it. > > Would we need a new function? Couldn't we just have a new > FIXMAP_PAGE_* constant? e.g. would something like this work? Looking forward to the virtualization support (SEV), the VM will be completely encrypted from the time it is started. In this case all of the UEFI data will be encrypted and I would need to insure that the mapping reflects that. When I do the SEV patches, I can change the FIXMAP #define to add some logic to return a value, so I think the FIXMAP_PAGE_ idea can work. Thanks, Tom > > --- > > enum memremap_owner { > KERNEL_DATA = 0, > BOOT_DATA, > }; > > void __init * > early_memremap(resource_size_t phys_addr, unsigned long size, > enum memremap_owner owner) > { > pgprot_t prot; > > switch (owner) { > case BOOT_DATA: > prot = FIXMAP_PAGE_BOOT; > break; > case KERNEL_DATA: /* FALLTHROUGH */ > default: > prot = FIXMAP_PAGE_NORMAL; > > } > > return (__force void *)__early_ioremap(phys_addr, size, prot); > } > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f71.google.com (mail-it0-f71.google.com [209.85.214.71]) by kanga.kvack.org (Postfix) with ESMTP id 522606B025E for ; Mon, 13 Jun 2016 11:16:34 -0400 (EDT) Received: by mail-it0-f71.google.com with SMTP id b126so105334875ite.3 for ; Mon, 13 Jun 2016 08:16:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0083.outbound.protection.outlook.com. [157.56.110.83]) by mx.google.com with ESMTPS id rd13si18298940pac.120.2016.06.13.08.16.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Jun 2016 08:16:27 -0700 (PDT) Subject: Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear References: <20160426225553.13567.19459.stgit@tlendack-t1.amdoffice.net> <20160426225740.13567.85438.stgit@tlendack-t1.amdoffice.net> <20160510134358.GR2839@codeblueprint.co.uk> <20160510135758.GA16783@pd.tnic> <5734C97D.8060803@amd.com> <57446B27.20406@amd.com> <20160525193011.GC2984@codeblueprint.co.uk> <5746FE16.9070408@amd.com> <20160608100713.GU2658@codeblueprint.co.uk> <57599668.20000@amd.com> <20160613120322.GA2658@codeblueprint.co.uk> From: Tom Lendacky Message-ID: <575ECE3C.5030600@amd.com> Date: Mon, 13 Jun 2016 10:16:12 -0500 MIME-Version: 1.0 In-Reply-To: <20160613120322.GA2658@codeblueprint.co.uk> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Matt Fleming Cc: Borislav Petkov , Leif Lindholm , Mark Salter , Daniel Kiper , 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, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Ingo Molnar , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov , Ard Biesheuvel On 06/13/2016 07:03 AM, Matt Fleming wrote: > On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote: >> >> So maybe something along the lines of an enum that would have entries >> (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could >> be added later as needed. > > Sure, that works for me, though maybe BOOT_DATA would be more > applicable considering the devicetree case too. > >> Would you then want to allow the protection attributes to be updated >> by architecture specific code through something like a __weak function? >> In the x86 case I can add this function as a non-SME specific function >> that would initially just have the SME-related mask modification in it. > > Would we need a new function? Couldn't we just have a new > FIXMAP_PAGE_* constant? e.g. would something like this work? Looking forward to the virtualization support (SEV), the VM will be completely encrypted from the time it is started. In this case all of the UEFI data will be encrypted and I would need to insure that the mapping reflects that. When I do the SEV patches, I can change the FIXMAP #define to add some logic to return a value, so I think the FIXMAP_PAGE_ idea can work. Thanks, Tom > > --- > > enum memremap_owner { > KERNEL_DATA = 0, > BOOT_DATA, > }; > > void __init * > early_memremap(resource_size_t phys_addr, unsigned long size, > enum memremap_owner owner) > { > pgprot_t prot; > > switch (owner) { > case BOOT_DATA: > prot = FIXMAP_PAGE_BOOT; > break; > case KERNEL_DATA: /* FALLTHROUGH */ > default: > prot = FIXMAP_PAGE_NORMAL; > > } > > return (__force void *)__early_ioremap(phys_addr, size, prot); > } > -- 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