From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966444AbcIWSXp (ORCPT ); Fri, 23 Sep 2016 14:23:45 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:51178 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933869AbcIWSXn (ORCPT ); Fri, 23 Sep 2016 14:23:43 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Stuart Yoder , Robin Murphy , Jason Jin , Leo Li , Alison Wang , "linux@armlinux.org.uk" , "linux-kernel@vger.kernel.org" , "kernel@pengutronix.de" , Fabio Estevam Estevam , Scott Wood , "shawnguo@kernel.org" Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms Date: Fri, 23 Sep 2016 20:22:58 +0200 Message-ID: <4642389.nHAzKPNi96@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1474597146-33312-1-git-send-email-b18965@freescale.com> <2519047.ijr708V79a@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:1NpiUMdtTjiaXdA9tSw65muMmHoyhAABaGdaU24e38jfKhdU4ue T9ZVaa7IYmSFMgzBwFFN0bZUZp3zWDtlMA+ptmEXYIEYJ5IT3qT28EQucqGj3a+IPE1i0pM nFuXFnCnuBhjkJluGtoZtSTzip/5edq77t0lKwXfkn4uThOyJ+aBRekCL3NiqNIeRtIBJSv i2995Jh+VNQzGgXF5Wzrg== X-UI-Out-Filterresults: notjunk:1;V01:K0:jkORLQq6bvM=:nHp/LE89OVP58P3D9kHN5N swhhoMhKt0qrojMC1sKEJ6Rn2yiyuqVnpVLZmg3x1khqxFeDPriGWRf+9WbcmqvUh7xs+IPvd HLsW+1ZAM8FOll1J8gS563p68n2TjmISS+o0dq3QXwAXBzIhveMNbyQhMbavpZ12VPzp0X5MP uSjeunXY0i8vOY4nNRC5ZJpmv+OMySpjyobWCcpTFM6KjpPb1rgQTngHc/zzot6eOrP2+TXAc 4uqou+k8NfjkiRYiIjzhfwAAB4SOoOn3HR1kW3nd4JOSSWnn7WY+W5htPndGeGzE/kyv4wXeS 9GipLIRCZioFwt4Mzea6KrVywKfbhs9SbDrgiazPOh5/73WsFg8AYwl3ewq5RFb8EmjbwYYcb F2iXqWdmswcWECllwaAvylgzGoq/6l432U/dSnDVsUFVByrxAWj1K8GUBQVeBh9s9KtbIAcJg KevRGJUEzRUEs1Jw8gK40/NmZ19bFkUicbA8/c1TaE+YgepWYiOONNxB9v6UOL3pbxiJJXX2G 9RwMOLQjZ6L3OHPruBIRS1k19vGEbnjMkOUhO1Cp3MopNNx5NSbX4NGHDZCGBy6rz/Ikmq8SC hRh50uzAG+zHht9alT4B5+Qqg4al2gyuPMUcFX5FCEsziJXDlw+04I/o+iaqQ+wZdohNlfWeO U8jyYY8/9V8o+jpp5E+h8fLZwRX/M3pbR2TSp5yUI9XAG61yxePcmwftEDEGOjdNrWaP7x3Fn ajkeOwNYTnO9lSvP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, September 23, 2016 4:09:29 PM CEST Stuart Yoder wrote: > > -----Original Message----- > > From: Arnd Bergmann [mailto:arnd@arndb.de] > > Sent: Friday, September 23, 2016 10:58 AM > > > Really, though, the firmware call thing is an incredibly niche use-case. > > > Beyond development, the only real benefit of starting an AArch32 kernel > > > in Hyp is that you can run AArch32 KVM guests, which you can do equally > > > well (if not better) under an AArch64 kernel. > > > > This was my question earlier in the thread, apparently Alison has > > another use case in mind, but I don't yet know what that is. If > > that use case is important enough, we could do it this way. > > > > The only use case I can think of at the moment is boot testing > > on kernelci.org, which could be used to check whether all the drivers > > work in 32-bit environments. > > The reason we want aarch32 kernel support is for specific customers that > have requirements for legacy 32-bit kernel drivers that function on ARMv7 > but for some reason are very problematic to port to a 64-bit kernel. So, > the way to ease the 64-bit transition is allow them to run an aarch32 kernel > and their driver on an ARMv8 SoC. I don't think we specifically care > whether the kernel starts at EL2 or EL1. Thanks for the explanation. Unfortunately I don't think that helps get this approach upstream, in particular I wouldn't want to add a platform specific hack just to help a third party not have to fix their out-of-tree drivers to be 64-bit clean. If your customer already has a chunk of downstream patches large enough to be problematic to rebuild for 64-bit, they should be able to also pick up these two patches, but of course what we really want is to get drivers upstream and fixed (presumably this would be an even larger task than just fixing them, so I don't set my hopes too high here). I'm still not opposed to making *all* 64-bit platforms available to 32-bit kernels for testing purposes though, and that would solve the customer problem too, as would the approach of encapsulating the kernel in hypervisor stub that implements the PSCI calls and using MACH_VIRT with the respective layerscape drivers enabled. Arnd