From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751823AbdFIS7d (ORCPT ); Fri, 9 Jun 2017 14:59:33 -0400 Received: from mail-dm3nam03on0040.outbound.protection.outlook.com ([104.47.41.40]:40850 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751584AbdFIS72 (ORCPT ); Fri, 9 Jun 2017 14:59:28 -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: Boris Ostrovsky , Andrew Cooper , 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> <9725c503-2e33-2365-87f5-f017e1cbe9b6@amd.com> <8e8eac45-95be-f1b5-6f44-f131d275f7bc@oracle.com> From: Tom Lendacky Message-ID: <33f20df0-bf71-bd9d-7a7e-4fb5e8793400@amd.com> Date: Fri, 9 Jun 2017 13:59:21 -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: <8e8eac45-95be-f1b5-6f44-f131d275f7bc@oracle.com> 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: DM5PR15CA0023.namprd15.prod.outlook.com (10.173.207.161) To DM5PR12MB1145.namprd12.prod.outlook.com (10.168.236.140) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM5PR12MB1145: X-MS-Office365-Filtering-Correlation-Id: 4b40e120-f965-4ee0-c114-08d4af69a52d X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081)(201703131423075)(201703031133081);SRVR:DM5PR12MB1145; X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;3:n4u/nWA+dSJrk3R7U8Ora7fd1+/pqVNW8tk0avMIXhucWaIPJ7KCut0INfln1GVtdPa/Vh2B3mtVgpDMdDgO29n4a9ttUWFrBkt3OBjCZFV6zJLuBnf2U0QorWQWYlwi+oERQZUp9qFx98kUqr5VpYNq52Xe6dcRx6eBqGSLk5CWIkrsqGKwo1oShAAqhmmifl4Cot0UUyPE+3IByCEidICvsbz1yNHWpdVuo9UAtVKIH7iuc2DS86p7qJ2WU41xtb4pyJOMkpdxEMjk0gydb+CwhWebdCjUPF4HK/hcul/bJMAqO76VmrVffeP9aHospn43UuDwFETwjBJT90P6QVONDLWRTE0ud+BTWmIBZBI=;25:N1eA+0fbHet3RPov8+zgVvLDK2NpEvf9NMEomIKE3R2iIi9kWV/pv6sXzTFQo4N/ouOj/PPsdu2YSNyv/9jzGDJM2r2DmvILGTbzLEFqxr6YGX8eF5UOBnG/n3AGx/R9HCxdgaBFbMQytJ7C2x9XQ7eBU3FLwKLv93F74H4Kq+gJa2vS/We5zST2xG5aqUbV2GCKYAJz78rpjsrYTcF85qAivFDXbD1OZmYrWRoQqDvVWenLa9raiQbCjbBSqrIjxvImhfy2/AuSKpv8lxefpLFF0H3mB4CCjV41wets4mn9xnyXI/S0t3n1R+yOFxs1rgxR3HI4nr0fq8OBCMjXj9bPUNwKjafpk8BEFfCf/HYPGy/85Ab49Tk5bcNgbgi4Ng287/raILbmG3Dar2LNUMJ2kq4q92VLPXyEyqmNnUWOxM/r4c2M8jplnscoZttPkFbxMAPkg2byfAgJfMgfkKimwQdQxpNJILFtA58G17w= X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;31:Ea8TpfWVLmLYgwE9suYExxxP9qWAEocK9mN1vV0FZlp/678TR/LgPVfThJLeJ7r9EspzRr+ZtmhYVqjo9IK/EDsw84jyzm4/x9kk6+W/vYqXo9eXJ4NqOuIWlB8YLVOUwupe5i5QF7NNKGV/azqXB0QgTCJyYCR6NbBrsh8YFzNoLimU3wCkMtQBrsISCdQS80k+tQn51YQ0NzbF5NvpN+NG4kdJBJjNamrzH6pGdVg=;20:40zQy2f9Bcax1iUQVf9aIkLncCDmFF/KaPmrkWIk96m8bBt73qzT2sL655gFOU1CDKHX7xqDllsQUiYB7bLq1Lf7g5GaMe6fUa64AcNBb+pktcTANQV4vs8Vq444bKIu/su5srdZG/UA+DJIAeocM8rCe3NyOv+s6kN7UphWi7tjKjQhB2f7Rol7+DIQAnJBHTS6xmsBjO/gBCXnuWBSRzERF9QUQmObvHcemGGbI9+C8BkicDK9JrP/cgLcxfTCTOw1o2eJZ4iXUdDGtI4e+0bAAx5o/vvhlZjvIH/f57HUe63lSoIRwneUQxZsg73ytHBni+sF7qPJg4uw+2NiO0ejPG+Yn0SDfW8rTtKrKRvqOMM0jcGdc81QcVzpDJMoX+8jaF84iujeOIDZht82EwYE8iVNpFNNiCTiCIjZraV1vz2ngzRWkhmdopQDrGUbuacBuNXDgdEPJrhEFYetwVMN5sPYBA/ITtpIovETvAB0zXiDOSxRKmbsUOBvU6r3 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)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DM5PR12MB1145;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DM5PR12MB1145; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjEyTUIxMTQ1OzQ6NnpoRkM0K3ZHVEJWNVJNZ3Bkd3BMQTRKazdD?= =?utf-8?B?M1NuaW1BV21IR1RvNDU3MjZqYXl5R1BNVTBtL3dRVkFCQXpMM3p4ZksrRlpN?= =?utf-8?B?Y2dScjJjd2g2R0lXSWF4NTBneHBzckJUOFJhL3UxTUljajVQR0ZSUC9rRXZr?= =?utf-8?B?V0xLZ254ZGVCQnRjeTVJWDFITG10cElIK2l4OCtOeS9pVXlWWTM4ZDFzMDVl?= =?utf-8?B?TVArdU1abmpld3dEUk9GNlIxd09HbHM1citTWjVwSmUxSzVRbGk5NUk2Uk0v?= =?utf-8?B?a3h0NVVhb2FHb0UrRUVITHo0SkpmZ2xOV29PdjNwalRzQjkzSDlBeExBMDZW?= =?utf-8?B?VFI4dDhGZHZyWmVFRE5lZEZjNXdzMkZNOGtSTkE3M09mWlZxRUhTN3V2UHpD?= =?utf-8?B?akVJa0VsSjdOM0VkMXhuSUJzQmRKWWU5Q3gyLzBvcmkrenh1NUlielUvaTZH?= =?utf-8?B?ZlBBSXFDOWhvNGgwWmtmbHN1VzR5YU81NnI5THRvdTVmRHhZb1BudTlST29Z?= =?utf-8?B?amJGTStlaC9EZGVMMGJjaTVyU2p3Y0c0b3kxMzRhOVAwVTZMREFiaGVvQ3pN?= =?utf-8?B?a3ZvbVFnNzlyR1NjZ0NWNS8rUUdTd2UybmNyeVdoakpXZk9ZWm5FSWZ2VEtT?= =?utf-8?B?S1pEY3hnWWdKSTFmMklld21GMW8xMDF6Slp6eUhIaXZaZjBRV2lhcnd5WCtV?= =?utf-8?B?b0RnVnZBRHNwWnhFVm9na0RrZlNPSTR5RFFjWTYyR2hnUUVtOEl2Rk1JRzcy?= =?utf-8?B?N1FUL3drak9CNUxoU1dOVzN2YWdRL1NHamJVV21xVjMzczloTnRRczlvQ3BE?= =?utf-8?B?UGx1TkZXVW5TZVdzTE13ZkI3aWl4Q1hNUUNaejRtMk5OWUNxcDNSeXhHZmxY?= =?utf-8?B?OXVtQnZWKy8yODlBanN2d2JkZnRrbGs1MjFjUGtETkhZTTFTZkp0RUptWmEx?= =?utf-8?B?TnhRU0Y2YmZiUjNtc1F6b015cjlWSno0R05PR1hBZGpwc21FcDZNaXEzeDkx?= =?utf-8?B?dmhsTzdlVGp6KzFRNHh4SVBkMkpDTzlZS3NlYlM5RTBGMHV1REYzR3FKT2RK?= =?utf-8?B?eFhYQUN2SmlLc1pnNHQvcmxjbzc2MW1WWmQ5NXZCakhSLzNlMmVNTitDcGY2?= =?utf-8?B?dlJReWtaUU1uUzFNWHVoTXlLUFgwNWV6Z25rSlF3Tzk0OUVIdWdaNEtMMDBm?= =?utf-8?B?ZXJUT2JDMnFpeko5dXVFdnh6am5sWWRuL0VPaHljVVpGbGZPUzltSzVkSGtK?= =?utf-8?B?L3VHSU1VaU4rYnlyOTQ0VlVkWHJJV0cybzNTOGVtbCtlSmJwL01weXdPUkpq?= =?utf-8?B?KzFkM3AxN3FZbzVJWkdWRTlJNEthdjlJS0lTbnBNMStxVWVObGdEMW0vekJ5?= =?utf-8?B?RzhkejVVejhlTHEwaTFYcG15Q2RGYWs0WTZwK05FMTlXenYxSG13UlF5a2pG?= =?utf-8?B?TFI2VDVrbEg4MU5BWlRvN2VsZnBqb0dtTm9LV2loZDNOU0VxbUhMbWVFeFhZ?= =?utf-8?B?OUxZWVd6UUNic25rbEl5Z2RpdUhma0c0dStzSllkMHFtUG1aYzk1dG9WSGpX?= =?utf-8?B?TVRZUlhLbm05eDJXb2tEa3h5RGI2TGtRRlVoN2RDSjFpRjVkeXVDSkpCMXhV?= =?utf-8?Q?lU4+ZklV2iYuu0gTjz3?= X-Forefront-PRVS: 03333C607F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(6049001)(39400400002)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(377454003)(24454002)(81166006)(7416002)(305945005)(8676002)(54356999)(76176999)(7406005)(6246003)(7736002)(478600001)(50986999)(64126003)(229853002)(23676002)(33646002)(72206003)(93886004)(36756003)(38730400002)(31696002)(42186005)(86362001)(90366009)(2950100002)(2906002)(8666007)(3846002)(47776003)(189998001)(230700001)(54906002)(77096006)(25786009)(53546009)(3260700006)(6486002)(4326008)(53936002)(65826007)(31686004)(5660300001)(65956001)(65806001)(66066001)(921003)(1121003);DIR:OUT;SFP:1101;SCL:1;SRVR:DM5PR12MB1145;H:[10.236.64.250];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjEyTUIxMTQ1OzIzOkgwdDlvQmN2S01GTFV5ampBNkc1N2lnVVBF?= =?utf-8?B?RThjWVdhQmFoU2lmM29oV2hTSGtDQ1hPZWRxc0NPazNvc1A3cHNHQ3MrOTNR?= =?utf-8?B?cnBpWWVNZm5iVXpwUncyS0o3RzZiSVZvc09xbHNTeWc1dy9iRlFnUjdLc2o1?= =?utf-8?B?b3hTMTgzTUdOT2V0aVNCbjJ2SW5EbnNVUFJIaGNpRjk0Y0ZreTBmcTNyTHNx?= =?utf-8?B?eEY2c2ZiSndKQnJaVVRFWCs3Z2tGWTNudmlHeDZTczJoa3kzcE9kQmdSSFBT?= =?utf-8?B?dmlhWkt1eDQ1UDAvZFk2Qlk2RGJ0NzR4MXM4NGp4bUliMldFeU5tbEJFV0N5?= =?utf-8?B?eURFMTROWmY1WU8zRVE3bmlIVTZlbFNSYytRNnAvWVkxMDM1U2ZpK1ZZUGVi?= =?utf-8?B?blVNNGRTbG9mOEY1dGE0VmZzcE8yOTJGM2RyMHpUNTBGMEt1R1E3czk0RFJk?= =?utf-8?B?VnlaSW0vR2hVTm1PN2VNVVV0MldqaDQ0NEh3ZVVoQWVvM3MwQ2Rqd0ZiNHJv?= =?utf-8?B?WXhucnZEYnNFclZxekZsemtpVVBiY2NTcmU0ZkFSK25aNW1wVHZTTm9qKzV3?= =?utf-8?B?amZIL3NYZmVscjBSSDVsMll1Rk9jZGZBNDllTXR3dzIrcTBFckx2UU5MZDdU?= =?utf-8?B?Ukl4YUlKS3U1Wjg4bEZXd0YwMDcxZ0ljNjBqejJiNTBRdmtuUDQ0ZmtqbTk0?= =?utf-8?B?OUMvZ08xNEtuQkNneWpNVm02UUJzQVErVDlFT0tSbUd4WndLV2Y5S3NRclkv?= =?utf-8?B?V0ZnUWNyMG1YMEdzQTZqdmM5Ky9td01FcnhsNG9PRXJvd0lSSkNKUGJvWFMx?= =?utf-8?B?YnZ4ZkFmV281b1M0RTVvVUoyVTRJTm1jTjhrbkJvNExkbDJaT3gxYWM3c3p5?= =?utf-8?B?STdoOGdoVXlvSGEyWTJRTUtUamk4K0F0MmtmMVhYY3JpSXdBa0FYdlBSVWR3?= =?utf-8?B?TlJoNTFwM3lzU1kvYUltcVlleDRSdWo0dGVYbS93cmdMYkZjaTc2RnZEL1FJ?= =?utf-8?B?TjdIWXVvTmtIMnZlTk1ZUmNMV2RTaWF3VzJ0YlFnako0SWpYRDBsbzBqazV0?= =?utf-8?B?ZFZ1bGxsbXhqamRubG1WWHlpY1NHT1lXV0d5VTEzdFpzWFFkNU5IdVBKQmg5?= =?utf-8?B?WWhDMUtmTDQ5OTg4MGNyM1Y4K3RUeVE5WGZvYnArS3YvejlobWdKYXE0Mm1D?= =?utf-8?B?UDFtNnc0RmJ4U3dFeTBpOThBVjdCNlRoME9hMkJ3S3RhRDk1d0pTUGsyYzJX?= =?utf-8?B?UFdweThpUzlDZHhiNzlzVHJEbUlNVVBYZjlxeU8xa3VYU0U4MytTTUlnUE45?= =?utf-8?B?Vnp0NmdQTXVGSmk0MXRGUmF1T0xNUU5pOXZ3Q3k2YnFpZVBqL3B3YTc2VDM1?= =?utf-8?B?STRsTUtUVUdTZlNKK0c2aFFWdU1SZzhsLzg2NkxsTXV2NGlHNDVNbCs4Sms5?= =?utf-8?B?cWJ1cVg4cVRLUTYwaldMOVN3QmlscWtpdWY5M2VVV2daVTZtK0dpcWphdmdP?= =?utf-8?B?cFpBRlVxSVkraFlib3E4QWhWODllWkdEcHAwL2pBd0JhVFNLRnA2eEp0WTNG?= =?utf-8?B?SXoxc0I4WW5tbFA3K1hpeVlNKzNENEQ0TWtUMkxrTXRDbEpmTldtaUFCVWRR?= =?utf-8?B?eHlNODdMQnRCcWQ4ZG5lMmd2dFltSGpVdlZCSXR1UTFkWlpWL0tVUGR6WWNJ?= =?utf-8?B?QXI1NG1RNnpBSjZyNUowWGZWeEtNd2JITHRxN2tvRklUR1lnRGFLbDVtS1ZM?= =?utf-8?B?cFljekY2NFZ6TEFEZTRJTE9oNjhxbkxENEVqKzllaDhBUU1odjZMVzdyUW5X?= =?utf-8?B?eGpxckxTeEgvY1JqeG91U21KODNlb3pZTjR3UVNnQ0xjU1YrdkN1TWozQmQ2?= =?utf-8?Q?vZd1TlwS68Q=3D?= X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;6:4RMrWienpplI3ACx0+RLpuai7wf+lVcTu5uuHAGegC9vugJrKWZR+BjQ77CN8aNIGBf90aO99icZuDCyD9N7BkGtMlDVCXaPqdBjPTCgf5Tyk7/2pvwaumLpJvfAQEIMFOg2uoJDbUboi9an376Ky+Mn6NLUqXreE2ZrBW2Qx3pZlAXAKL7wqdtVW7BSp1YbtDy1cBezhNmNFaNW8eEPCjHMASuSIujDo2Jt7wTljphur6ivilcmby77sBwZQVCPHg4BM8KDbecWh/kF5RZK234QTwnqomTAD71rqq89lbRVSMjx4jem2/BUaGfp05TKy0chqWh4MJGVsTPaAFw/rydQV8CvzhVowGGL/HPUIfTmP+N2Zt2YqM9LEg+aq5oZmLpKQt6C+TqFEbvbnoZ5CmkHze4w1vi0VbCVO+PR9SqaU6NxlmfoDS0AWUTcQcQ48qc0R+qsHxgvYmWQqfhraGA1XC4dzDjfL+23xQcoCx1IMOyKSQoAhQCxQUTXTwxax78E0nwcRRCWYtbR0tEFBNA0IVkXLhhxMk7eVpIPjxs= X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;5:piARK9Nqk8VjKodoaHVzLQJpw5k2NKzqOJJ8kiCKyFf7+d/q9DDjDNuWpFsSnm0kSLz7ofYtz1yLvs7z7RJ0AAiXpYv/9pSlLZkY7HoOxgasunC3OUdxIzJXOQz+bS7VY8z0nW5vXgirWX8g5DNoXAv1S11I1qlG+RMWVymqTbYAPPRPPVT86H5gLJ3Sg3xPfnow+Z4iRaDl6tq3cXGFbalgC3E74UF7SK8Cu+e4yVgjqWxSnq9s58RdKlUNxW1A/ULDz5Yj66pmAph/WjzoMw/nig9KBQ+u+H9Rk9o6kJ1yBzqte8XhBZdY9FRNfdwte1JCq9nc+ylUIoK6nBR6vvK9bfdeUiYg1TEQxY0aPnhgS4zFS2U/ljeJV02VyM6BoXpmZv9NXtjFRh0hEnaJ5plEV2JzLr5MNkwVzE7ewko2gJpLBpB56FklJSrYa0PEi/bNdqGFpTgBCptHVo/2xD3XF9XsZtauZqRi/1NoRkcnUeeh5vRZfjBYpl6h5ibH;24:NvkhXmRkrrj2wqS06NUHfri2axMjW/n8WkbSO35iEwvqIAjBYFXEXvYdbNMUeiJM7TzPr//xsey7vxHIOPAtHmwUfjdGbNQr0r86ntqPJs8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM5PR12MB1145;7:7ppQPbnbrOvb1/m7izkmZ4MQLSuDVzBZMMSK7WSCkhvuW8r1ApfPSd2DG1QerUb1jz3FhHsQ2GKqfBOYhT8fIMVH+gguiC/7ACIUTPRkitoEed3Wvs8kvLSYDU6yUbOq+HBdHgvzEd9zzRtJldMUcGhnTtvEpZMWGvyIH8Zaes82UFN3XUqcpK8EhfC7sBpRIQ2n2bJUxO71nvnEVndfo9xuC3mv/G4cJs0PWr/BReC1ZUn2MMBG19V978oIMMMaEWEkc4gE7K4GHd3i9TY324UqviJAgGsUnns4uaOwad8ENKOm9fq0pGPYXngP6PxcjJ4A74Yz9XUR+0daf8YpJw==;20:iqHwUtVnDqI71ieEGC5ILjv7cCU0sBcQAum1+HksC0I4OtH2O7BVf9m1pjR4C34UMX5Q7Noy0fVAS79gzKjNh0dmYDkZ5YCm8Ru/zNjC3GP0NboDDUF74McISU7ExwVcwFPbD+MaJKUk5CwTmMVAt3c5QxVfOe3fiJVSmcLkHqzY4gMOZzw8p95nrZW/enRiLtOx40G2TGgOF5TF0qxZMBLZCJNWdS/3X3TRGcyJJlI/VK68z45uZyn96Hqn1ZFx X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2017 18:59:23.3169 (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 6/9/2017 1:43 PM, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >> 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? > > > PV guests don't go through Linux x86 early boot code. They start at > xen_start_kernel() (well, xen-head.S:startup_xen(), really) and merge > with baremetal path at x86_64_start_reservations() (for 64-bit). > Ok, I don't think anything needs to be done then. The sme_me_mask is set in sme_enable() which is only called from head_64.S. If the sme_me_mask isn't set then SME won't be active. The feature will just report the capability of the processor, but that doesn't mean it is active. If you still want the feature to be clobbered we can do that, though. Thanks, Tom > > -boris > >> >>> 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:59:21 -0500 Message-ID: <33f20df0-bf71-bd9d-7a7e-4fb5e8793400@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> <9725c503-2e33-2365-87f5-f017e1cbe9b6@amd.com> <8e8eac45-95be-f1b5-6f44-f131d275f7bc@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <8e8eac45-95be-f1b5-6f44-f131d275f7bc@oracle.com> Content-Language: en-US Sender: owner-linux-mm@kvack.org To: Boris Ostrovsky , Andrew Cooper , 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 List-Id: linux-efi@vger.kernel.org On 6/9/2017 1:43 PM, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >> 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? > > > PV guests don't go through Linux x86 early boot code. They start at > xen_start_kernel() (well, xen-head.S:startup_xen(), really) and merge > with baremetal path at x86_64_start_reservations() (for 64-bit). > Ok, I don't think anything needs to be done then. The sme_me_mask is set in sme_enable() which is only called from head_64.S. If the sme_me_mask isn't set then SME won't be active. The feature will just report the capability of the processor, but that doesn't mean it is active. If you still want the feature to be clobbered we can do that, though. Thanks, Tom > > -boris > >> >>> 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-dm3nam03on0051.outbound.protection.outlook.com ([104.47.41.51] helo=NAM03-DM3-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1dJP8P-0001af-1b for kexec@lists.infradead.org; Fri, 09 Jun 2017 18:59:51 +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> <9725c503-2e33-2365-87f5-f017e1cbe9b6@amd.com> <8e8eac45-95be-f1b5-6f44-f131d275f7bc@oracle.com> From: Tom Lendacky Message-ID: <33f20df0-bf71-bd9d-7a7e-4fb5e8793400@amd.com> Date: Fri, 9 Jun 2017 13:59:21 -0500 MIME-Version: 1.0 In-Reply-To: <8e8eac45-95be-f1b5-6f44-f131d275f7bc@oracle.com> 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: Boris Ostrovsky , Andrew Cooper , 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/9/2017 1:43 PM, Boris Ostrovsky wrote: > On 06/09/2017 02:36 PM, Tom Lendacky wrote: >> 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? > > > PV guests don't go through Linux x86 early boot code. They start at > xen_start_kernel() (well, xen-head.S:startup_xen(), really) and merge > with baremetal path at x86_64_start_reservations() (for 64-bit). > Ok, I don't think anything needs to be done then. The sme_me_mask is set in sme_enable() which is only called from head_64.S. If the sme_me_mask isn't set then SME won't be active. The feature will just report the capability of the processor, but that doesn't mean it is active. If you still want the feature to be clobbered we can do that, though. Thanks, Tom > > -boris > >> >>> 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