Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp328549pxb; Fri, 15 Jan 2021 14:20:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJyTN4NCMhE2IOc0xmHg4rmbEtiXEbCNu/xBNpyJ7sb0t5EeaWsuXsjQDIj6ka116uPFN5eM X-Received: by 2002:a50:acc1:: with SMTP id x59mr5189216edc.43.1610749204663; Fri, 15 Jan 2021 14:20:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610749204; cv=none; d=google.com; s=arc-20160816; b=v1P/e2jDMiAvqih00Y9YdlIOhhL0ePd6pP1qzvWIGUpWyAwM4qx2qekG0aiLI6VpfQ 0M+ARGDX0oZG3qc6+oXL9UVRHVaMnfA94pgcbNeNJT/Dv2H+U0aLxZ9VFrkTXv8D0kHg WG5FYT1IIR3YoMCZUs2b6BYZhUzmQClZwrj5GEC0yqHxHCti9j1VMltWro92NrJXV/bX QHFQdWfNpJWxREleU6XGaD4d75XEMJRtqUGQqGcVzxpsJoWLb91B4rcJM05zu3Z1OnjH PMVYHossQwXOv4NNftnFlZDH24d2q1BE7StnNbf7gt5gGr5W0XbSwd2ssqHrvowBS7iL Cinw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=R6dSNCkLqDLVZHS4O/Wz+9vdCt8DV6yMdH7EWpOmxvM=; b=pgrcjG9F4IpuhNz9fZzQbF+KQhmJjvPydE5h5CCqRru6SO1BQe7ORrNpcy21ODJaNK FVihEYad5J0SOaO8dbt5MCp8GVBRIuQAMBfKloqrykeVD0cVFD3ag4QnqykO7N8A1tzq Xc8saGIDhnMwf8C8Uhkq9O9FZRVRm9P1U1039nMXDjfvBViro5H2Zh8+s20G6EYakrMh RqCh1C5XzqaVfWNmPhWLW58OVmrU2HrtM0ZK8QN4l8Ks9JQ6Zuy3R3UNk+BRpWYPylQu kNDHkxhSPUVyz8/EhVfgIe36wa7vzKyO4kCgJNAoMPlEzG9TOv/NO8RJILpk/JLakJQ0 zJVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="W/+YhIqh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j7si4443868edk.67.2021.01.15.14.19.40; Fri, 15 Jan 2021 14:20:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="W/+YhIqh"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726858AbhAOWSK (ORCPT + 99 others); Fri, 15 Jan 2021 17:18:10 -0500 Received: from mail.kernel.org ([198.145.29.99]:41218 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbhAOWSI (ORCPT ); Fri, 15 Jan 2021 17:18:08 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 72CA423B1C; Fri, 15 Jan 2021 22:17:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610749047; bh=51AgOraSDUgeKFnzRXPrgQAF8UQsqnNhAJF/wHnUnuA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=W/+YhIqhwKpXMR1YHjsUDC/1vi3AWO14SB7s0CrInE/m/l9jIXs2gKoWQtGg6DRi1 mf4Us2McffrGNfxp4IKqE9Krhk9PJ6mRw52FrXdnWRw8t7OGbutqFJFImF//XaAK3B k296fxiI4dCA4u0e733GVj0Fpxayev4L71aTiRKsi0yNHKw3Gn80vLuK3OmBZXWmyw oknAsGz6IZ87kZfT4BR2bsmLOb9d+uOeSqnk8nhAisGl7bkTC8POoU9m8/KrTzm54l klHJ4yfGG8GXfWeMFLvQaAf6u+lkXxtZwfx2ZfsR0uBSzeGhBbnktJm2piA7XJhISW g81QIgbXjkJ+w== Received: by mail-ot1-f45.google.com with SMTP id i6so10089561otr.2; Fri, 15 Jan 2021 14:17:27 -0800 (PST) X-Gm-Message-State: AOAM531wQ7MD+YQyIxDlZLa3XX50C34/yuPr2NlM290VqK70kyaIQa4/ JQLg5v0E45RQGGRcM0NlLlG+ON39+2PaRgniB6o= X-Received: by 2002:a05:6830:2413:: with SMTP id j19mr10338611ots.251.1610749045821; Fri, 15 Jan 2021 14:17:25 -0800 (PST) MIME-Version: 1.0 References: <20210106064807.253112-1-Sonicadvance1@gmail.com> <20210115070326.294332-1-Sonicadvance1@gmail.com> In-Reply-To: From: Arnd Bergmann Date: Fri, 15 Jan 2021 23:17:09 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers To: David Laight Cc: "sonicadvance1@gmail.com" , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Yoshinori Sato , Rich Felker , "David S. Miller" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , "H. Peter Anvin" , Chris Zankel , Max Filippov , Alexander Viro , Arnd Bergmann , Andrew Morton , Aleksa Sarai , Xiaoming Ni , David Rientjes , Willem de Bruijn , Christian Brauner , Miklos Szeredi , Minchan Kim , "Eric W. Biederman" , Stephen Rothwell , Vincenzo Frascino , Vlastimil Babka , Oleg Nesterov , YueHaibing , Suren Baghdasaryan , Nicholas Piggin , Brian Gerst , Dominik Brodowski , Jan Kara , Arnaldo Carvalho de Melo , "linux-alpha@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-ia64@vger.kernel.org" , "linux-m68k@lists.linux-m68k.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , "linux-sh@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-xtensa@linux-xtensa.org" , "linux-fsdevel@vger.kernel.org" , "linux-api@vger.kernel.org" , "linux-arch@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 15, 2021 at 9:01 PM David Laight wrote: > > From: sonicadvance1@gmail.com > > Sent: 15 January 2021 07:03 > > Problem presented: > > A backwards compatibility layer that allows running x86-64 and x86 > > processes inside of an AArch64 process. > > - CPU is emulated > > - Syscall interface is mostly passthrough > > - Some syscalls require patching or emulation depending on behaviour > > - Not viable from the emulator design to use an AArch32 host process > > > > You are going to need to add all the x86 compatibility code into > your arm64 kernel. > This is likely to be different from the 32bit arm compatibility > because 64bit items are only aligned on 32bit boundaries. > The x86 x32 compatibility will be more like the 32bit arm 'compat' > code - I'm pretty sure arm32 64bit aligned 64bit data. All other architectures that have both 32-bit and 64-bit variants use the same alignment for all types, except for x86. There are additional differences though, especially if one were to try to generalize the interface to all architectures. A subset of the issues includes - x32 has 64-bit types in places of some types that are 32 bit everywhere else (time_t, ino_t, off_t, clock_t, ...) - m68k aligns struct members to at most 16 bits - uid_t/gid_t/ino_t/dev_t/... are > You'll then need to remember how the process entered the kernel > to work out which compatibility code to invoke. > This is what x86 does. > It allows a single process to do all three types of system call. > > Trying to 'patch up' structures outside the kernel, or in the > syscall interface code will always cause grief somewhere. > The only sane place is in the code that uses the structures. > Which, for ioctls, means inside the driver that parses them. He's already doing the system call emulation for all the system calls other than ioctl in user space though. In my experience, there are actually fairly few ioctl commands that are different between architectures -- most of them have no misaligned or architecture-defined struct members at all. Once you have conversion functions to deal with the 32/64-bit interface differences and architecture specifics of sockets, sysvipc, signals, stat, and input_event, handling the x86-32 specific ioctl commands is comparably easy. Arnd