From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759432AbcIWP67 (ORCPT ); Fri, 23 Sep 2016 11:58:59 -0400 Received: from mout.kundenserver.de ([212.227.126.134]:51066 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758649AbcIWP65 (ORCPT ); Fri, 23 Sep 2016 11:58:57 -0400 From: Arnd Bergmann To: Robin Murphy Cc: linux-arm-kernel@lists.infradead.org, Stuart Yoder , Alison Wang , "shawnguo@kernel.org" , "kernel@pengutronix.de" , Fabio Estevam Estevam , "linux@armlinux.org.uk" , "linux-kernel@vger.kernel.org" , Scott Wood , Leo Li , Jason Jin Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms Date: Fri, 23 Sep 2016 17:58:11 +0200 Message-ID: <2519047.ijr708V79a@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> <2017806.nj5EEu7nrO@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:8EIYvGnpWsKiNb1ab48Px8fna/Qu/ERWp1IjrR/kHtbGWFTImEn YPbjoCh6UNf41VBI5OuxDIeEeGGSeD3j8m14V+fqjL4yZ5ClrpDOsnox8rLkCnDlqA6ETzQ yNso0hEqv5+EhI8XYH33xxm8Uq/ZwrgBJTAIk5X1XbTEVWljjhwbamjlBlLJL7swDCSqUVh RI2ScKxLSM7v0DLt/NKWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:y7G34u9gCok=:uc1bQN1SZUAMaPL6q6vtDH QaBXtL7mEo5US36TL1bm96WA/FH0v/vY4/1JJM/GQjM2TTcJAkGO2UVzknpU9SUTrmKESSu6D PjTEp74Oh8g59c8wdg+DQw1VSR/5zqN6lN+I9VOSoPjXncJbAVotm8PSG1MP/Y3WtE4VB8IQK +s1e8ActkkYd/yGWqMBcXVKF5F84/DB5Qb56R06WK9fEv6hIsmx9vgqgbN8QA+JAjtaFnASNG 77jXu+l5hMYWJHOIqAo4WLWoO3oX9aAJWbLB97FS6hM6I5xM/pcnLWdbE/P8dpMJ+a6B629Lp jegNXNzBzVfll1FV2GbHHiwfpZF53/37yv1CTtTh9G/GWXlafuG72HuOossXeBCgbJk4Z4z/L dsyUGFQFlUQJftkvwlY42edB6bXv8xjPrpV6H3uHfwpLFpyqFK97beaA5yOJyq3ETm+yrZorO sLtp5ZhNIbrN9YdFpXXX2UGhFJ6jLKaifd9aKdZXvLhmPWtBZzVws6+FBaarn4Ni+hK/6+Av5 x3IWyzmPH9+RsUptwz+Nz25JED3sKabSIQDNmSVuJojb4ExaqcndCNgVHqw7cluf0i8YZPIlX gmaYY68p1Q5zN2am6I8Qh+PKvNL/GxhCR9tO/WK0ThasR5HES2XIXQkmtrov6/ja8ulnjQdIR UEpQ5fd97yKf+LaRpofUl6VboI5Utxt0QB+4k7OYOLZrKMzIzi5cyf/e2QCiA53UENgD7W7lM HerUXNoc97+VG36T Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, September 23, 2016 4:13:30 PM CEST Robin Murphy wrote: > On 23/09/16 15:44, Arnd Bergmann wrote: > > On Friday, September 23, 2016 3:24:12 PM CEST Robin Murphy wrote: > >> On 23/09/16 15:01, Stuart Yoder wrote: > >> Otherwise you can > >> always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll > >> need to trap and translate subsequent SMC calls for e.g. PSCI). > >> > >>> If there is such a requirement, it's something begging for standardization. > >>> Doesn't make sense for multiple divergent approaches for switching from > >>> aarch64/EL2 to aarch32/EL2. > >> > >> Perhaps - I did briefly look into how hard it would be to write a proper > >> SMC service handler to do this (since ATF does have a framework for such > >> things), but concluded it would be more than 10 minutes' work and just > >> cheated instead. It's certainly something which could be raised with the > >> firmware folks. > > > > If we end up allowing all arm64 platforms to be enabled in arch/arm, > > we could perhaps create a generic implementation that does both of > > those things, i.e. > > > > - Take the arm32 kernel Image or zImage file, wrap it inside of a binary > > that implements the arm64 boot protocol. > > - When that starts up, try to use the new PSCI call to jump into > > the arm32 kernel > > - If PSCI failed and we are running in EL2, implement the shim > > and start the arm32 kernel in EL1 mode > > 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. Arnd