[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b15672b1caec4cf980f2753d06b03596@AcuMS.aculab.com>
Date: Fri, 15 Jan 2021 20:01:15 +0000
From: David Laight <David.Laight@...LAB.COM>
To: "'sonicadvance1@...il.com'" <sonicadvance1@...il.com>
CC: Richard Henderson <rth@...ddle.net>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
Matt Turner <mattst88@...il.com>,
Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
"Will Deacon" <will@...nel.org>, Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
"Michal Simek" <monstr@...str.eu>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
Helge Deller <deller@....de>,
Michael Ellerman <mpe@...erman.id.au>,
"Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Heiko Carstens <hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ibm.com>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Rich Felker <dalias@...c.org>,
"David S. Miller" <davem@...emloft.net>,
Andy Lutomirski <luto@...nel.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"Borislav Petkov" <bp@...en8.de>,
"x86@...nel.org" <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, Chris Zankel <chris@...kel.net>,
Max Filippov <jcmvbkbc@...il.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Arnd Bergmann <arnd@...db.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Aleksa Sarai <cyphar@...har.com>,
Xiaoming Ni <nixiaoming@...wei.com>,
David Rientjes <rientjes@...gle.com>,
Willem de Bruijn <willemb@...gle.com>,
"Christian Brauner" <christian.brauner@...ntu.com>,
Miklos Szeredi <mszeredi@...hat.com>,
Minchan Kim <minchan@...nel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"Vincenzo Frascino" <vincenzo.frascino@....com>,
Vlastimil Babka <vbabka@...e.cz>,
Oleg Nesterov <oleg@...hat.com>,
YueHaibing <yuehaibing@...wei.com>,
"Suren Baghdasaryan" <surenb@...gle.com>,
Nicholas Piggin <npiggin@...il.com>,
Brian Gerst <brgerst@...il.com>,
Dominik Brodowski <linux@...inikbrodowski.net>,
Jan Kara <jack@...e.cz>,
"Arnaldo Carvalho de Melo" <acme@...hat.com>,
"linux-alpha@...r.kernel.org" <linux-alpha@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
"linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
"linux-xtensa@...ux-xtensa.org" <linux-xtensa@...ux-xtensa.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: RE: [PATCH] Adds a new ioctl32 syscall for backwards compatibility
layers
From: sonicadvance1@...il.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.
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.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists