From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945961AbcHRJps (ORCPT ); Thu, 18 Aug 2016 05:45:48 -0400 Received: from mail-sn1nam02on0041.outbound.protection.outlook.com ([104.47.36.41]:39456 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752864AbcHRJpm (ORCPT ); Thu, 18 Aug 2016 05:45:42 -0400 X-Greylist: delayed 79084 seconds by postgrey-1.27 at vger.kernel.org; Thu, 18 Aug 2016 05:45:42 EDT Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Thu, 18 Aug 2016 12:45:28 +0300 From: Yury Norov To: Catalin Marinas CC: "Dr. Philipp Tomsich" , , , , , "Joseph S. Myers" , , , "Kapoor, Prasun" , Alexander Graf , , , , Arnd Bergmann , Andrew Pinski , , Alexey Klimov , , "Zhangjian (Bamvor)" , linux-arm-kernel , Maxim Kuvyrkov , , Nathan Lynch , LKML , Martin Schwidefsky , , Christoph =?iso-8859-1?Q?M=FCllner?= Subject: Re: [RFC2 nowrap: PATCH v7 00/18] ILP32 for ARM64 Message-ID: <20160818094528.GA4765@yury-N73SV> References: <1471434403-25291-1-git-send-email-ynorov@caviumnetworks.com> <175AE090-EDA7-4A8D-9044-3FFA74AC1903@suse.de> <20160817124822.GA25751@yury-N73SV> <20160817142916.GC20762@e104818-lin.cambridge.arm.com> <20160817152642.GD20762@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160817152642.GD20762@e104818-lin.cambridge.arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: AM2PR03CA0018.eurprd03.prod.outlook.com (10.160.207.28) To SN1PR07MB2253.namprd07.prod.outlook.com (10.164.47.147) X-MS-Office365-Filtering-Correlation-Id: b84d3576-e191-45c9-3662-08d3c74c69a1 X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2253;2:apzBLA8crTe629FgxSeF6otz0jX9iHBRVvQNOes5RuMa7DdXnabBuhWVTrDwGuEw2mqX1LoqI0u1m8FlVBPSwQajRBaSDKCyhqWKOJKGQLJGxuUBmKnjvofFGnLsVmsA8yXs3ag7SQAawG5suR+ReqOe7x9XAMJ4B7OXm2dL3QEXXRElWJW3yh0LPqdvGt+N;3:dZDA6uuw8/GHKZxanSU1oxBVM9o0YHPSXuaU6PIWP3Lc6fgX92A7Wbbj72JFMRlqILiWCdU34D/Lz/qX/6WMvDOUGUXTFPuAEF4YNQbBcayBdK6qyYMhshvSDYRW+GYL X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2253; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2253;25:jCtw77RKseCRJCnD/hyAchiWMaDuJU+WaBmcJQ78Mr0VF6/ilCoNlijYrRai5PhL+yX26vWBoWGKeQc8wHkS1+6142QP/Jt6hkB2qxw4revuuk0nT2hEOVDrDiyP4bOeLGE1mdk2Ai8IKLmay1M4l6WeI2mDuwU/QVVa/gQLeGekTfG0zf8UhXRaAbcPdSp7BLefdPoLFxpW324trU+guGVr4ILg0nr5giRBhjr0PTrtFb9xaOlpEE7ZKrnsqC9HDwVvJBaxBEi8EvRMzMB48e8DC+z/ngHmN8VYEVZ5jE8HUOxOeZpoJQ8zEkwp3cKdUag5xHpgrx0k8Ym0wfTxlPkPXsnAc8X1BtLC7hFYaj6tapnrG3KisiDA1mC1xx5FJW5TsS8N+4ok/zhU8bTAszG481u/KiXOFZBY9opg/UTfWhH8PE4oo/lFe32ltlDtjL71Whtbq5+hbwqCAxWRiUBWjx5L6zQ20HRtu6T6WqVDburUiJ3oAnOZ6mVzQGBOZM7Up2NLZv+WhDuqqrS9je++LQ/FoLEAPK3CtE24OpbawNue31crRhSzTKIxIQantT5jjdT5gv9T1l7VC/ljNZ4GDuD6Il5CtECs1pTEgA03jomG4wbwDJg3cBVV4q/VdQBkPLHgdPNpPKyzDSvMByu/N0ZmaEkr1lFXpcSVM0bb91tkqum4/KgtZpO/Y62k+28LEfU2x1M2X+FOnGenj624Yk6wOUdXuOI5JxYWbG3YqFn9wh5vQd1ZXA05RQPlpwF8fnlwQaCK6xyQdLGS90RdZwym7ZBOderw9LnUvCL4hih3krHlEpb4mw7EUwD6xjqPXvm7I4CeUni9pGNSs6OeB2Wq5w5D/xTlw8JqUgw= X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2253;31:LZIvT/hYozr0c0y+kjboi9IJH6DR3CouEK3dUQLAlpmws2LutLEqIHkYU6zcmz8PAX/DweWsEeOI5le5ldGyJ2InWuw2JSiZdZFoyc+NaGPyTI69ffVZcltZRrhJkw+B7di6owusG8cGfjjgT03UtLhmsj0lXMciJAOLoGfLfRNjWSV47YyKr4noQ52/AG/dGdsBSwf/YuzTGIvUVEuiqiWj3f2Qo6DYbJkTe3cns10=;20:r5cCaIWVifCPjxcGB/5UubRzJu2PnhBuZsQ/eqwB/D6YhUyRxOreL9HYcHVgzXfrNxq9RD6sdOSPvE+2IG2A1B332PCyE1PJSsfTrO785XVC5H1rIy7FCI2oYGqW9wN+5p1JkZCFKB3g6nUCfdhn2h9INh4bNmaZzxY0ohpnw+G0kMck0o/URtzLB1kJVxRj+TzaJrE7BJVNlcme+px9+dCV5TchhI+L4OuvhXql+1sEkT9OJ4IvuHe0F0OsDZSC1Yxz86eFAbFpyqcTnOrjeS13GH8aCBKx/v/wPfLnlOPH+BK3b2T/T46xYwqVBDzBk1bz8JDacpZ78djUp79fSW63nhgH4qaX452unM5GeHg5kIc073f03dmwDJbPNBdRiY9ATd8q+xjNjettWmLJeanG/fnr+Knb8cJENmFIhP0hn5fLPBpOB2CzkFE03qYGLUb1w7+Hua70thRzKnohQc2jlDUOUrMjaiKJ/adCR6XiKeuaCbmnhSIh19FCDaa8bqdJZy8H/YAEwKBevHlKgnm4A0ezvHAtj+ga4pXr9vcq5K7cM2bd/4lUQE5r1L5vp10u935mWUhHf99wNBRcSVQcwK7Wh4H0ooOoB4iRgkQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046);SRVR:SN1PR07MB2253;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2253; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2253;4:47HAbwom7D/mIUHEteM53x5KkwaJuGyuchfoILNFcjl0f8JJfpUgCOHJAkKSl0D7dRve/w85qRAW+BSMfe1RaRY1sYbWscg/KEsfRju8kg++gqx+xBLR3d+19UyYvqs/r1Z6aXGh3HHRnsQFk4pGNMIUaxlK/UkzezHiCVHBUMs5PaUrmGkJEBrQ20W8hkjlZFvuFfOS4UiRogEaPSUX9aHIxiXllpiTnfkG5auq7+HIC1rdAunLiWeXj8or8rymwdQQStBm3zPfws+JgfrS0mAzW3VY0e1OG/PLB0Rq0I44sSDfkYXmJnpBMI0sADcKyMzpRQQ/B8/qaPGI/utZYRrc31+MTn4UaRM2AXqZFV5N/pMF/txcEdSV/SIQxpog08nfpxbkDtaS5fyoLg/Dbk7wqMWyE/XZuqmZ1xsEbL4kXt+4dSG3QJTv7MJ1pRuy X-Forefront-PRVS: 0038DE95A2 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(24454002)(51694002)(199003)(189002)(7416002)(68736007)(105586002)(66066001)(586003)(33716001)(8676002)(9686002)(81166006)(305945005)(7736002)(6116002)(3846002)(81156014)(7846002)(110136002)(189998001)(4001350100001)(97736004)(93886004)(106356001)(76506005)(47776003)(42186005)(77096005)(2950100001)(101416001)(50466002)(19580405001)(15975445007)(50986999)(76176999)(23676002)(54356999)(33656002)(4326007)(1076002)(83506001)(92566002)(2870700001)(2906002)(19580395003)(18370500001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR07MB2253;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjFQUjA3TUIyMjUzOzIzOm5vWTRCUGl2ZUtqV2x2aXhWUXRuN3F4WlJw?= =?utf-8?B?elpJT1J2WTRwSUFnK3Qwc1BlaE5JWEZENmNjNGxuTFNzWGlKejVUOFNIUnFo?= =?utf-8?B?MmhPS2w3cHltQjR5YU5VRGw3ZENJWlhIZWY2N0hxTmNCeThRa2dXQ0w2dEFr?= =?utf-8?B?Y0s4R3RBc2ZHWWlkTTN5MEdHZ3ZoNEtvN2VKd2hpUmtoWWgyNzZzcVdXLyt5?= =?utf-8?B?RHFTNUVTYVJHV3owcjd5cWNPRFNMRm1UMUpkRDFFby82a2l3SmcrN1ZQSFF2?= =?utf-8?B?aWVJM1cyeXppWEJRdTFXVmtuSUtIYWdLYk56dDVLSkN3YzNuRFBqUjhiMFRi?= =?utf-8?B?WmdCUUJ0ejRqSFV1RmhIZWk0UDNWc3RXMXpZeVYyYnNNOTF4TjdGZnZCM3Jy?= =?utf-8?B?dlhDRXQyTCtWbXhCN3kvZ1M5QkF2UU5vQkpiTUN2RGZneXB0c2Rubk1lYUdw?= =?utf-8?B?dzBXU0tNYmNSbzkwRXY3UEZ4NVdhNm5UcUVqSkVGUFdjbG00b3JVd1gyT1VQ?= =?utf-8?B?Z2lUcG5IQXVtb29xYkd0M2ZJT3QwTGZtSnNmL3M4VmhMOHVHaHRqWWczSEtj?= =?utf-8?B?QW9EZ0V1N1VoS0oyMDZ1czhkYTFtOStlaVE2TGFVL1hsd082VEFoWVkzb3FY?= =?utf-8?B?RHFFWDdkeTZiUlpSV0tsait3d2UwK2NUUnpDY0t6NWk3c3NQTFkzTWpMWFJo?= =?utf-8?B?QUZON1hNSXBrOFFsZWVTelUwQW51N0ZEVkgvVURiN0Vxd012ZlIwWVFtaTRR?= =?utf-8?B?VGhBcUlUTi9aZk1tRERPajFRRHdyejdyR3JYZ0xVYnY4LzE4QW5lcDl2MWFz?= =?utf-8?B?WFc4a2V1NFpWNjJCKzJwbjdPaUIyazF5dk04YnUxTDJxUkdhNjF3Zlkwazlz?= =?utf-8?B?R2pINFA0TWo5UVd2V2szRis0cE1FL3UvY282MmFLa0txRnhvTWIreVBnNWJD?= =?utf-8?B?dUgwaVNodHFRYkFOSnBEdEdDMmNMa2RiZ0tTRUZtcWlQV05MdDRFUmVVQ3p2?= =?utf-8?B?NklDZFlUNFNWZUlVSDdEcU9lSGhwM2d0UjJWVFVldWFMbm9nNWpNaWNFOWpj?= =?utf-8?B?U2pkOFJoKzVoYUtTdmtMc2F0cUZZbU10eWprRWE3N3REbm50dEVyM2tRdDNa?= =?utf-8?B?emxEamNYcVdORjJtZjhoNDNmcytQSU52MFlpeXFNWWxBdklKWnZWYzdGMDUz?= =?utf-8?B?YlFld3NQa0tHU0xLeVB6eGVlYnZReG1samZ1bjk2c05TcUthZnNGVmV6dWZt?= =?utf-8?B?NE90R3h4WlpkTU1haE5YSkg1V09lWlNXdElSckVQTFdQMlRiQlk1eWE2Q0xk?= =?utf-8?B?Z0VQM2ZDSncrS3ZLQjh1RTdGU09FWEtaVXhwZ3lsR1NhREZROTdSbFJvNlo0?= =?utf-8?B?eURiMHdEZVB5VStlc1dURENyNy9WU3RleUV4RmV0ZUx6b2U0R2lDVm1CNDJC?= =?utf-8?B?V0xwWWNtOXFVK0xVNThBbW9KMnpUNi85ZmNpT1IyM092bDhBeVJodVh1ekl0?= =?utf-8?B?V1JWZU9RZlNXM3VpUkpKVkMxamNjMXZkYVNhenJXTzB6blpuaElHRHVuaFJ4?= =?utf-8?B?ZkUxWGRIc1dieTA0MkQxaDEyZUF3YXo5eFBSVTd1cnBwL2hKdmtVeExud3Ey?= =?utf-8?B?Znp1eHBwa0tzZktpQjZQKzVINk9MTjVuNWVCbk5FbXIrcE9IYUt3Mk84d29J?= =?utf-8?Q?vigw53d0jakrLcSLiKUr+E6dZ189UQFboO9RvFs?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2253;6:jJB13D6QeXoyYWdU2VpbIRLKVpcoe1aInkArLg+F5CovuFLaS/qhEAVz7rUHDxA0rXGirDlVG60348JJxMRVEEep0jRxhjiDXaQPkQNlPmrycvb7iNLHal/m1JoWnxz8Gj+aY+B48D182ptoOC3Yhg5wgb7k7bhbZzJWVfMnjoLJ56i6Dx6oPgQHDdbodWM4fgPvHmpDA2YygSaFZ6KEjmSVM1CcmXbuJwbLnwzw85kwP+i38dDcwioLjz9W8kZO6fGXk3H234qfjwpN2CRqLkbU7Ebdk69HRZkJSluxgr8=;5:DwBS8xISDy2vlHr5etTgSwwb+2yqVTICjjOHg/cYW8jKRydi2IJ7+LgTYXzOeaqtdFKDKS61Z2sNAyzyXJsJRz4rzV2a0KgcEPkMTMlgns5Et5yLBpWr6d98nQPp39X/F01NsGGcBjdZlWFrVZX36g==;24:J41ZyDA55TKtGktEvUVQ0DEFHC+gxWDZowIjjrbT5kUntIAA5ZgnG3BYSjztM06MCBDECSn1Si1ztm14IYfFwZYu2+t/hMEC4MmDkkY/EV4=;7:JrQX6mOfprjO1sv4OmL1tj19ryjM3sWwu7MlK+ahmiUwB+1UTcjZGAVBb14sTtyg1qB71XG0qLI0VOMt5TOFgJr+y2tYAomwGBCHYkRBjutqGNK3NSz5Js2nXSbVMedRH4kQuRqoVYlWxelvc+/6dK+z8BB32GbtsRHs1Z5UaIVw0wiIbY94wwZTJWuJLqeJRh5FBMrPZ9FZkIeuotWgMNtoC1wFoE+QBqY90SIR8pFj0VosJ0eohbKM3/0NDQYX SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2016 09:45:38.9193 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2253 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 17, 2016 at 04:26:42PM +0100, Catalin Marinas wrote: > On Wed, Aug 17, 2016 at 04:32:23PM +0200, Dr. Philipp Tomsich wrote: > > On 17 Aug 2016, at 16:29, Catalin Marinas wrote: > > > On Wed, Aug 17, 2016 at 02:54:59PM +0200, Dr. Philipp Tomsich wrote: > > >> On 17 Aug 2016, at 14:48, Yury Norov wrote: > > >>> On Wed, Aug 17, 2016 at 02:28:50PM +0200, Alexander Graf wrote: > > >>>> On 17 Aug 2016, at 13:46, Yury Norov wrote: > > >>>>> This series enables aarch64 with ilp32 mode, and as supporting work, > > >>>>> introduces ARCH_32BIT_OFF_T configuration option that is enabled for > > >>>>> existing 32-bit architectures but disabled for new arches (so 64-bit > > >>>>> off_t is is used by new userspace). > > >>>>> > > >>>>> This version is based on kernel v4.8-rc2. > > >>>>> It works with glibc-2.23, and tested with LTP. > > >>>>> > > >>>>> This is RFC because there is still no solid understanding what type of registers > > >>>>> top-halves delousing we prefer. In this patchset, w0-w7 are cleared for each > > >>>>> syscall in assembler entry. The alternative approach is in introducing compat > > >>>>> wrappers which is little faster for natively routed syscalls (~2.6% for syscall > > >>>>> with no payload) but much more complicated. > > >>>> > > >>>> So you’re saying there are 2 options: > > >>>> > > >>>> 1) easy to get right, slightly slower, same ABI to user space as 2 > > >>>> 2) harder to get right, minor performance benefit > > >>> > > >>> No, ABI is little different. If 1) we pass off_t in a pair to syscalls, > > >>> if 2) - in a single register. So if 1, we 'd take some wrappers from aarch32. > > >>> See patch 12 here. > > >> > > >> From our experience with ILP32, I’d prefer to have off_t (and similar) > > >> in a single register whenever possible (i.e. option #2). It feels > > >> more natural to use the full 64bit registers whenever possible, as > > >> ILP32 on ARMv8 should really be understood as a 64bit ABI with a 32bit > > >> memory model. > > > > > > I think we are well past the point where we considered ILP32 a 64-bit > > > ABI. It would have been nice but we decided that breaking POSIX > > > compatibility is a bad idea, so we went back (again) to a 32-bit ABI for > > > ILP32. While there are 64-bit arguments that, at a first look, would > > > make sense to be passed in 64-bit registers, the kernel maintenance cost > > > is significant with changes to generic files. > > > > > > Allowing 64-bit wide registers at the ILP32 syscall interface means that > > > the kernel would have to zero/sign-extend the upper half of the 32-bit > > > arguments for the cases where they are passed directly to a native > > > syscall that expects a 64-bit argument. This (a) adds a significant > > > number of wrappers to the generic code together additional annotations > > > to the generic unistd.h and (b) it adds a small overhead to the AArch32 > > > (compat) ABI since it doesn't need such generic wrapping (the upper half > > > of 64-bit registers is guaranteed to be zero/preserved by the > > > architecture when coming from the AArch32 mode). > > > > Yes, I remember the discussions and just wanted to put option #2 in > > context again. > > I don't particularly like splitting 64-bit arguments in two 32-bit > values either but I don't see a better alternative. To keep this > mostly in the arch code we would need an additional table of syscall > wrappers where the majority just use the default zero-extend everything > with a few specific wrappers where we pass 64-bit arguments. Or we could > set an extra bit in the syscall number for those syscalls that need > special wrapping and avoid zero-extending. But neither of these look any > nicer (well, maybe only from the user-space perspective). > This is the discussion started by David Miller https://patchwork.kernel.org/patch/9132521/ After it we switched to current version. > > Everything points to just going with the pair-of-registers and getting > > this merged quickly then, I suppose. > > I will refrain from commenting on how quickly we merge this ;) (it may > be seen as binding by some). > > -- > Catalin