Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751473AbbLUWOt (ORCPT ); Mon, 21 Dec 2015 17:14:49 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:51054 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751201AbbLUWOr (ORCPT ); Mon, 21 Dec 2015 17:14:47 -0500 From: Arnd Bergmann To: "Dr. Philipp Tomsich" Subject: Re: [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Date: Mon, 21 Dec 2015 23:13:33 +0100 User-Agent: KMail/1.12.2 (Linux/3.19.0-27-generic; KDE/4.3.2; x86_64; ; ) Cc: Catalin Marinas , Andrew Pinski , "Joseph S. Myers" , "Kapoor, Prasun" , broonie@kernel.org, Nathan Lynch , LKML , Alexander Graf , Alexey Klimov , Yury Norov , Jan Dakinevich , Andrew Pinski , David Daney , Andreas Schwab , "Zhangjian (Bamvor)" , "linux-arm-kernel@lists.infradead.org" , Christoph =?utf-8?q?M=C3=BCllner?= , Marcus Shawcroft References: <1450215766-14765-1-git-send-email-ynorov@caviumnetworks.com> <2334903.IjsQ1BK3JF@wuerfel> <4753CD2F-914D-44D5-BD18-8DF94068315D@theobroma-systems.com> In-Reply-To: <4753CD2F-914D-44D5-BD18-8DF94068315D@theobroma-systems.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <201512212313.34114.arnd@arndb.de> X-Provags-ID: V03:K0:2Olga/d8o43Y0UuTNxISgno8oAz1Dy99mFUvu1qhDEUSyVkIfHv ilaxaWKna7mLVmpPCcxgkPxm3taEyCk0vCMVvyu+hahvD94uKKhrephFeiK++OVcRpow6HX 6XuBpb9vdK5pPIAy+7E3ak6rXg+FvwbRW/CAfRhbdELLyY8D5KzgoeKgyBZEoMOzUklTZ+l 1gw2zu6NSBcveY9q7xFWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:vBHrtuZqgrM=:Kxz6+QNtXdWgRTujaY0fdo K5NyBKnGB0tNiQHtEHwJY9VYFBTeDoCOpiPDu/eKTUKYT1UXvMMbqonN7gqs3pkUodC6elj4G 47b71z4vov3dlkwtmIInpDSyOjg6Eiw9KFS9J62wX2JoPO3dAJzEUuvwSJcDo1HgRupgnhPkU gUnDya5g78bJOizglirztCXPJ3wJ0eKJQ761bbQI+ux6GBQwX7qn/augR4bXMG0fLcgg2YR1t hAIEtV9NAo/2tEcrEAwISYZ/OclTKtK1PI3LTz07wccTLRQTHPexIXlfUsMwhax0whTO0zFeZ rN6Uv3uBKU4us0ac1n0JUPSpb0ENVM/79CL9oHnDk/xtV1Bf68979mc5MCTSTVZW5Zdh5lRD+ hT2npS7Ft8eK7DirFEiMnZCPiA6jAnz52LkwhsW8rMBTTcei0HluCjAQUZscPTT0s+/HhsZQ/ 5jUSNovEmZGN2qgtfuiIYk1LaXafQ2hn5GJM7yL2iO7PpD23kbea3ca+tKy//lPkWMVTcfSFD A43+iWnlp6+wuj/X9POZ4hftCa7XFgo3jdSF8sZiXXGSaDazqJDVKYUKY8Ii00nOD1GIQ4Rkq m9mYWI8oC9Q8fqZ+NntCOfsq0/W5knyid8CKFnroHjfmUIQ2JFGmRs/uUUDv9IoUNyHybeChP GWl/t1rBlSCQNnZh4gdQnE+BqUFUgM4CxEuDtLnP0jOnPQv8rt3Ugk2b6iK864K4v8KrJY05R lNVn5unQLP5gNwPF Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1720 Lines: 33 On Monday 21 December 2015, Dr. Philipp Tomsich wrote: > > > On 18 Dec 2015, at 13:47, Arnd Bergmann wrote: > > > >> 3. Follow the PCS up to glibc but always pass syscall arguments in W > >> registers, like AArch32 compat support (the least preferred option, > >> the only advantage is a single wrapper for all syscalls but it would > >> be doing unnecessary zeroing even for syscalls where it isn't needed) > > > > This would mean we cannot pass 64-bit arguments in registers, right? > > Note that there’s no 32bit registers (the ‘w’-form always refers to the lower > 32bits of a 64bit register, with implicit zero-extension)… and load/store > instructions always use the full base-register (‘x’-form) for address calculation. > I.e. a load/store would inadvertently pickup “random garbage” in the upper > 32bits, if no explicit zero-extension is applied. > > In other words: all zero-extensions for 32bit arguments should be explicit > on the kernel side. I think that is what Catalin meant with the single wrapper in the description: the kernel always zeroes out the upper 32 bits in the initial trap, and then we only need to do sign-extensions for the few cases that need it, and pass 64-bit arguments in two lower halves. In contrast, approach 1 adds a separate wrapper for each syscall that takes care of both sign-extending where necessary and zero-extending all othe 32-bit arguments but not the 64-bit arguments. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/