From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751897AbdFISg7 (ORCPT ); Fri, 9 Jun 2017 14:36:59 -0400 Received: from mail-bn3nam01on0045.outbound.protection.outlook.com ([104.47.33.45]:8417 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751667AbdFISgw (ORCPT ); Fri, 9 Jun 2017 14:36:52 -0400 Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=amd.com; Subject: Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3 To: Andrew Cooper , Boris Ostrovsky , linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, iommu@lists.linux-foundation.org Cc: Brijesh Singh , Toshimitsu Kani , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Matt Fleming , Alexander Potapenko , "H. Peter Anvin" , Larry Woodman , Jonathan Corbet , Joerg Roedel , "Michael S. Tsirkin" , Ingo Molnar , Andrey Ryabinin , Dave Young , Rik van Riel , Arnd Bergmann , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , Juergen Gross , xen-devel , Paolo Bonzini References: <20170607191309.28645.15241.stgit@tlendack-t1.amdoffice.net> <20170607191453.28645.92256.stgit@tlendack-t1.amdoffice.net> <4a7376fb-abfc-8edd-42b7-38de461ac65e@amd.com> <67fe69ac-a213-8de3-db28-0e54bba95127@oracle.com> <12c7e511-996d-cf60-3a3b-0be7b41bd85b@oracle.com> From: Tom Lendacky Message-ID: <9725c503-2e33-2365-87f5-f017e1cbe9b6@amd.com> Date: Fri, 9 Jun 2017 13:36:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [165.204.78.1] X-ClientProxiedBy: DM5PR16CA0036.namprd16.prod.outlook.com (10.172.42.150) To BN6PR12MB1139.namprd12.prod.outlook.com (10.168.226.141) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN6PR12MB1139: X-MS-Office365-Filtering-Correlation-Id: 5c37b198-5600-4a97-fb59-08d4af6678e2 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081)(201703131423075)(201703031133081);SRVR:BN6PR12MB1139; X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1139;3:xoHGHI/QFgMFCiYCuczlirugd0lEESXmvjb7br2Ex9/kR1ncMH7P1pAbq5N3RepWuMfRvblprK9Q8pL6e2c8IFYt53q4tajqktkW5yQx0FmdpcLG1HzuZMxcjdhjvn2ow0jzL8fzsC8GIEmsbxoNtaHAGmPgz4th6Skc0Yoelu57as47hxE9ytV7Rp9QWE/N9GPKL7mNgt7yHRgZVpUbf4it3wIW7FWdXEKj/2GUCJ0tihph0zqyJ1IBlab4I3AXtz3x+lvjhIVguR0Y2F+n8edx1N4RRGL9GmLPfApOVN/7h9HGiGUtv7xu/Ii0vpQwUNwY29phu/lpcwNC4QeAcmwmlFs2g+mUwwuRM24rRUo=;25:p4RB9u+C4Z6noqdL5BgtCE7QTiy9gY9YPLZHQGmUSqhLsicU8BRHL/p48Sew4/dNbe+UB9v4ctU31V5oA9ZkKt8U9fYXDgedNd7iyU/v4EL34O7wdsq66slUkf0APpLd8vRlO1WvcynDce3OOGlFZyyv8wmnu2f2gYoO2+GxRymNpyk49wwvh1QcsOyNPiReg72Z8HR4CHmZZpLCd+xSSJN0FT0g8BsRaW4y74d1fM2xS94z7b2whL6YztE+VxjtmKm3NKwYf8FWvOkUqaUd8B5G2H7rFhd/aSieT3bgnuevsEt7puwF2O/Bar82Fs0sI4l/UJBUv999iOwMOFIzeTwIR8IkYCRnNsgAd44EVjQeGfrz5kDysJ31wL3ZGPGS3lqlZ54z8fCobJUBnRz9RiHt6S3tpDgUfHCpRFogKc+20A9bPcKUg4cCTxiCgtct37j6iEBq1066aITgkj2DcL54CcWykktYF8koqRkeV00= X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1139;31:UKkOouyTUn6HUD5/nsRZ8fDhefPFTUfMRSPo475VPnFbrTPQGlAEJITgWs0iMFZbicvy2AdzXVhNtS2db3fhRgBHQwWHqo5rBV0du7CqbzHzpiO3RUvuRcDZugwX/AR6xhIrdDon9f96GonMIQm5NjyKweevx9ugRkU3AExlwqeuf8ibtiWdfxzjTuzlXlftWZlEh3CJbUehH4qY3lk74FecFoXD5arRyCEgPz8/Las=;20:+0wgJNuy387ZzHJXYgfBlLdVLu1znvh0qYtRSjp9YDtB9tY2hKzrFQqMXpgKwmVhveSxfZV9K7c2mVPPkgsGda03PH1GBQ+KuagiTG2N1sJulXj1+rzamRVaDLHuzUmwdOoX3dx7TcLjTe4Vg7XYTvQT6k3DTGO3gRfLiKlP3I/OZVhN5WeaU8qA++SgUdY0XyK1U9hlF1ZqvXV8K1BJtWiRkzquUsTbn83/Gx/V3OzEolxFNM1+PONwntkHzvfPYQmyDl7Xh5IrgXgKTkWYO/a7T/STzIvdVOgMKYHmJ3kQGsBqv7TMIPxE5HTr0ZpEQQZ19SM+3AZ54Sy0IVKjvyqScIvoDYwobwrYnYIL4pNoT309xJZEc0ztgrU+L+ZnRf3cDIHbm2SKGPY9t+ZxiuU3EAXeSWWS3DrhfMW+KRo8pXVyKPmJtLxDAq7iDD/4uhS/c1O58zAgYA7oWVMG0iDsImVpN/4Ak/IdU3cjKbad/LPkCVljq318FaFFy0fn X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(17755550239193); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:BN6PR12MB1139;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:BN6PR12MB1139; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjEyTUIxMTM5OzQ6S2psNVhmVUhLQTl1REdQSFBPNURLTjYxeFhj?= =?utf-8?B?MGtCQUIrNmhCeERaS25paXVrek4vRUJONUxWNGU3VzBTSHRYcVBTaWZxalAx?= =?utf-8?B?S2ZaSFZUWlIwL0hjOEFBMzdCaVNlb0EyckFFeGU3TU40U2VJeDZCcHVEMHBM?= =?utf-8?B?MTZDbEVsa2VndTlBbXFJK2dWdmtTbnFhZUtMRW9wUUlCTzcycStOQUZrTElj?= =?utf-8?B?cDJMck0wQVY2bkpyRGlZRGROWUNITjQvWFJxVkJ3WkFlSlM4OWlWcU1Rc0hY?= =?utf-8?B?U0tNdnRmRE9UREs0ZG15Um9WUnhBcXlSY1l6ck1rY3o2OEZiYnc2enJVVGsr?= =?utf-8?B?RnVrT2FoYWpMMTVUQUNpeXRwRVdGMEJOR0ptU2FaaGwwRWZTR29lemZOMDNR?= =?utf-8?B?MXE1aDBnRmt4ZExmeU0zOWdqNUx5OHRwYmFJdCtpajE0OGVlbVRRQjNZcTFQ?= =?utf-8?B?L0o3M0R6eFpUaVRsU2dpWFNSYUtyRTI2VS96d0VOUDRIQkpNajg1dDBOWkVr?= =?utf-8?B?U1oyeTAyN1o3Mm9UWE1ac0Rsb05uRFN2dW9jZEl5Y1o3TTkwQ2xPdVcyZ0Uv?= =?utf-8?B?V0t5a05ld1dTTGVLUDBTQW00bStRa1hFNnNIMS83YWM3YUtydlFqYlA2UFg0?= =?utf-8?B?Z1RkZ3ZLa1F6eXVKWVFTUERYNlRUQkUrL0RuVVZzR2pRWVN5d2xEVFlTMFRJ?= =?utf-8?B?K2gzVmdIMlgzekk4SGlCNjNZVHQ0N29hT3pDdk9sLzNMQmIyYVhzV2JFeWdG?= =?utf-8?B?SjhnMDY4S1V6QVVQb3RERnk3dWlCWStEaVk2VFUyYnFXeXBnT2k0UW0vK3Nr?= =?utf-8?B?d0ZQYjRGbFB2cE1ESnlRbFFVSXFoQnN2NzVJZjZZN20vRDVMRmlXWENSR2h5?= =?utf-8?B?RjlOUk5PUDJtNms0VUdqWXYzUlVoajdvaHMyME1JRFNiNU9uMFlvK0lBZ29O?= =?utf-8?B?NFFHQnRhV2xRNnMrSHEwQ2liNTFwVDZJaW5pZlBaNDNuZ0VvNVNCV216SUNs?= =?utf-8?B?VXJVc2QycDNUQXpkZkNlQnVKUmlGMVFRT3I1VVdiMXFBTW9CMTB4YXNvbTJQ?= =?utf-8?B?dEdsOVRZdWZROHRZNTUzcWQ3b0ZDdXZRVUlQL3JaekNZVnh1SExHbFQxWXlO?= =?utf-8?B?OUVTdWdPcjdNNXhiY0IvY1VIelo3ZXJKUWdTdHJrQTZPSVNZYzY3QTZpNG5O?= =?utf-8?B?YVFvcUc3a3dhcWwzYVJNQjBCaU45SkJBdWJWdEgzVEZIVytsd09CZDljOTk4?= =?utf-8?B?TFFaOWhyODhRSm5waWZUbkdRMXlrOVYrcWozM2ZsZmhwR0NxOGhmdWx1YVZL?= =?utf-8?B?VGlXMFdTMWhJcll1aG9DckRIcHNnWldRenBkeGJTcThTZ0l3RnR6bnkwek1k?= =?utf-8?B?OUJseUtiY08yRHd2Ri9ERlVWSEZQUDJscHpmUWdjTW5vZnNuZXhFajFjbzg3?= =?utf-8?B?RjlGOW1naDB4OVlpUmhZMllMQVN5RCs4U2E5cVNlamlmeFpJZU9uTUI0dG96?= =?utf-8?B?UldETUhJZVZKWUpxWnNRUkxnRThCS25NU1FjSkxsb0Y3cnlJbEN3cTlYUEVz?= =?utf-8?B?V2U2OHFuZ016bTNucitBZTJheU81aVR5dDVELzJHRWQyeUI2Z1NRbGk0MUdG?= =?utf-8?Q?L3MJ7Hxc+zbYZFosCSi?= X-Forefront-PRVS: 03333C607F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(39860400002)(39840400002)(39410400002)(39450400003)(39400400002)(39850400002)(377454003)(24454002)(72206003)(64126003)(7736002)(305945005)(6666003)(478600001)(2950100002)(65806001)(230700001)(50986999)(229853002)(93886004)(31696002)(47776003)(54356999)(66066001)(65956001)(86362001)(76176999)(8676002)(3846002)(81166006)(2906002)(4326008)(25786009)(53546009)(5660300001)(3260700006)(42186005)(53936002)(31686004)(36756003)(65826007)(7406005)(33646002)(8666007)(7416002)(54906002)(189998001)(38730400002)(6246003)(23676002)(77096006)(90366009)(6486002)(921003)(1121003);DIR:OUT;SFP:1101;SCL:1;SRVR:BN6PR12MB1139;H:[10.236.64.250];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjEyTUIxMTM5OzIzOlFndkI2MEVtdnlweGlZUFRGS242Tzg4QXo5?= =?utf-8?B?SG5yb3NJaWx2WTBpRXFQakFlVHk2SWlWek02NmNnZXk0dHJxSEZDOHZhbGxW?= =?utf-8?B?ajdQRHhveGpqMVdiS3dXemY1aHZiSVRJN3FIYUdrS01YUnB3cjUveVlSL2pS?= =?utf-8?B?NkJvM0ZhMmJwbWVTdmFSU0R3NzhYeGEwZDh6czVZbU04cnNZWmhNYndrTnBm?= =?utf-8?B?N2pjWklXUWprVzJqNzltaDFEd3l0V0JTM0srNTg5cEd2M3JNa0E5V25RcHRQ?= =?utf-8?B?SmFKMnNlanhIRXJ0aE5uR094MnBjaEpSSHU1OS9rOU02TzdnVWhUYXgzRlAx?= =?utf-8?B?bFlVR1YwVGhJd084Z1RrbzFKallDaVdGbTNGK1pnb0tnN2lQY2FqMFdYRWZn?= =?utf-8?B?RTlxYnJ1NUFtN0Q3YmNlYUdHb2dxUW1PZlN4T2ZOYVlETllHNE9jb0hFdmUy?= =?utf-8?B?bHZRdVRUM1dKQno2ZTdBczJTSUhuTTdDQTZiZENsbExSTi8xV09wY0E1WGNC?= =?utf-8?B?a2VHYjJPbytFZWh3dm1ScGFWY3BuNkZhNWNkMmtGcEVITHRadURwak5HcXh6?= =?utf-8?B?dzhmaWJMNVBENkI2M05YbHV2L3BnVU1FZUpxV1ByYis1Y2pMKy9ibTBqUldK?= =?utf-8?B?VXl0V2NqMmJld3ZCRG40ajA5Vkp6OFdMaW5Nb3hnTkZQMnJXTkl2c2gra2tF?= =?utf-8?B?cDB2cnNxekJ2VGpxWVpCcjlmK2ZvREhwYWJMSzFHOTFYNEJueG53bSt3ejUw?= =?utf-8?B?bXhQWEgyQnZ2VHY2Tm93S0JORzkrQ1ZJblF2b0ZpamZDV3loQnpEYWsyaElU?= =?utf-8?B?Z09UMjd5N2J5Y2pYWnBMQ2M1bXZkUWNmdllPTFJWYllHaExDMGRybHBTZEFp?= =?utf-8?B?bFBXSUN4cXh6aEtzZFpOeE1yTGJFdEJpSnlPV1FhN0QxMHB4TUJZRUFiZXBy?= =?utf-8?B?ZEJDelNmZkxlanlFT3R1VndJSTJ1V0ZWYkU4dzNad3d0RENvMmI1d0dIMFcr?= =?utf-8?B?WGhUZnI1NDF2bW1ZMjRyTDlFMHRiZzZjVE5jRDdUaTNiRGlSdGlYdXl0MGhP?= =?utf-8?B?cVdIMzRqVXZOOVBCQ0k0eFUxQ2llTjVXVDJQNG5PRlRiVkxDOFBDN2xCQklz?= =?utf-8?B?bzJzNSs1ekh6eENLMzRubzVIM0V0dDQ0VkFEQStsNEZnN2xmQSt0NGpoSXdD?= =?utf-8?B?VG1pUjRXWG1taGtFVkJLWkh4bW9OY1YxdEswYnBmenpoTS9ZUmJvN2JFUzFQ?= =?utf-8?B?cHRQYklYVGVyWkdNRVVOZ05zUHhRWmd1STJ5NTRyRTlsSUhIRkdLK0p4MkJN?= =?utf-8?B?VzhOdzJxaU1aYTgxSnRsMVIzM25NYStFQW4rYU9BNXFNMjRsWkZZOEkrcXF3?= =?utf-8?B?NWE3KzNQY24yM3R4aExYS1ZabFF2NVlGb0I4OU5LNHYxNFRQenVDQWRmM2VF?= =?utf-8?B?aHdCRVVoRUJxSjJ6eTZQbTFZd1R6TStJRGxyNFRlS3RuMlliV1dNUytuK0k3?= =?utf-8?B?WmdLUUFDODhTMjF0ajI2VDhwa1hOZXNwNUNNYjZwcDV1RlB2SmFVOEJFNXFQ?= =?utf-8?B?KzBnY2k4R0UwUTZIVmZraG9uTlFhWmxucjVzaWt4akpXUXUxQmNSV2RLdUNs?= =?utf-8?B?azlvYnY0Ulp6Nnc5aTFSMGVEdjJkMDY0VVE0SHY3aXZjOHVUQ1FiZjdzenZF?= =?utf-8?B?QmVDMmlsMHBkK1NDMVYvMFJVaVNjd1VJWFFqTzl1WDYzSmJ2K3lJbW1yek9F?= =?utf-8?B?cGRGbkRzUHNVa2pjY2lyNHFndFdpZTlRY0paSkllWlZtK3dtcTU0MDlGdTBm?= =?utf-8?B?eU5kV1RxODI5RHFsRG9qM3B3b0Flb3ZsUTlyNmc2K0ZLUU9LaVVzVFNzWjZu?= =?utf-8?Q?j9xr9rHUG90YIOy+cPMQMYr/t6rxqY0O?= X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1139;6:cj2BkilzHYnNHe4K+Tq3I2MRKlhvm9w+1sf4TsOYfCpA9k2gHOe86zpBgwSexAH8VF4IEiHwGscD9fxACxbOV3I7skmVW1i1P44T0aJMmT36fL4gCE5TVpWK1mE8QoxRZqkYulAbRiAdiwmfBcpwXkl0tbuctSyC5l3pjno+WuX/D5L7nKfbS3RR6GfHEErK8reL7+45pf/XiCuMpbkx8OwugHP4/+TxQrEeuMxRg8dBFzRNnv4dFDJ/ELleCaJXPpuiNOhWTCo7uaMCAspo/UF9vVRCj8czGfF+EOnKkXLQ3cxH0WptrnvrYJZNRiBAUzD6Y4YbJGM+6uYQ6vqdNPokhR9X8XD2kjgvx7zpiKiQyn3DEPrOqCY7YGpXOh7NwFG8O3k/Eu09Mapg1TNbcud+z4PHE/a2PX9sKahmA8JYfQRRAVEnhCskslffn1hxijirugri0ZpsYVtjvWxt690bGvcFC26j3gb+8qIvm7s1kWjhGoiYB46cd4PiSNSlYGaUw3KO+NGBg1wLkXKUiTik6eYw3w8YboURYJC/fRY= X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1139;5:87BSPoJDAoffHebD1xIjtme65Cf3v+j9jHggmFQcRRVDbjSgpZg5U3evhbmje/PDgdqI1FZYE0Zkc1mzYQ+lUmQRLAC45z7p7hzmmYVaxfMEBbTrbwLZxJxT/x3Aj2SQGWphLHonKTLExVxGtfCtaG5ULPZixb0yjkvImBvEa5TPsbyHt1WDYVARfuo573YJXUzjMUb+y+huaaNcIC6C/l6BLaJ/oLeII8dH1fx+pMW9r6FTKQKTf/t/SXDX2z+N5JGIfI8p2Vy5EB9IKUZ7VYqF51CVp4fRNirOc4ipPwwUxyoBte//Oxbj17vJ/ZirWrC0kPsDw5ev5x0AuBl5olMHIH/r722wvaT63wAkd+a4R2ibQG3lTj+wDvyySAgjqetg5P/pyh0yaoy0KQ/1LOc7XFj4dRsLn78X2nerLy02G0Reyl0FUj4yRIYWAnrt9uUYTNhHIG+kTKFTkSSgNUKBAzaVUtCw7yDUPBTZ97AemRpWFRw65CgF2sSBeMsQ;24:gJg5r5X3AK7Tr+Q+GwZOotWQoRxZqw/IV0ZWsqLIDg4AE2y4OOxoGD100mWinnCCU/9FRw8MR2LeI1ysABdMAoze2Oejc6b0gCVTLBYG8Fk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1139;7:uBlXbyoU5SrZM+E7tst61S3MTECVlzjMKL3owTl0+wWpxLyhzkznPYaQHVBGq87eTVeKiSoD6brALiUiwwHsm8596NamPr9zRJz2yLX4SC4MWgAf+PqgM+5dLsuYOvC4mrEouCnwr/NrGKD7amEdumqCSplNj1HXdR51zIfN6NTTnomrU4IVqk0bdlV6kH0LTDMcBdAT2ReO2s9PVn00QWt1QS/gPt/9WWZko16sVLKjVkdjingUKcS+unHBgilUZlVfq1SoWefTXRCKvRG+VAuNmj5/8Non/9HVf2XAdDDS9p89C2Y850nwjitBycXigZ9MXgaZ2kprnrewX3RiyQ==;20:fuRn0D9diZqi3CjtTpO9kfoE1bTFALMTY4Ep4etcccW6jmNZ/vkNliMVw45SvhE+pTU/mqZGmfBsbS5M4xnn7pyzPzswetiyMoYzRAj2UszyJvRX17LFiLJ0SAuKWCvv4Pzfr+xnE5uwtsudHrjaiYMV74fV1EH6DfFcM86aqH02e64/+89VaksEhh5t1p9g4pkkg06Ur4Z/v/YG/iDBiFooY1zHxlZOzrA8LxM/U4WGofkE4AVTqGZRTbzjRSrE X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2017 18:36:39.2259 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1139 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/8/2017 5:01 PM, Andrew Cooper wrote: > On 08/06/2017 22:17, Boris Ostrovsky wrote: >> On 06/08/2017 05:02 PM, Tom Lendacky wrote: >>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>>>>> What may be needed is making sure X86_FEATURE_SME is not set for PV >>>>>> guests. >>>>> And that may be something that Xen will need to control through either >>>>> CPUID or MSR support for the PV guests. >>>> >>>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf >>>> 0x80000007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG. >>> The SME feature is in leaf 0x8000001f, is that leaf passed to the guest >>> unchanged? >> Oh, I misread the patch where X86_FEATURE_SME is defined. Then all >> versions, including the current one, pass it unchanged. >> >> All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in >> xen_init_capabilities(). > > AMD processors still don't support CPUID Faulting (or at least, I > couldn't find any reference to it in the latest docs), so we cannot > actually hide SME from a guest which goes looking at native CPUID. > Furthermore, I'm not aware of any CPUID masking support covering that leaf. > > However, if Linux is using the paravirtual cpuid hook, things are > slightly better. > > On Xen 4.9 and later, no guests will see the feature. On earlier > versions of Xen (before I fixed the logic), plain domUs will not see the > feature, while dom0 will. > > For safely, I'd recommend unilaterally clobbering the feature as Boris > suggested. There is no way SME will be supportable on a per-PV guest That may be too late. Early boot support in head_64.S will make calls to check for the feature (through CPUID and MSR), set the sme_me_mask and encrypt the kernel in place. Is there another way to approach this? > basis, although (as far as I am aware) Xen as a whole would be able to > encompass itself and all of its PV guests inside one single SME instance. Yes, that is correct. Thanks, Tom > > ~Andrew > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Lendacky Subject: Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3 Date: Fri, 9 Jun 2017 13:36:35 -0500 Message-ID: <9725c503-2e33-2365-87f5-f017e1cbe9b6@amd.com> References: <20170607191309.28645.15241.stgit@tlendack-t1.amdoffice.net> <20170607191453.28645.92256.stgit@tlendack-t1.amdoffice.net> <4a7376fb-abfc-8edd-42b7-38de461ac65e@amd.com> <67fe69ac-a213-8de3-db28-0e54bba95127@oracle.com> <12c7e511-996d-cf60-3a3b-0be7b41bd85b@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US 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: Andrew Cooper , Boris Ostrovsky , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kasan-dev-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Cc: Brijesh Singh , Toshimitsu Kani , "Michael S. Tsirkin" , Matt Fleming , Alexander Potapenko , "H. Peter Anvin" , Larry Woodman , Jonathan Corbet , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Ingo Molnar , Andrey Ryabinin , Dave Young , Rik van Riel , Arnd Bergmann , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , Juergen Gross , xen-devel , Paolo Bonzini List-Id: linux-efi@vger.kernel.org On 6/8/2017 5:01 PM, Andrew Cooper wrote: > On 08/06/2017 22:17, Boris Ostrovsky wrote: >> On 06/08/2017 05:02 PM, Tom Lendacky wrote: >>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>>>>> What may be needed is making sure X86_FEATURE_SME is not set for PV >>>>>> guests. >>>>> And that may be something that Xen will need to control through either >>>>> CPUID or MSR support for the PV guests. >>>> >>>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf >>>> 0x80000007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG. >>> The SME feature is in leaf 0x8000001f, is that leaf passed to the guest >>> unchanged? >> Oh, I misread the patch where X86_FEATURE_SME is defined. Then all >> versions, including the current one, pass it unchanged. >> >> All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in >> xen_init_capabilities(). > > AMD processors still don't support CPUID Faulting (or at least, I > couldn't find any reference to it in the latest docs), so we cannot > actually hide SME from a guest which goes looking at native CPUID. > Furthermore, I'm not aware of any CPUID masking support covering that leaf. > > However, if Linux is using the paravirtual cpuid hook, things are > slightly better. > > On Xen 4.9 and later, no guests will see the feature. On earlier > versions of Xen (before I fixed the logic), plain domUs will not see the > feature, while dom0 will. > > For safely, I'd recommend unilaterally clobbering the feature as Boris > suggested. There is no way SME will be supportable on a per-PV guest That may be too late. Early boot support in head_64.S will make calls to check for the feature (through CPUID and MSR), set the sme_me_mask and encrypt the kernel in place. Is there another way to approach this? > basis, although (as far as I am aware) Xen as a whole would be able to > encompass itself and all of its PV guests inside one single SME instance. Yes, that is correct. Thanks, Tom > > ~Andrew > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f198.google.com (mail-pf0-f198.google.com [209.85.192.198]) by kanga.kvack.org (Postfix) with ESMTP id 090706B0279 for ; Fri, 9 Jun 2017 14:36:53 -0400 (EDT) Received: by mail-pf0-f198.google.com with SMTP id b74so27503740pfd.2 for ; Fri, 09 Jun 2017 11:36:53 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0061.outbound.protection.outlook.com. [104.47.33.61]) by mx.google.com with ESMTPS id f26si1412472plj.86.2017.06.09.11.36.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Jun 2017 11:36:47 -0700 (PDT) Subject: Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3 References: <20170607191309.28645.15241.stgit@tlendack-t1.amdoffice.net> <20170607191453.28645.92256.stgit@tlendack-t1.amdoffice.net> <4a7376fb-abfc-8edd-42b7-38de461ac65e@amd.com> <67fe69ac-a213-8de3-db28-0e54bba95127@oracle.com> <12c7e511-996d-cf60-3a3b-0be7b41bd85b@oracle.com> From: Tom Lendacky Message-ID: <9725c503-2e33-2365-87f5-f017e1cbe9b6@amd.com> Date: Fri, 9 Jun 2017 13:36:35 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Cooper , Boris Ostrovsky , linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, iommu@lists.linux-foundation.org Cc: Brijesh Singh , Toshimitsu Kani , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Matt Fleming , Alexander Potapenko , "H. Peter Anvin" , Larry Woodman , Jonathan Corbet , Joerg Roedel , "Michael S. Tsirkin" , Ingo Molnar , Andrey Ryabinin , Dave Young , Rik van Riel , Arnd Bergmann , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , Juergen Gross , xen-devel , Paolo Bonzini On 6/8/2017 5:01 PM, Andrew Cooper wrote: > On 08/06/2017 22:17, Boris Ostrovsky wrote: >> On 06/08/2017 05:02 PM, Tom Lendacky wrote: >>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>>>>> What may be needed is making sure X86_FEATURE_SME is not set for PV >>>>>> guests. >>>>> And that may be something that Xen will need to control through either >>>>> CPUID or MSR support for the PV guests. >>>> >>>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf >>>> 0x80000007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG. >>> The SME feature is in leaf 0x8000001f, is that leaf passed to the guest >>> unchanged? >> Oh, I misread the patch where X86_FEATURE_SME is defined. Then all >> versions, including the current one, pass it unchanged. >> >> All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in >> xen_init_capabilities(). > > AMD processors still don't support CPUID Faulting (or at least, I > couldn't find any reference to it in the latest docs), so we cannot > actually hide SME from a guest which goes looking at native CPUID. > Furthermore, I'm not aware of any CPUID masking support covering that leaf. > > However, if Linux is using the paravirtual cpuid hook, things are > slightly better. > > On Xen 4.9 and later, no guests will see the feature. On earlier > versions of Xen (before I fixed the logic), plain domUs will not see the > feature, while dom0 will. > > For safely, I'd recommend unilaterally clobbering the feature as Boris > suggested. There is no way SME will be supportable on a per-PV guest That may be too late. Early boot support in head_64.S will make calls to check for the feature (through CPUID and MSR), set the sme_me_mask and encrypt the kernel in place. Is there another way to approach this? > basis, although (as far as I am aware) Xen as a whole would be able to > encompass itself and all of its PV guests inside one single SME instance. Yes, that is correct. Thanks, Tom > > ~Andrew > -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-bn3nam01on0065.outbound.protection.outlook.com ([104.47.33.65] helo=NAM01-BN3-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dJOmT-0007v0-23 for kexec@lists.infradead.org; Fri, 09 Jun 2017 18:37:10 +0000 Subject: Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3 References: <20170607191309.28645.15241.stgit@tlendack-t1.amdoffice.net> <20170607191453.28645.92256.stgit@tlendack-t1.amdoffice.net> <4a7376fb-abfc-8edd-42b7-38de461ac65e@amd.com> <67fe69ac-a213-8de3-db28-0e54bba95127@oracle.com> <12c7e511-996d-cf60-3a3b-0be7b41bd85b@oracle.com> From: Tom Lendacky Message-ID: <9725c503-2e33-2365-87f5-f017e1cbe9b6@amd.com> Date: Fri, 9 Jun 2017 13:36:35 -0500 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Andrew Cooper , Boris Ostrovsky , linux-arch@vger.kernel.org, linux-efi@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, iommu@lists.linux-foundation.org Cc: Brijesh Singh , Toshimitsu Kani , "Michael S. Tsirkin" , Matt Fleming , Alexander Potapenko , "H. Peter Anvin" , Larry Woodman , Jonathan Corbet , Joerg Roedel , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Ingo Molnar , Andrey Ryabinin , Dave Young , Rik van Riel , Arnd Bergmann , Borislav Petkov , Andy Lutomirski , Thomas Gleixner , Dmitry Vyukov , Juergen Gross , xen-devel , Paolo Bonzini On 6/8/2017 5:01 PM, Andrew Cooper wrote: > On 08/06/2017 22:17, Boris Ostrovsky wrote: >> On 06/08/2017 05:02 PM, Tom Lendacky wrote: >>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote: >>>>>> What may be needed is making sure X86_FEATURE_SME is not set for PV >>>>>> guests. >>>>> And that may be something that Xen will need to control through either >>>>> CPUID or MSR support for the PV guests. >>>> >>>> Only on newer versions of Xen. On earlier versions (2-3 years old) leaf >>>> 0x80000007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG. >>> The SME feature is in leaf 0x8000001f, is that leaf passed to the guest >>> unchanged? >> Oh, I misread the patch where X86_FEATURE_SME is defined. Then all >> versions, including the current one, pass it unchanged. >> >> All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in >> xen_init_capabilities(). > > AMD processors still don't support CPUID Faulting (or at least, I > couldn't find any reference to it in the latest docs), so we cannot > actually hide SME from a guest which goes looking at native CPUID. > Furthermore, I'm not aware of any CPUID masking support covering that leaf. > > However, if Linux is using the paravirtual cpuid hook, things are > slightly better. > > On Xen 4.9 and later, no guests will see the feature. On earlier > versions of Xen (before I fixed the logic), plain domUs will not see the > feature, while dom0 will. > > For safely, I'd recommend unilaterally clobbering the feature as Boris > suggested. There is no way SME will be supportable on a per-PV guest That may be too late. Early boot support in head_64.S will make calls to check for the feature (through CPUID and MSR), set the sme_me_mask and encrypt the kernel in place. Is there another way to approach this? > basis, although (as far as I am aware) Xen as a whole would be able to > encompass itself and all of its PV guests inside one single SME instance. Yes, that is correct. Thanks, Tom > > ~Andrew > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec