From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932913AbcKOS3x (ORCPT ); Tue, 15 Nov 2016 13:29:53 -0500 Received: from mail-cys01nam02on0085.outbound.protection.outlook.com ([104.47.37.85]:42912 "EHLO NAM02-CY1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751081AbcKOS3t (ORCPT ); Tue, 15 Nov 2016 13:29:49 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Lendacky@amd.com; Subject: Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption To: "Michael S. Tsirkin" References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003723.3280.62636.stgit@tlendack-t1.amdoffice.net> <20161115171443-mutt-send-email-mst@kernel.org> CC: , , , , , , , , , Rik van Riel , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Larry Woodman , Ingo Molnar , Borislav Petkov , Andy Lutomirski , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov From: Tom Lendacky Message-ID: <4d97f998-5835-f4e0-9840-7f7979251275@amd.com> Date: Tue, 15 Nov 2016 12:29:35 -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: <20161115171443-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.77.1] X-ClientProxiedBy: YTXPR01CA0024.CANPRD01.PROD.OUTLOOK.COM (10.165.183.162) To DM5PR12MB1145.namprd12.prod.outlook.com (10.168.236.140) X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;2:05wvcvAAIP2RyfbM3wG5VIkMq6ZjUFzVKg/7qHR/QhU2mM2GRC7rivMaNxdwIeAgF5pBcJykhBly2iIQW9rDclXpGHIH3CAlB07oWcFNPiQVNWHDrfjjH+CqgH+Jz9lkFirktxA2srn5FfIWGfhQBdUKMp+Qb9JsWcnb0NgfceM=;3:6bakZhg1bRc6lpOm6/kky91jzBSDEug6lYTueH/JCo1CiQ+6WPM8EvJI8fZLdfMqKU4Scyxz9ebjQLa+UQws7pFDi2Hdv8exSfgtbu0A8z1wl0uQb1JdXjD0EclbJBDT1ssIw9FOvngi2B9RwV5znR1gcHgLN1R/dvZmOPmr9EY= X-MS-Office365-Filtering-Correlation-Id: 8cb5bb25-868b-46a3-5768-08d40d855dd9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR12MB1145; X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;25:CwC9qKaY/4K3lAcgu9d1ym4JiQyKmZ0tn0rkcJ84GVzEV5/kMJEq/TZqA8hJWSVc0+MBhfUNOAr6vZQZrAKp/gbmeFmYPB6kpK443jrRDys6uvjLRR4vxvptbLiefIf7xTHnsBVYQ/+cdpwghpJmSgR9v+Sm2wHNIVE7JGlPbIzUi54TYYyh8rB2E0fyD2+nGYoI59xhC7lvdCOFx2xBUROW/FxPVOOOEo88vscfIiqpmov+BeIdXxJ7R+Qzr6wGJHtSnKyGdEAFgYz4p/G3607Ktsxz20DbwCn/U+03+7DXr7lo2FhEuUgAAoLjiW674ZyZ4DOFfcLWR0ak7sRWnN0ZaztLUNfTEnLcbkMMuYzblKkI1rDe9er5LcY2i1PwUwcpahy/JCrAV7UDmUjkXqO4JwNKxgkwFhoGaH80HlErzQCCRvZH+/vA2VdyGuwpuwH5cd+rf/H4r66ACw7MCULabQpJa6dIRxsAbW5OXjT8aLPsH7aDQfDqCIxrvn5v2Sv00GhPLbqq+QTRcBMzW1823LI3aOXX/yCthBGHYhGcJUaAX0Yk392U2e4BSOx8cwamziEJdh497/aS6zP/XMTy5s9PhA9LkOxWA9kC/L8DWjHpw7V+YLdPB+P+At+wV1vVa2CXavOi0OQcOMNCDBb5TusT5vRr110fLot8BRImz4hqmqgK+8lxfmScyA8qY5TLfZo1mm+lRE1lQP/VrpT/9dyb6XYKLfsEw/ECnprGHWW7zA2SWxdMmKf1U1j7 X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;31:3rUvJsl/VMUxeKQGT7tTMl0kMzJheZOlR03pMHTl9MFfnEL+sb3un4UrywUVE3ZxahG0AEd0s4bFevrsAIiy2pFAK8Tn0BaHl22+3AMWGIHEl3qobK326Z3Xwi3zo52l8FBFn0uKuPh4llY5zOtNzYsTa6LuRU6ov9KswjhlvU0jMFicfdIYdm5FQpaOZTOQ09QgvZtnk/sCebzcoZHJBxIQY2BH2I+oB6LGlJKCuIkQFg4OFfXHEza+nNjm04IGg1wo741dvcfWE4J9Ck5x9lPI0IXtebm+Nfj1KQLZV9o=;20:LJGkeTrfQVDFCdhuWaxjowIhYlkHMTfexWPux0dk8dXsIm2kty4j9kGB/X2V4NvPksTMD2iwttUx014C4PUgDWobgezG2KvsI6SZLKwzHMjkvb7SDF4LYauDok4xGzjMWUmk+OKVBv9S1C9ynoVQ+tcM0hSeZYDdCNkQCF0bgLFVgqp0lEaHRkdF5qrw3gSb3oa+o/wIqCDaAhXIHqXhtYjHSg3TU2W/zdH2OeDPpbHURfcqfcAWby+VTtxszXNysYrRAOJC6FamWH9PjbtndQH/nggq5PPJCXp3/YCfCIp/Jbo3BwNN59ZRCEm/FMvxzNMUmcceNz7P4vySc9O8vKqM9CHVI/08lBxo6F5RJfc2OlcErHpG1V2RJN48a6vVt0h2RpJCrK9ohLEKEyLeK/q53GZADDk0VpqTsBC7JaxQVWlZauYbx/wGXNaz3poJ4g+0C22KNJwdaA0G/bzjRgxwQ8OXyRt0+nwWF1xWyMDsjZ29RtzE4aU8JwVr0k/p X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(767451399110); 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:mdaJRHZIboTVVOw70DmdcIM/FfBWUvAAFAKwpv7HlxmE4MdvEAvK+DDdYGQLTSZjWUTaGSeEI2CGHfpdGYx5222tOH5m2VOn+EXC7i/PnjyWqbuI5ZCVvrV/wqyx93XdkWE1Lygn9XYh99DgFGP6Pzkr5vlm93DR+sbUvIzaGoOkv/3bsqzGzp2y4M6qyuv1Mx3ufOyw15N8CiRQ1YHhlqfi+1Y5mWFQHghHem5GJSYQRPBOyQEyZT2VYmKtb2HM4rIYqB9xjTevW/8XZ15ALAxFHv2vlpQs8+dNWn3i2rePlz8fsxCt3GCe2fr2TpVpmTPkreZtJtVzNXcl8Af5IMQtRrPlw5yCC9SnVY9nAkh3axKz2hpL0/RSNIy8kBb8TPzgAbufYyje2LLoOzYWhiK24T6h46foFJExmx6LkEtJ/oKTuLQg/MVT5d9myfhwpkEwbRanaHGeGkuxyX/AQR8rPDk5eHH8WF6/Cs1dOmU= X-Forefront-PRVS: 012792EC17 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(377454003)(189002)(24454002)(199003)(6916009)(6666003)(2950100002)(83506001)(6116002)(68736007)(3846002)(7416002)(77096005)(65956001)(86362001)(54356999)(7736002)(5660300001)(230700001)(8676002)(7846002)(305945005)(65826007)(110136003)(2906002)(229853002)(4326007)(50466002)(81166006)(76176999)(23746002)(4001350100001)(97736004)(66066001)(189998001)(47776003)(81156014)(65806001)(101416001)(50986999)(42186005)(92566002)(31696002)(33646002)(105586002)(31686004)(106356001)(36756003)(64126003)(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: =?Windows-1252?Q?1;DM5PR12MB1145;23:50fLCvPGNzaaxvCCf/RljD8r7TIuTNMgW6ILZ?= =?Windows-1252?Q?GIE7vaSPsTCUs6wMn50o0lM92N6Wsay6W9EHvcfPZ3lClbAe/nESOIWP?= =?Windows-1252?Q?4H0wC/cH28TIUzgBxCTpVKbnb2xXqGb+rbULxgghNKtEk3Uu1ODPhT+j?= =?Windows-1252?Q?gSCwHxPVxu7R+6HsYhhF0gZhEPeeKyuZHPvuI99vAAnFuMvlJrL826fK?= =?Windows-1252?Q?8HC6+REovhnWHkt0b0K71JSDagU0ieY32qNx5obpGxMq/XxjCM2efwxD?= =?Windows-1252?Q?yVPncXY3Eeb0Z/NuCpQOcQg3eSQ/bI7WpcmvBQ04i8YDIX7bqtzClZ4R?= =?Windows-1252?Q?LH4aJsF5JDzpuiwS6zjZUTYQfWZ0hpZSIys7f8//KCGdtryOmHkBtMEj?= =?Windows-1252?Q?l4zPytISQ2cNtHj/THZ4+HjRWI/GRBvNS2BMwlcxthOAaNatC7Jc9Pff?= =?Windows-1252?Q?4CN5gwyhC3bH4gieXnEiulF7B1ZwXjV125nSdJuND7vlvQZ/P/5N5xZL?= =?Windows-1252?Q?KZ0UI4nSaq5hsZedPjnfWlpfw3dauQtjtDvLW6SIublFSqoEfziUtMoo?= =?Windows-1252?Q?H3diJpR7nH9za6rN/k1k2K6bVdH9TN6EDxB3RUdWWRVByun6FajY/yX9?= =?Windows-1252?Q?5vJyhJ++x3UuorK2YTBQlrLkeFw2F+08b8cNwrFwF5UzHagqgpM3zj7a?= =?Windows-1252?Q?mYTsekVScFUt95gtJBLvsTf3eb/30HVr0agpADauP0ImJ5JAYxLjn99W?= =?Windows-1252?Q?GAqPznmrScvmuMI/c+5aCIN33ClS7bse6m+LueX/SCc6vr83q6FDM5gw?= =?Windows-1252?Q?s2sNRdfqPeR5mj+abE3aHmk6TELUbQqcS5h7g0r15MU9GhQbmGilgZes?= =?Windows-1252?Q?MX8XV0ZfygRbwj9nmlmvAAI2mpX2V26xbOArpiBYJ2/W/vTwH0CbLIAH?= =?Windows-1252?Q?06OYfDDLYo+LwxxfiMe1L/PEiUFU5Je0FmdiDgs3yu4FPs1Z1DW86qyb?= =?Windows-1252?Q?BMu6Ora5yIRSDpdk6xi0LWrQo/UVof/hHsNvxEZUYv6zSmlxXCnIr0bH?= =?Windows-1252?Q?LXFhmYn84bumMOc30NFluSD+n4W8g7skWrw6LEWpRblqml5g/UnO/hkV?= =?Windows-1252?Q?nOz6vj8AzEUUgWk0Pk6cR8mcBImKtFhMFlN7tqubsTFnOb59kvktj8Oj?= =?Windows-1252?Q?yIGj3yYE3IRFxsRnbLiX3cwmse115XSwcdcmpYmRlqb1XH7Zo3MINb8s?= =?Windows-1252?Q?vfkji1NwIyduEIwZZLpWFv0k0/VSCxLwq2lvMcfVur6r/g2U+X9rNS2m?= =?Windows-1252?Q?7/uwXpxYgRqgPWrHgqcra7aOpgr1bagxoCwdTr/pdjh8sjSImIuHwB3h?= =?Windows-1252?Q?p2vZcvdqKa7kXxJ1iuie2f8qAawh7DizfZIp0zSC7271HHHaIZw4Ms?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;6:Wfus3GiJNASDhB8U54ZEF8k0u7khbPY0IHYSJG7bpwdMXFmq/WBS32fEpURXmLpSq26qemo/U+M3MlSMAh6UkZFYSM3ZGp93TP66dI0/OYkgxuleKAT9RruTWphAd+yKClYBhnl8+d8VtMnSnFz6Z0PRLXM2x7ETUIABVHSsHU9tilTdTa8GmrIwN4G0lCJa7SJeMiQE4Xsz3gjYUfYcSCMZV7jvju0n40hiCjs6D+++m4yevsDwtcf04D4iuD8k9ihV+3VjXDijB8dBVlsgo25mv6iGnZImYUqSs36KwJL6wZY6rcVrSK326N6jk4+h+hQFXZzQxckMvqMvsUNYCWkSQwgvg+AREKR52woYogL6owuYKgUWhamgaifirlh5;5:6j4uK1HRfuXxrhbRoCjOb6PedRGekpIy+PuH+QuTZYHLc0KKgc02lG195bRDWWVogG1DC0KOxOH+p3fT2aqsEsfcDchMJ3i47wU2IyvIGXxosNj0s727FksGxobvYSx8a7AADAKmG/TXa5H2fGo6OA==;24:9PF2XxYbEvkmgktmre3SqbY1G/Gx6s+9m1tDF8efs8fscrtz4BJzOMkbgF1sWr7jjFy6Xhx3K39JA+GlhyB84NnwDjc4NKBUqZX6l8ryMvQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;7:Tia4i9zx1+lniSM3kGC6lyzwEjjggdrIO6IepgMcuxkc9V3/DDrFVSykvQgE0YzNdyPHrHySBY8s3eU+nEujc0RetqcoanxaPAclx/xUps09h3tlBuC3O2ij2pfGRr+izaEm7L51WwC3dOfPM5vRKqLwJGNebZAGS/zx6wFpOBrbK6GK4x+2RZcx6qqRjPzOInh73REO+fneKyc6+o9XHSVDZXei1gLmGBwGZNd9dxNgksHl0NlhXWddGzcHbNzzEUZIpWlM14WBRh47fkjlpgGhxAF2YKsoCPzb9nR+XEnYpGhLNitatOpVoXOUZOi/+rmjmi8Tj0Kfys5gW9cEzAIFYysqSmPmRUbJvKiymW4=;20:jKifiNAEYsIVKm5rEXCSDbJ6cGgIXTZNOEzKitAj7OoCVJNgGSN+yC2K4FVw9C2rZv4xQ9nMAT9omV9utSpoKhdaCDTK6Diwl69DmKM0Pf6NTuj/8YPn7M4bai8PrmO/WpSgPxIHtI3W0eWCI7bZi55B1SebJRMShhT31O+r55IfK1ZAQZxzmSW/843XslImEdI2skapOtWQ0ZZx5JH039wLZ56aBwka2hGXUfK33xzHxwHd8LJi1Tu9ONAPpGId X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2016 18:29:40.0180 (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:16 AM, Michael S. Tsirkin wrote: > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does not support 48-bits. SWIOTLB will be >> initialized to create un-encrypted bounce buffers for use by these devices. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/include/asm/dma-mapping.h | 5 ++- >> arch/x86/include/asm/mem_encrypt.h | 5 +++ >> arch/x86/kernel/pci-dma.c | 11 ++++--- >> arch/x86/kernel/pci-nommu.c | 2 + >> arch/x86/kernel/pci-swiotlb.c | 8 ++++- >> arch/x86/mm/mem_encrypt.c | 17 +++++++++++ >> include/linux/swiotlb.h | 1 + >> init/main.c | 13 ++++++++ >> lib/swiotlb.c | 58 +++++++++++++++++++++++++++++++----- >> 9 files changed, 103 insertions(+), 17 deletions(-) >> >> diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h >> index 4446162..c9cdcae 100644 >> --- a/arch/x86/include/asm/dma-mapping.h >> +++ b/arch/x86/include/asm/dma-mapping.h ..SNIP... >> >> +/* >> + * If memory encryption is active, the DMA address for an encrypted page may >> + * be beyond the range of the device. If bounce buffers are required be sure >> + * that they are not on an encrypted page. This should be called before the >> + * iotlb area is used. > > Makes sense, but I think at least a dmesg warning here > might be a good idea. Good idea. Should it be a warning when it is first being set up or a warning the first time the bounce buffers need to be used. Or maybe both? > > A boot flag that says "don't enable devices that don't support > encryption" might be a good idea, too, since most people > don't read dmesg output and won't notice the message. I'll look into this. It might be something that can be checked as part of the device setting its DMA mask or the first time a DMA API is used if the device doesn't explicitly set its mask. Thanks, Tom > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption Date: Tue, 15 Nov 2016 12:29:35 -0600 Message-ID: <4d97f998-5835-f4e0-9840-7f7979251275@amd.com> References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003723.3280.62636.stgit@tlendack-t1.amdoffice.net> <20161115171443-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20161115171443-mutt-send-email-mst-DgEjT+Ai2ygdnm+yROfE0A@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: "Michael S. Tsirkin" 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 , Borislav Petkov , 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:16 AM, Michael S. Tsirkin wrote: > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does not support 48-bits. SWIOTLB will be >> initialized to create un-encrypted bounce buffers for use by these devices. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/include/asm/dma-mapping.h | 5 ++- >> arch/x86/include/asm/mem_encrypt.h | 5 +++ >> arch/x86/kernel/pci-dma.c | 11 ++++--- >> arch/x86/kernel/pci-nommu.c | 2 + >> arch/x86/kernel/pci-swiotlb.c | 8 ++++- >> arch/x86/mm/mem_encrypt.c | 17 +++++++++++ >> include/linux/swiotlb.h | 1 + >> init/main.c | 13 ++++++++ >> lib/swiotlb.c | 58 +++++++++++++++++++++++++++++++----- >> 9 files changed, 103 insertions(+), 17 deletions(-) >> >> diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h >> index 4446162..c9cdcae 100644 >> --- a/arch/x86/include/asm/dma-mapping.h >> +++ b/arch/x86/include/asm/dma-mapping.h ..SNIP... >> >> +/* >> + * If memory encryption is active, the DMA address for an encrypted page may >> + * be beyond the range of the device. If bounce buffers are required be sure >> + * that they are not on an encrypted page. This should be called before the >> + * iotlb area is used. > > Makes sense, but I think at least a dmesg warning here > might be a good idea. Good idea. Should it be a warning when it is first being set up or a warning the first time the bounce buffers need to be used. Or maybe both? > > A boot flag that says "don't enable devices that don't support > encryption" might be a good idea, too, since most people > don't read dmesg output and won't notice the message. I'll look into this. It might be something that can be checked as part of the device setting its DMA mask or the first time a DMA API is used if the device doesn't explicitly set its mask. Thanks, Tom > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.161.199]) by kanga.kvack.org (Postfix) with ESMTP id 14E4D6B02AB for ; Tue, 15 Nov 2016 13:29:49 -0500 (EST) Received: by mail-yw0-f199.google.com with SMTP id s68so324281799ywg.7 for ; Tue, 15 Nov 2016 10:29:49 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0084.outbound.protection.outlook.com. [104.47.37.84]) by mx.google.com with ESMTPS id o3si11778765otd.209.2016.11.15.10.29.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 10:29:48 -0800 (PST) Subject: Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption References: <20161110003426.3280.2999.stgit@tlendack-t1.amdoffice.net> <20161110003723.3280.62636.stgit@tlendack-t1.amdoffice.net> <20161115171443-mutt-send-email-mst@kernel.org> From: Tom Lendacky Message-ID: <4d97f998-5835-f4e0-9840-7f7979251275@amd.com> Date: Tue, 15 Nov 2016 12:29:35 -0600 MIME-Version: 1.0 In-Reply-To: <20161115171443-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Michael S. Tsirkin" 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, Rik van Riel , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Arnd Bergmann , Jonathan Corbet , Matt Fleming , Joerg Roedel , Konrad Rzeszutek Wilk , Paolo Bonzini , Larry Woodman , Ingo Molnar , Borislav Petkov , Andy Lutomirski , "H. Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Thomas Gleixner , Dmitry Vyukov On 11/15/2016 9:16 AM, Michael S. Tsirkin wrote: > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does not support 48-bits. SWIOTLB will be >> initialized to create un-encrypted bounce buffers for use by these devices. >> >> Signed-off-by: Tom Lendacky >> --- >> arch/x86/include/asm/dma-mapping.h | 5 ++- >> arch/x86/include/asm/mem_encrypt.h | 5 +++ >> arch/x86/kernel/pci-dma.c | 11 ++++--- >> arch/x86/kernel/pci-nommu.c | 2 + >> arch/x86/kernel/pci-swiotlb.c | 8 ++++- >> arch/x86/mm/mem_encrypt.c | 17 +++++++++++ >> include/linux/swiotlb.h | 1 + >> init/main.c | 13 ++++++++ >> lib/swiotlb.c | 58 +++++++++++++++++++++++++++++++----- >> 9 files changed, 103 insertions(+), 17 deletions(-) >> >> diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h >> index 4446162..c9cdcae 100644 >> --- a/arch/x86/include/asm/dma-mapping.h >> +++ b/arch/x86/include/asm/dma-mapping.h ..SNIP... >> >> +/* >> + * If memory encryption is active, the DMA address for an encrypted page may >> + * be beyond the range of the device. If bounce buffers are required be sure >> + * that they are not on an encrypted page. This should be called before the >> + * iotlb area is used. > > Makes sense, but I think at least a dmesg warning here > might be a good idea. Good idea. Should it be a warning when it is first being set up or a warning the first time the bounce buffers need to be used. Or maybe both? > > A boot flag that says "don't enable devices that don't support > encryption" might be a good idea, too, since most people > don't read dmesg output and won't notice the message. I'll look into this. It might be something that can be checked as part of the device setting its DMA mask or the first time a DMA API is used if the device doesn't explicitly set its mask. 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