From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EEC7EC433DB for ; Sat, 16 Jan 2021 22:42:02 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3ADCC20643 for ; Sat, 16 Jan 2021 22:41:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3ADCC20643 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4DJCj223yWzDsmw for ; Sun, 17 Jan 2021 09:41:58 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aculab.com (client-ip=185.58.86.151; helo=eu-smtp-delivery-151.mimecast.com; envelope-from=david.laight@aculab.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=ACULAB.COM Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.86.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4DHXBP20z3zDvVV for ; Sat, 16 Jan 2021 07:01:32 +1100 (AEDT) Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-79-PS3OFpBZPgGXINPuMHjjeQ-1; Fri, 15 Jan 2021 20:01:22 +0000 X-MC-Unique: PS3OFpBZPgGXINPuMHjjeQ-1 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Jan 2021 20:01:15 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Fri, 15 Jan 2021 20:01:15 +0000 From: David Laight To: "'sonicadvance1@gmail.com'" Subject: RE: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers Thread-Topic: [PATCH] Adds a new ioctl32 syscall for backwards compatibility layers Thread-Index: AQHW6wzXd1V6Thk8U0iiUgMFo8hTJqopEBwA Date: Fri, 15 Jan 2021 20:01:15 +0000 Message-ID: References: <20210106064807.253112-1-Sonicadvance1@gmail.com> <20210115070326.294332-1-Sonicadvance1@gmail.com> In-Reply-To: <20210115070326.294332-1-Sonicadvance1@gmail.com> Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C51A453 smtp.mailfrom=david.laight@aculab.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 17 Jan 2021 09:38:28 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-xtensa@linux-xtensa.org" , Rich Felker , Jan Kara , Miklos Szeredi , Dominik Brodowski , "linux-kernel@vger.kernel.org" , "James E.J. Bottomley" , Max Filippov , Paul Mackerras , "H. Peter Anvin" , "sparclinux@vger.kernel.org" , "linux-ia64@vger.kernel.org" , Christian Brauner , Vincenzo Frascino , Will Deacon , "linux-arch@vger.kernel.org" , Stephen Rothwell , Arnd Bergmann , Yoshinori Sato , "linux-sh@vger.kernel.org" , Helge Deller , "x86@kernel.org" , YueHaibing , Russell King , Christian Borntraeger , Ingo Molnar , Geert Uytterhoeven , "linux-arm-kernel@lists.infradead.org" , Catalin Marinas , Matt Turner , "linux-mips@vger.kernel.org" , Fenghua Yu , Arnaldo Carvalho de Melo , Vasily Gorbik , "linux-s390@vger.kernel.org" , Brian Gerst , Heiko Carstens , David Rientjes , Willem de Bruijn , Nicholas Piggin , Suren Baghdasaryan , Aleksa Sarai , Thomas Bogendoerfer , Ivan Kokshaysky , Alexander Viro , Andy Lutomirski , Thomas Gleixner , Xiaoming Ni , Vlastimil Babka , Richard Henderson , Chris Zankel , Michal Simek , Tony Luck , "linux-parisc@vger.kernel.org" , "linux-m68k@lists.linux-m68k.org" , "linux-api@vger.kernel.org" , Oleg Nesterov , Minchan Kim , "Eric W. Biederman" , "linux-alpha@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , Borislav Petkov , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 >=20 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. 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. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)