From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762123AbcINNqA (ORCPT ); Wed, 14 Sep 2016 09:46:00 -0400 Received: from mail-cys01nam02on0074.outbound.protection.outlook.com ([104.47.37.74]:2601 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756072AbcINNp4 (ORCPT ); Wed, 14 Sep 2016 09:45:56 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Subject: Re: [RFC PATCH v2 15/20] iommu/amd: AMD IOMMU support for memory encryption To: Borislav Petkov References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223820.29880.17752.stgit@tlendack-t1.amdoffice.net> <20160912114550.nwhtpmncwp22l7vy@pd.tnic> CC: , , , , , , , , , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Andrey Ryabinin , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Paolo Bonzini , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov From: Tom Lendacky Message-ID: <27bc5c87-3a74-a1ee-55b1-7f19ec9cd6cc@amd.com> Date: Wed, 14 Sep 2016 08:45:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160912114550.nwhtpmncwp22l7vy@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: BY2PR11CA0038.namprd11.prod.outlook.com (10.163.150.48) To DM5PR12MB1145.namprd12.prod.outlook.com (10.168.236.140) X-MS-Office365-Filtering-Correlation-Id: 73ff6695-d8f0-40b0-83b9-08d3dca572c5 X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;2:TVcDXsOjvVPm/X4If0gDdkHJkJZIlIjJNGmoE1RZcNoC3BVmWr3Cu/eBqdPCIHJ0K4bXmTxOhXhj1IsYb1lv0Ppyh71ov0SjvUACTBWCiFzQ2hyGzWKBD4C22namYOV6K4NNvZA4lE9VhSqRw8EHIcDC+jpFuvlUhouunVqgHel3XTYMn4HVtkUAmPBYyB19;3:lcKdP3JzE5tiLj6Neq64oU12TuB3eyIV8BLmcmbkzdm7XBMdrn530+iy1JSyClJNkVxn43Qmp4WzKEArKBJ1JWvUp2wplWI7K/IBegklha0nOZn3PKCc0rjfoxpE3jbg X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR12MB1145; X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;25:FkXyY2hmWg/7YOgda3DoENC/u3V26GQ3sXoM6abd2DknmCsf36hBDTs+uIR45PMM9dpO8UkeNrP2nQgY3CLgj37Gjoz55BTM0MUkSSBb8be3zhorDKTjvStjK+14fwphxfEYXneN4IpkHfOL/QlPqN5G4E/W+AAfKgb345ViBZlMR1kPHKYVo5y9fhml5RL3evg0wFDSMpL3RdbrClzIhIYGXsGC/ifgH/uw+dFv8hcHGbZ59IDC1aEmZHBBwxn8/piLqYeHeC9EARF7BemZpauJcASQNeSG4i75cB8elXAkaAI+G059ErXD4Mzo2V5t9a1hXt/7EWdW0d/AYoNMDXC/y2o6szPvtmRcgjGDtmNus3BsgAE3AA6VZY9mA5wSz39Ro4dLTyWBMYSnxLtmvWzZU1ENSz2oAQgfr/XVzF+4pR8OIdOBgz6nxqTkqwFqj3b2nay8ypkW+mfNEQWvvYlTbbIBsj+WSU5KSe9pMwKlDYzyGxlTFI3Ve4cpzP0LuM6poHxGJUmzUB6Is2AwDLWy7RQaNw1mMy9eF9YODSGBUuKUHZ9pItm3NDqoB8tDP5e7ijRKu+fPdKOBIEq4mYnMUq21N2suVXE1JRkOUbhU+qAB0My/Yfd5zwxsz0LA+WRhTOaxajRTrnbqxNR9sCEl41z2BXiA9ta9UrP052f9yF9cbh1f6hFbZQbVtl41;31:RhISBgBqcmAB9IDEB6AvCzsXuKB90Vw648DKRvKRbBlXYo1Wo+z29Y276PsXbFu+MLI0toy4lGtBtl98MLPR6BmQhl69W6uioVD0F8o6yUdS4VMsCwZLxfLfsp6JjEXczy//4GsqI6mWB4Ur0JKXEGV3deJyHS6IQFL4SgJhINdMzebPiIBuhVyFWEmbKfF/LV1vMPwSeuMuKQszF6kZDZgtJpgTIb2kxVmpFU+s0ns= X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;20:r7XhcqRR8CKe/fx9Q85Zac3kh4PUkOGqQG16LRdn7E1i94VZ3c1YsZek4vaN3qeLvSJorZXTfMQJyXZrKL0FOmPVtg/ImDZbHrDeA/LyNUoLbB1qde1JdsvZ98RwYyaR72SFzw3QrLI9tUQeXSHHEG/hIoRQQB5nNS0fuIeW75vOHYJklA0I3q09x23TqAiZ3kcWRin5AO4DrgZogr2zPeAmMpKV/DIHL/yVOWO0SzRYZecoryP+IgBa5DLSn+gHuQhbSFzfxT+QfWgFjDdYssxbtVIEPRJos31FSJwMr0m7q4RKG7OAW1OLgqkGuLGC+aXyCEZH9kjs7juL5p8ddaqyDK9rBLzkjXwQ/AbrYqhli4c8gAmiPRjCSj2w2I6BUPfiTlhkJrJaJlBciMmX1kRxO8CzVghKbd2j4L/GDcDQRF7UVYesFPQEmvO3IMbVLF+zOZd2KluKQatjDnDxT2bKsT6DThBLo4R9Z1L0Ro02mHEicoiUyfQVDaIzBaSH;4:C9raEUTPItf2/npxKwMMrNydI5iJHglzkiDM+GmPDrvHjGmiev4djZbqGcXpHl9l9Pcva89lzCiZWUAzYk41e5eRPnvlN3b/pjAMxFECQ8nafsAzv7GPIBYHZg/k6iMzsMEGGDuxlQs71HgCe9hXQLGfYHdxkg+oY6+Aovn8cQd0em6CGTmh9/lzWdwS+92Ktd/9KTZXcy0P3TIf/OZ5UCdMDT8MHKzyAU4N4vab/Zqon1DIIOGM9uXaFnHbK59SUjojWZSV7Z87WDb7PxdpqJVibdOmVHwxcnQV+Jf9luRSOBO+ToIH2mZWUqzSmSHJpObJlk97IEBpz74Gr6dNlMNTv21XuJojkhBmIzrnHGoS5uv4flkurHrJOjXYTtCGJ05yUqIZ88cWqef61jLiT+h5IH0QXvtszFdUHY0ecX4zOpQTsO7b68XHhCcBKKwf X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(767451399110); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);SRVR:DM5PR12MB1145;BCL:0;PCL:0;RULEID:;SRVR:DM5PR12MB1145; X-Forefront-PRVS: 006546F32A X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(83506001)(36756003)(2906002)(4326007)(19580395003)(19580405001)(586003)(64126003)(6116002)(42186005)(3846002)(230700001)(50466002)(92566002)(81166006)(7846002)(81156014)(33646002)(7736002)(106356001)(68736007)(77096005)(305945005)(76176999)(101416001)(5660300001)(2950100001)(7416002)(4001350100001)(50986999)(8676002)(65826007)(97736004)(65956001)(86362001)(105586002)(65806001)(189998001)(54356999)(110136003)(66066001)(31686004)(23676002)(47776003)(31696002)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:DM5PR12MB1145;H:[10.236.18.82];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjEyTUIxMTQ1OzIzOk5aTVlrNmFaQ3Mrb1pZa3ZRSGwyaEt5dVEx?= =?utf-8?B?LzNUYVBaWGlWVmh5ZzZ5V0lnZ2VXbDRFVnhvaDBWWUZSVFdvQUQrSnFQTGRK?= =?utf-8?B?ZnhXVDNUdm9QUTR3TFpzK3R3L1VKZ0R5czJvZ0NtWTlMazBXZytTemhVWDlw?= =?utf-8?B?aGNKQTBCSEliSnVFN2tjS2NMOW9kSTVRZWtrTnRiREhLNzBnL05jZUJXR2Vv?= =?utf-8?B?d3B2U2RFSWxWZXpEYUVwcUxHNENydDdVTGZtUm5nUUhXMEtvYzVycDFzM3Vi?= =?utf-8?B?UmE0T2JzVWZ6ajJySlVzbjBCdEdGK0ZBT3c3ZlI4VE1pK0hVUnFoYXlBM2Jn?= =?utf-8?B?WWVYVG5XUXZ2MG96RUZtWjZQdkpZUW5VOVpiMDdNd1JGcFNQY1U0a0dCMU1C?= =?utf-8?B?MTNKUHNCSDNLWEkxZW90S2NkVzQvNXFPVEpyNDNGVWpiOEd4d1hXUWkxMi9z?= =?utf-8?B?SUI3WW1zaG5jVDB4SmRZOVBiVTVvSFJnYUxwb2F5YkxVWVYxa1BEWlkxMnl4?= =?utf-8?B?L1BRcjFsWTZUTW5oZjh5WXpZMDN5YVZ4eUtmZDJ6anNvSG5TeUhteDV4V1Uv?= =?utf-8?B?ODljNGZJSzJiYVR1eE1XdzBHbm5TcllhSkpxRkR6UFMvdjc3VWVSRDdFcVgz?= =?utf-8?B?VXpCU0NRell6V2c0R2RFYmlOTzh0cGJZcGZQcFcvalYyMzAwaFhkSWRGSGt2?= =?utf-8?B?Y09hVXBtY0xoNm14Vkthc2N3eHVPbE9VcUtFUUdLcUJ0TFhOdWtZTWR3Qkx3?= =?utf-8?B?UllMd2VHZTZtTlIwOTl5aXV5TUlBNEhKd01NNHhzdHk3d01FU2xuOUFmTlRu?= =?utf-8?B?d2Z0cktpYisxTE5KL1A2Tmo1WW1nRm5DYk1LVXpVN1lyYTJ5VlZnQ25UUGwy?= =?utf-8?B?S1VpaTk4eWNkMGVEUmh0bVZNUFMxTnZTbHNYR3lhKytLQ2ExTkVJUzJMUkZt?= =?utf-8?B?QTN0ZzhVaTBRZG5rM3dkb3E1Tzl3ZUxSaVlMVWdEdDljUUpYK01jTXQwNVdE?= =?utf-8?B?cUhtNnRUeWNLeFIxeUJGYzhPcStPcW9zV1dkRjBLcGpCUk44YnlkWUJkbzJt?= =?utf-8?B?VlVsODZiYjRoWWM4dm5HMTFJaXM3ZFFhN05VTTFIQlFsSHlPWlhuNXg5N3A4?= =?utf-8?B?L0dGN0Y1Tk5Yamg0TGdjREtwS09zOFJOYVVXY1ZTZVBsb0QzQkVPVGQ5NkZz?= =?utf-8?B?bDUrZjFsUWlpdldiMXZQNnFPYmptNEtYamtoWlJqN1FIK2hicjVQQTc3bXgx?= =?utf-8?B?OVV0Y1htWkI3N3M2bGN3MlpBYjRkUmNqZmdiamVWeE12cENZa2tzdXRxWG5w?= =?utf-8?B?UUJ1a3d3U0QyUkJjQlBhaGRYV1YvNDJBVWovR3pCd2hlak9oWGZhV3djaUh6?= =?utf-8?B?WWlqUlNhcDZsZ1JkNnZaNGszajZmdzh0Z2IwVEFXdVlvMUVGR0NPaGJMdXVT?= =?utf-8?B?YW4xWTBmSGs5TUJ0WGd2RUNEc0JDS216YjMraEhzTHg3b1JSNXd5dERqL3NE?= =?utf-8?B?ZVdVUkFmaXVpamJIZzBZeWJqTnB3MFNwUUV5WDdzcnkxWnQraWE2MkhRa0hu?= =?utf-8?B?N2JMb3Q1b0ZUVVBDN3JnUzhuWnZQano5THNuM1NIRmdHeUZhRW9leXRlQ25J?= =?utf-8?B?eEtKTjloZG1WanUvODNZMStkd2xOR1FOK01SQjQwUzNBeFpBM3pjZHpXSnU1?= =?utf-8?B?U3Z1b1Z5d2xlTi9KU0FxSVVKbUlHeGpXVlZKQVgwRmtKQlVRQW1DRVNTR3VI?= =?utf-8?B?bHFmT1JhRHNNZ0RjTWR2Q2VHdU5LOFE3MU5WNkhSS20yV3RZOVoydXFBMTdU?= =?utf-8?Q?AocngypWb1p51?= X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;6:kv4nnsuJ0RhswPvZCUShnhubOLUaAVzG3OMkh3pLv9WSPHiHkjyY3GFgY35snW7BRZMIaumgl2RhD8n01yYE62ZwxnsR93S9ogg8m2BnXM/aLG7SULYGJnQYKUZodD8pkQgPgJJaOn8WA/UU3uKnFVmYZetEeBzIozuXfRUTkU1T9smoATg+JwlIgfcX2nm1CkySBNU1rseRJoY2B4l2vT7Y0N9Ha47USr0MnpMDZjlPzW2vQmso1ivbOKLf+tvgirIIM8i+ig92gpeGuDN14Zjp7YuCOhgAECaiXVAlGx/xxk/SKpQgykdXJ4wFI/h9wAJCT+PZ/bA6isFTIz5CTg==;5:LvIiQdJ0AVDDNp1LUn5wwlNbbiKfZ1Fg9Zdd/Bf4670LfyEBRJPXi12BmUbmTxKiB8O34UfO1mta7AxqBFn2pDvjmePkuK0NysHDYB6CDLwzDRPx9j2Vt5VVgIrQGARgv6JZXC3fpCOY2OT1xewcAA==;24:sUQk/X4wBbXzhRh9yNGrl34YJnzO2l8C71y9c0Iw83DEulTldUU/qlm8mDQDjA2L1g0OzUMFer9zg2SqaAOKuAI8p0iFgk0tjotc6HHpqPE=;7:MoYOhSA2w6j6VLvcJY9WgpKGPcqBimGIr0DP3gwOXHsT7vetDnh8QadraqAV2bHKATjbnxuCYG3+vK1vhfCrTKV03ehhnR6ri1F3wvTOCdLBAJ5jOzFRXXoTzDsQZ5FYCnxvilU6fddkWGlNQdLPFVn6A7iW+OlOk4t/vTfRkX8bzqrqrIt1f/f44rm51SJQa93P4SJxWRrDIxPetnf4Xeu0RJmbnF/TJnYA3IeyNjFZzuJfDrbiU67aPCeY+oOS SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;20:djK9NYs3J+D57P4Hud6VzuzaSSri2+1K9LQJEFHx23TqYRBfiV13yiLr050gVMGBcWvLLj2WaZLIHZc+eD6XaybuVnHJngqGboVnVSYc+hmEPzZ3ZSd9m8uJVE7kD2EG53CCnCL3uClzg24V5GzrP7akrV91e2NjMkkWEYgTEDCp9TTk+1pVUHxoyz3t9404hj1ELU75GS2O04QFegcpPy7jv21viS9TDZRxJ0yZp6FA2d5T3O+10hT8ddVM5d7+ X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2016 13:45:51.9754 (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 09/12/2016 06:45 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:20PM -0500, Tom Lendacky wrote: >> Add support to the AMD IOMMU driver to set the memory encryption mask if >> memory encryption is enabled. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/include/asm/mem_encrypt.h | 2 ++ >> arch/x86/mm/mem_encrypt.c | 5 +++++ >> drivers/iommu/amd_iommu.c | 10 ++++++++++ >> 3 files changed, 17 insertions(+) >> >> diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h >> index 384fdfb..e395729 100644 >> --- a/arch/x86/include/asm/mem_encrypt.h >> +++ b/arch/x86/include/asm/mem_encrypt.h >> @@ -36,6 +36,8 @@ void __init sme_early_init(void); >> /* Architecture __weak replacement functions */ >> void __init mem_encrypt_init(void); >> >> +unsigned long amd_iommu_get_me_mask(void); >> + >> unsigned long swiotlb_get_me_mask(void); >> void swiotlb_set_mem_dec(void *vaddr, unsigned long size); >> >> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c >> index 6b2e8bf..2f28d87 100644 >> --- a/arch/x86/mm/mem_encrypt.c >> +++ b/arch/x86/mm/mem_encrypt.c >> @@ -185,6 +185,11 @@ void __init mem_encrypt_init(void) >> swiotlb_clear_encryption(); >> } >> >> +unsigned long amd_iommu_get_me_mask(void) >> +{ >> + return sme_me_mask; >> +} >> + >> unsigned long swiotlb_get_me_mask(void) >> { >> return sme_me_mask; >> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c >> index 96de97a..63995e3 100644 >> --- a/drivers/iommu/amd_iommu.c >> +++ b/drivers/iommu/amd_iommu.c >> @@ -166,6 +166,15 @@ struct dma_ops_domain { >> static struct iova_domain reserved_iova_ranges; >> static struct lock_class_key reserved_rbtree_key; >> >> +/* >> + * Support for memory encryption. If memory encryption is supported, then an >> + * override to this function will be provided. >> + */ >> +unsigned long __weak amd_iommu_get_me_mask(void) >> +{ >> + return 0; >> +} > > So instead of adding a function each time which returns sme_me_mask > for each user it has, why don't you add a single function which > returns sme_me_mask in mem_encrypt.c and add an inline in the header > mem_encrypt.h which returns 0 for the !CONFIG_AMD_MEM_ENCRYPT case. Currently, mem_encrypt.h only lives in the arch/x86 directory so it wouldn't be able to be included here without breaking other archs. > > This all is still funny because we access sme_me_mask directly for the > different KERNEL_* masks but then you're adding an accessor function. Because this lives outside of the arch/x86 I need to use the weak function. > > So what you should do instead, IMHO, is either hide sme_me_mask > altogether and use the accessor functions only (not sure if that would > work in all cases) or expose sme_me_mask unconditionally and have it be > 0 if CONFIG_AMD_MEM_ENCRYPT is not enabled so that it just works. > > Or is there a third, more graceful variant? Is there a better way to do this given the support is only in x86? Thanks, Tom > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v2 15/20] iommu/amd: AMD IOMMU support for memory encryption Date: Wed, 14 Sep 2016 08:45:44 -0500 Message-ID: <27bc5c87-3a74-a1ee-55b1-7f19ec9cd6cc@amd.com> References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223820.29880.17752.stgit@tlendack-t1.amdoffice.net> <20160912114550.nwhtpmncwp22l7vy@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160912114550.nwhtpmncwp22l7vy-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" , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jonathan Corbet , linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Ingo Molnar , Andrey Ryabinin , 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 09/12/2016 06:45 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:20PM -0500, Tom Lendacky wrote: >> Add support to the AMD IOMMU driver to set the memory encryption mask if >> memory encryption is enabled. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/include/asm/mem_encrypt.h | 2 ++ >> arch/x86/mm/mem_encrypt.c | 5 +++++ >> drivers/iommu/amd_iommu.c | 10 ++++++++++ >> 3 files changed, 17 insertions(+) >> >> diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h >> index 384fdfb..e395729 100644 >> --- a/arch/x86/include/asm/mem_encrypt.h >> +++ b/arch/x86/include/asm/mem_encrypt.h >> @@ -36,6 +36,8 @@ void __init sme_early_init(void); >> /* Architecture __weak replacement functions */ >> void __init mem_encrypt_init(void); >> >> +unsigned long amd_iommu_get_me_mask(void); >> + >> unsigned long swiotlb_get_me_mask(void); >> void swiotlb_set_mem_dec(void *vaddr, unsigned long size); >> >> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c >> index 6b2e8bf..2f28d87 100644 >> --- a/arch/x86/mm/mem_encrypt.c >> +++ b/arch/x86/mm/mem_encrypt.c >> @@ -185,6 +185,11 @@ void __init mem_encrypt_init(void) >> swiotlb_clear_encryption(); >> } >> >> +unsigned long amd_iommu_get_me_mask(void) >> +{ >> + return sme_me_mask; >> +} >> + >> unsigned long swiotlb_get_me_mask(void) >> { >> return sme_me_mask; >> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c >> index 96de97a..63995e3 100644 >> --- a/drivers/iommu/amd_iommu.c >> +++ b/drivers/iommu/amd_iommu.c >> @@ -166,6 +166,15 @@ struct dma_ops_domain { >> static struct iova_domain reserved_iova_ranges; >> static struct lock_class_key reserved_rbtree_key; >> >> +/* >> + * Support for memory encryption. If memory encryption is supported, then an >> + * override to this function will be provided. >> + */ >> +unsigned long __weak amd_iommu_get_me_mask(void) >> +{ >> + return 0; >> +} > > So instead of adding a function each time which returns sme_me_mask > for each user it has, why don't you add a single function which > returns sme_me_mask in mem_encrypt.c and add an inline in the header > mem_encrypt.h which returns 0 for the !CONFIG_AMD_MEM_ENCRYPT case. Currently, mem_encrypt.h only lives in the arch/x86 directory so it wouldn't be able to be included here without breaking other archs. > > This all is still funny because we access sme_me_mask directly for the > different KERNEL_* masks but then you're adding an accessor function. Because this lives outside of the arch/x86 I need to use the weak function. > > So what you should do instead, IMHO, is either hide sme_me_mask > altogether and use the accessor functions only (not sure if that would > work in all cases) or expose sme_me_mask unconditionally and have it be > 0 if CONFIG_AMD_MEM_ENCRYPT is not enabled so that it just works. > > Or is there a third, more graceful variant? Is there a better way to do this given the support is only in x86? Thanks, Tom > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 901656B0038 for ; Wed, 14 Sep 2016 09:45:56 -0400 (EDT) Received: by mail-pf0-f197.google.com with SMTP id v67so30051929pfv.1 for ; Wed, 14 Sep 2016 06:45:56 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0048.outbound.protection.outlook.com. [104.47.40.48]) by mx.google.com with ESMTPS id 1si4834924pam.178.2016.09.14.06.45.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Sep 2016 06:45:55 -0700 (PDT) Subject: Re: [RFC PATCH v2 15/20] iommu/amd: AMD IOMMU support for memory encryption References: <20160822223529.29880.50884.stgit@tlendack-t1.amdoffice.net> <20160822223820.29880.17752.stgit@tlendack-t1.amdoffice.net> <20160912114550.nwhtpmncwp22l7vy@pd.tnic> From: Tom Lendacky Message-ID: <27bc5c87-3a74-a1ee-55b1-7f19ec9cd6cc@amd.com> Date: Wed, 14 Sep 2016 08:45:44 -0500 MIME-Version: 1.0 In-Reply-To: <20160912114550.nwhtpmncwp22l7vy@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: 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 , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Andrey Ryabinin , Ingo Molnar , Andy Lutomirski , "H. Peter Anvin" , Paolo Bonzini , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov On 09/12/2016 06:45 AM, Borislav Petkov wrote: > On Mon, Aug 22, 2016 at 05:38:20PM -0500, Tom Lendacky wrote: >> Add support to the AMD IOMMU driver to set the memory encryption mask if >> memory encryption is enabled. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/include/asm/mem_encrypt.h | 2 ++ >> arch/x86/mm/mem_encrypt.c | 5 +++++ >> drivers/iommu/amd_iommu.c | 10 ++++++++++ >> 3 files changed, 17 insertions(+) >> >> diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h >> index 384fdfb..e395729 100644 >> --- a/arch/x86/include/asm/mem_encrypt.h >> +++ b/arch/x86/include/asm/mem_encrypt.h >> @@ -36,6 +36,8 @@ void __init sme_early_init(void); >> /* Architecture __weak replacement functions */ >> void __init mem_encrypt_init(void); >> >> +unsigned long amd_iommu_get_me_mask(void); >> + >> unsigned long swiotlb_get_me_mask(void); >> void swiotlb_set_mem_dec(void *vaddr, unsigned long size); >> >> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c >> index 6b2e8bf..2f28d87 100644 >> --- a/arch/x86/mm/mem_encrypt.c >> +++ b/arch/x86/mm/mem_encrypt.c >> @@ -185,6 +185,11 @@ void __init mem_encrypt_init(void) >> swiotlb_clear_encryption(); >> } >> >> +unsigned long amd_iommu_get_me_mask(void) >> +{ >> + return sme_me_mask; >> +} >> + >> unsigned long swiotlb_get_me_mask(void) >> { >> return sme_me_mask; >> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c >> index 96de97a..63995e3 100644 >> --- a/drivers/iommu/amd_iommu.c >> +++ b/drivers/iommu/amd_iommu.c >> @@ -166,6 +166,15 @@ struct dma_ops_domain { >> static struct iova_domain reserved_iova_ranges; >> static struct lock_class_key reserved_rbtree_key; >> >> +/* >> + * Support for memory encryption. If memory encryption is supported, then an >> + * override to this function will be provided. >> + */ >> +unsigned long __weak amd_iommu_get_me_mask(void) >> +{ >> + return 0; >> +} > > So instead of adding a function each time which returns sme_me_mask > for each user it has, why don't you add a single function which > returns sme_me_mask in mem_encrypt.c and add an inline in the header > mem_encrypt.h which returns 0 for the !CONFIG_AMD_MEM_ENCRYPT case. Currently, mem_encrypt.h only lives in the arch/x86 directory so it wouldn't be able to be included here without breaking other archs. > > This all is still funny because we access sme_me_mask directly for the > different KERNEL_* masks but then you're adding an accessor function. Because this lives outside of the arch/x86 I need to use the weak function. > > So what you should do instead, IMHO, is either hide sme_me_mask > altogether and use the accessor functions only (not sure if that would > work in all cases) or expose sme_me_mask unconditionally and have it be > 0 if CONFIG_AMD_MEM_ENCRYPT is not enabled so that it just works. > > Or is there a third, more graceful variant? Is there a better way to do this given the support is only in x86? Thanks, Tom > -- 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