| Message ID | 20180926135110.13061-1-Jason@zx2c4.com |
|---|---|
| State | New |
| Headers | show |
| Series | arm: support big-endian for the virt architecture | expand |
(+ arm-soc) On 26 September 2018 at 15:51, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > This architecture, used for running in QEMU, runs just fine when > compiled in big-endian mode. So enable it. This is enabled in exactly > the same way that it is for other platforms (such as vexpress) that also > support big-endian mode in QEMU successfully. > > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > --- > Personally, I'm using this as part of WireGuard's CI, and patching > kernels to include this is a bit annoying. Any chance this can get into > 4.19? > > arch/arm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index e8cd55a5b04c..b8c6062ca0c1 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -701,6 +701,7 @@ config ARCH_VIRT > select ARM_GIC_V3_ITS if PCI > select ARM_PSCI > select HAVE_ARM_ARCH_TIMER > + select ARCH_SUPPORTS_BIG_ENDIAN > > # > # This is sorted alphabetically by mach-* pathname. However, plat-* > -- > 2.19.0 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Sep 26, 2018 at 3:52 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > This architecture, used for running in QEMU, runs just fine when > compiled in big-endian mode. So enable it. This is enabled in exactly > the same way that it is for other platforms (such as vexpress) that also > support big-endian mode in QEMU successfully. > > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> > --- > Personally, I'm using this as part of WireGuard's CI, and patching > kernels to include this is a bit annoying. Any chance this can get into > 4.19? > > arch/arm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index e8cd55a5b04c..b8c6062ca0c1 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -701,6 +701,7 @@ config ARCH_VIRT > select ARM_GIC_V3_ITS if PCI > select ARM_PSCI > select HAVE_ARM_ARCH_TIMER > + select ARCH_SUPPORTS_BIG_ENDIAN Applied for 4.20 with subject line changed s/arm/ARM/, thanks! We don't really handle this well in general, by allowing a big-endian build if any of the enabled platforms select ARCH_SUPPORTS_BIG_ENDIAN, rather than making sure that /all/ of them do. I think most people just build a 'defconfig' kernel, which includes multiple platforms that use ARCH_SUPPORTS_BIG_ENDIAN. A better way to do this might be to assume ARCH_SUPPORTS_BIG_ENDIAN for ARCH_MULTIPLATFORM, and then mark all platforms that are known to be broken as 'depends on !CPU_BIG_ENDIAN'. Your patch is certainly fine for 4.20, but since we haven't decided what the proper fix should be, I didn't want to push this for 4.19. Arnd
Hi Arnd, On Fri, Sep 28, 2018 at 5:59 PM Arnd Bergmann <arnd@arndb.de> wrote: > Applied for 4.20 with subject line changed s/arm/ARM/, thanks! Thanks. > I think most people just build a 'defconfig' kernel, which includes > multiple platforms that use ARCH_SUPPORTS_BIG_ENDIAN. Right, that's what it looked like. In my case, I'm doing CI on some homebrewed infra, where I'm building lots of kernels for lots of architectures and testing them in qemu with various tests _for each and every commit_. Not having a server farm as impressive as Intel's 0-day infra, getting compilation times down is rather important. > Your patch is certainly fine for 4.20, but since we haven't decided > what the proper fix should be, I didn't want to push this for 4.19. Shucks. It's not like this patch makes the situation worse; it makes it better. But I understand and will wait for 4.20/5.0. Jason
On Fri, Sep 28, 2018 at 6:04 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Hi Arnd, > > On Fri, Sep 28, 2018 at 5:59 PM Arnd Bergmann <arnd@arndb.de> wrote: > > Applied for 4.20 with subject line changed s/arm/ARM/, thanks! > > Thanks. > > > I think most people just build a 'defconfig' kernel, which includes > > multiple platforms that use ARCH_SUPPORTS_BIG_ENDIAN. > > Right, that's what it looked like. In my case, I'm doing CI on some > homebrewed infra, where I'm building lots of kernels for lots of > architectures and testing them in qemu with various tests _for each > and every commit_. Not having a server farm as impressive as Intel's > 0-day infra, getting compilation times down is rather important. You can probably work around it by enabling ARCH_HIGHBANK, which is a minimal platform with no other requirements, so it should only add a few milliseconds to the build. Another option would be to do the testing on top of linux-next, which should have your fix starting on Monday. Testing on linux-next carries a higher risk of running into unrelated regressions, but also lets you find out about conflicts with other patches early on. Arnd
Hey Arnd, On Fri, Sep 28, 2018 at 9:19 PM Arnd Bergmann <arnd@arndb.de> wrote: > You can probably work around it by enabling ARCH_HIGHBANK, > which is a minimal platform with no other requirements, so it > should only add a few milliseconds to the build. Nice hack, thanks for the suggestion. Committed here: https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/WireGuard.git/commit/?id=56ff2eb9480e6c691a5b8d8ff1fa01090df61e1d > Another option would be to do the testing on top of linux-next, > which should have your fix starting on Monday. Testing on > linux-next carries a higher risk of running into unrelated > regressions, but also lets you find out about conflicts with > other patches early on. I do actually test on linux-next (and tons of other kernels too), but I like to have things working for at least the latest mainline. Jason
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e8cd55a5b04c..b8c6062ca0c1 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -701,6 +701,7 @@ config ARCH_VIRT select ARM_GIC_V3_ITS if PCI select ARM_PSCI select HAVE_ARM_ARCH_TIMER + select ARCH_SUPPORTS_BIG_ENDIAN # # This is sorted alphabetically by mach-* pathname. However, plat-*
This architecture, used for running in QEMU, runs just fine when compiled in big-endian mode. So enable it. This is enabled in exactly the same way that it is for other platforms (such as vexpress) that also support big-endian mode in QEMU successfully. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- Personally, I'm using this as part of WireGuard's CI, and patching kernels to include this is a bit annoying. Any chance this can get into 4.19? arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) -- 2.19.0