All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "kernelci.org bot" <bot@kernelci.org>,
	Arnd Bergmann <arnd@arndb.de>,
	tomeu.vizoso@collabora.com, Nicolas Pitre <nico@fluxnic.net>,
	Guillaume Tucker <guillaume.tucker@collabora.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Stefan Agner <stefan@agner.ch>,
	Russell King <linux@armlinux.org.uk>,
	Russell King <rmk+kernel@armlinux.org.uk>,
	Mark Brown <broonie@kernel.org>,
	Matt Hart <matthew.hart@linaro.org>,
	mgalka@collabora.com,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ard Biesheuvel <ardb@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Kevin Hilman <khilman@baylibre.com>
Subject: Re: rmk/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
Date: Sat, 16 Nov 2019 12:32:44 +0000	[thread overview]
Message-ID: <20191116123244.7be79023@why> (raw)
In-Reply-To: <CAKv+Gu_r2Cb3d3OXaOdYy+4V9noL6exJoK6pHevUm2WfPzsr1g@mail.gmail.com>

On Sat, 16 Nov 2019 10:26:27 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> (+ Arnd)
> 
> On Sat, 16 Nov 2019 at 05:54, kernelci.org bot <bot@kernelci.org> wrote:
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> > * This automated bisection report was sent to you on the basis  *
> > * that you may be involved with the breaking commit it has      *
> > * found.  No manual investigation has been done to verify it,   *
> > * and the root cause of the problem may be somewhere else.      *
> > *                                                               *
> > * If you do send a fix, please include this trailer:            *
> > *   Reported-by: "kernelci.org bot" <bot@kernelci.org>          *
> > *                                                               *
> > * Hope this helps!                                              *
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >
> > rmk/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
> >
> > Summary:
> >   Start:      b6c3c42cfda0 ARM: 8938/1: kernel: initialize broadcast hrtimer based clock event device
> >   Details:    https://kernelci.org/boot/id/5dcf3f0359b514dc84cf54c8
> >   Plain log:  https://storage.kernelci.org//rmk/for-next/v5.4-rc5-26-gb6c3c42cfda0/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt
> >   HTML log:   https://storage.kernelci.org//rmk/for-next/v5.4-rc5-26-gb6c3c42cfda0/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820-cloudengines-pogoplug-series-3.html
> >   Result:     ea70bf6e92c5 ARM: 8935/1: decompressor: avoid CP15 barrier instructions in v7 cache setup code
> >  
> 
> OK, so this regression is caused by the fact that the 'armv7' cache
> maintenance routines in the decompressor are also used for ARMv6 cores
> if they implement the CPUID extension, which I failed to realise when
> I sent this patch.

Nobody expects the 11MPcore... :-(.

> There are roughly three ways to deal with this:
> 1) add a mask/val match pair for ARM11MPcore and ARM1176 that hardwire
> them to the ARMv6 routines, even though they implement the CPUID
> extension. This would be very easy, but assumes that those two cores
> are the only ones that are affected by this.
> 2) modify the v7 routines to check for the L1Hvd MMFR1 attribute (in
> the flush routine) and for the CP15BEN SCTLR bit (in the on/off
> routines), and jump to the respective v6 variants if the CPU turns out
> not to support the v7 one.
> 3) revert the patch, and just enable the CP15 barriers (and issue a v7
> barrier) in the v7 on() and flush() routines.
> 
> I am leaning towards the latter, since it is the most straightforward,
> even though it mixes v7 and cp15 barriers in the same function, but
> that was mostly a cosmetic concern anyway.

A potential alternative is to check for the presence of architected
barriers in a macro (see the hack below). I've given it a go as a 32bit
guest on an A72 box, both as ARM and Thumb, and nothing caught fire. Of
course, it remains to be seen whether it works on a v6 machine (I don't
think I have any left in my zoo -- please don't send me any), and more
importantly whether we want to carry this kind of horror...

	M.

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index ec14687aea3c..144de4b08547 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -656,19 +656,40 @@ params:		ldr	r0, =0x10000100		@ params_phys for RPC
 		.align
 #endif
 
-		.macro	v7dsb
+		@ Check for architected barrier instructions
+		@ Branch to the tgt label if v7 barriers are
+		@ not available. Corrupts the tmp register
+		@ as well as the flags.
+		.macro	no_v7_barrier, tmp, tgt
+		mrc	p15, 0, \tmp, c0, c2, 4 @ ID_ISAR4
+		tst	\tmp, #0xf << 16
+		beq	\tgt
+		.endm
+
+		@ The following macros will use zreg as a temp
+		@ register, and will zero it after use.
+		.macro	__dsb, zreg
+		no_v7_barrier	\zreg, .L__dsb\@
  ARM(		.inst	0xf57ff04f		@ v7+ dsb	)
  THUMB(		dsb						)
+		mov	\zreg, #0
+.L__dsb\@:	mcreq	p15, 0, \zreg, c7, c10, 4 @ dsb
 		.endm
 
-		.macro	v7dmb
+		.macro	__dmb, zreg
+		no_v7_barrier	\zreg, .L__dmb\@
  ARM(		.inst	0xf57ff05f		@ v7+ dmb	)
  THUMB(		dmb						)
+		mov	\zreg, #0
+.L__dmb\@:	mcreq	p15, 0, \zreg, c7, c10, 5 @ dmb
 		.endm
 
-		.macro	v7isb
+		.macro	__isb, zreg
+		no_v7_barrier	\zreg, .L__isb\@
  ARM(		.inst	0xf57ff06f		@ v7+ isb	)
  THUMB(		isb						)
+		mov	\zreg, #0
+.L__isb\@:	mcreq	p15, 0, \zreg, c7, c5, 4 @ isb
 		.endm
 
 /*
@@ -841,8 +862,7 @@ __armv7_mmu_cache_on:
 		tst	r11, #0xf		@ VMSA
 		movne	r6, #CB_BITS | 0x02	@ !XN
 		blne	__setup_mmu
-		mov	r0, #0
-		v7dsb				@ drain write buffer
+		__dsb	r0			@ drain write buffer
 		tst	r11, #0xf		@ VMSA
 		mcrne	p15, 0, r0, c8, c7, 0	@ flush I,D TLBs
 #endif
@@ -864,11 +884,10 @@ __armv7_mmu_cache_on:
 		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
 		mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
 #endif
-		v7isb
+		__isb	lr
 		mcr	p15, 0, r0, c1, c0, 0	@ load control register
 		mrc	p15, 0, r0, c1, c0, 0	@ and read it back
-		mov	r0, #0
-		v7isb
+		__isb	r0
 		mov	pc, r12
 
 __fa526_cache_on:
@@ -1169,8 +1188,8 @@ __armv7_mmu_cache_off:
 		mcr	p15, 0, r0, c8, c7, 0	@ invalidate whole TLB
 #endif
 		mcr	p15, 0, r0, c7, c5, 6	@ invalidate BTC
-		v7dsb
-		v7isb
+		__dsb	r0
+		__isb	r0
 		mov	pc, r12
 
 /*
@@ -1233,7 +1252,7 @@ __armv7_mmu_cache_flush:
 		mcr	p15, 0, r10, c7, c14, 0	@ clean+invalidate D
 		b	iflush
 hierarchical:
-		v7dmb
+		__dmb	r10
 		stmfd	sp!, {r0-r7, r9-r11}
 		mrc	p15, 1, r0, c0, c0, 1	@ read clidr
 		ands	r3, r0, #0x7000000	@ extract loc from clidr
@@ -1247,7 +1266,7 @@ loop1:
 		cmp	r1, #2			@ see what cache we have at this level
 		blt	skip			@ skip if no cache, or just i-cache
 		mcr	p15, 2, r10, c0, c0, 0	@ select current cache level in cssr
-		v7isb				@ isb to sych the new cssr&csidr
+		__isb	r1			@ isb to sych the new cssr&csidr
 		mrc	p15, 1, r1, c0, c0, 0	@ read the new csidr
 		and	r2, r1, #7		@ extract the length of the cache lines
 		add	r2, r2, #4		@ add 4 (line length offset)
@@ -1279,10 +1298,10 @@ finished:
 		mov	r10, #0			@ switch back to cache level 0
 		mcr	p15, 2, r10, c0, c0, 0	@ select current cache level in cssr
 iflush:
-		v7dsb
+		__dsb	r10
 		mcr	p15, 0, r10, c7, c5, 0	@ invalidate I+BTB
-		v7dsb
-		v7isb
+		__dsb	r10
+		__isb	r10
 		mov	pc, lr
 
 __armv5tej_mmu_cache_flush:

-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "kernelci.org bot" <bot@kernelci.org>,
	Arnd Bergmann <arnd@arndb.de>, Ard Biesheuvel <ardb@kernel.org>,
	tomeu.vizoso@collabora.com,
	Guillaume Tucker <guillaume.tucker@collabora.com>,
	mgalka@collabora.com, Russell King <rmk+kernel@armlinux.org.uk>,
	Mark Brown <broonie@kernel.org>,
	Matt Hart <matthew.hart@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stefan Agner <stefan@agner.ch>, Nicolas Pitre <nico@fluxnic.net>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: rmk/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
Date: Sat, 16 Nov 2019 12:32:44 +0000	[thread overview]
Message-ID: <20191116123244.7be79023@why> (raw)
In-Reply-To: <CAKv+Gu_r2Cb3d3OXaOdYy+4V9noL6exJoK6pHevUm2WfPzsr1g@mail.gmail.com>

On Sat, 16 Nov 2019 10:26:27 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> (+ Arnd)
> 
> On Sat, 16 Nov 2019 at 05:54, kernelci.org bot <bot@kernelci.org> wrote:
> >
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> > * This automated bisection report was sent to you on the basis  *
> > * that you may be involved with the breaking commit it has      *
> > * found.  No manual investigation has been done to verify it,   *
> > * and the root cause of the problem may be somewhere else.      *
> > *                                                               *
> > * If you do send a fix, please include this trailer:            *
> > *   Reported-by: "kernelci.org bot" <bot@kernelci.org>          *
> > *                                                               *
> > * Hope this helps!                                              *
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >
> > rmk/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3
> >
> > Summary:
> >   Start:      b6c3c42cfda0 ARM: 8938/1: kernel: initialize broadcast hrtimer based clock event device
> >   Details:    https://kernelci.org/boot/id/5dcf3f0359b514dc84cf54c8
> >   Plain log:  https://storage.kernelci.org//rmk/for-next/v5.4-rc5-26-gb6c3c42cfda0/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820-cloudengines-pogoplug-series-3.txt
> >   HTML log:   https://storage.kernelci.org//rmk/for-next/v5.4-rc5-26-gb6c3c42cfda0/arm/oxnas_v6_defconfig/gcc-8/lab-baylibre/boot-ox820-cloudengines-pogoplug-series-3.html
> >   Result:     ea70bf6e92c5 ARM: 8935/1: decompressor: avoid CP15 barrier instructions in v7 cache setup code
> >  
> 
> OK, so this regression is caused by the fact that the 'armv7' cache
> maintenance routines in the decompressor are also used for ARMv6 cores
> if they implement the CPUID extension, which I failed to realise when
> I sent this patch.

Nobody expects the 11MPcore... :-(.

> There are roughly three ways to deal with this:
> 1) add a mask/val match pair for ARM11MPcore and ARM1176 that hardwire
> them to the ARMv6 routines, even though they implement the CPUID
> extension. This would be very easy, but assumes that those two cores
> are the only ones that are affected by this.
> 2) modify the v7 routines to check for the L1Hvd MMFR1 attribute (in
> the flush routine) and for the CP15BEN SCTLR bit (in the on/off
> routines), and jump to the respective v6 variants if the CPU turns out
> not to support the v7 one.
> 3) revert the patch, and just enable the CP15 barriers (and issue a v7
> barrier) in the v7 on() and flush() routines.
> 
> I am leaning towards the latter, since it is the most straightforward,
> even though it mixes v7 and cp15 barriers in the same function, but
> that was mostly a cosmetic concern anyway.

A potential alternative is to check for the presence of architected
barriers in a macro (see the hack below). I've given it a go as a 32bit
guest on an A72 box, both as ARM and Thumb, and nothing caught fire. Of
course, it remains to be seen whether it works on a v6 machine (I don't
think I have any left in my zoo -- please don't send me any), and more
importantly whether we want to carry this kind of horror...

	M.

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index ec14687aea3c..144de4b08547 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -656,19 +656,40 @@ params:		ldr	r0, =0x10000100		@ params_phys for RPC
 		.align
 #endif
 
-		.macro	v7dsb
+		@ Check for architected barrier instructions
+		@ Branch to the tgt label if v7 barriers are
+		@ not available. Corrupts the tmp register
+		@ as well as the flags.
+		.macro	no_v7_barrier, tmp, tgt
+		mrc	p15, 0, \tmp, c0, c2, 4 @ ID_ISAR4
+		tst	\tmp, #0xf << 16
+		beq	\tgt
+		.endm
+
+		@ The following macros will use zreg as a temp
+		@ register, and will zero it after use.
+		.macro	__dsb, zreg
+		no_v7_barrier	\zreg, .L__dsb\@
  ARM(		.inst	0xf57ff04f		@ v7+ dsb	)
  THUMB(		dsb						)
+		mov	\zreg, #0
+.L__dsb\@:	mcreq	p15, 0, \zreg, c7, c10, 4 @ dsb
 		.endm
 
-		.macro	v7dmb
+		.macro	__dmb, zreg
+		no_v7_barrier	\zreg, .L__dmb\@
  ARM(		.inst	0xf57ff05f		@ v7+ dmb	)
  THUMB(		dmb						)
+		mov	\zreg, #0
+.L__dmb\@:	mcreq	p15, 0, \zreg, c7, c10, 5 @ dmb
 		.endm
 
-		.macro	v7isb
+		.macro	__isb, zreg
+		no_v7_barrier	\zreg, .L__isb\@
  ARM(		.inst	0xf57ff06f		@ v7+ isb	)
  THUMB(		isb						)
+		mov	\zreg, #0
+.L__isb\@:	mcreq	p15, 0, \zreg, c7, c5, 4 @ isb
 		.endm
 
 /*
@@ -841,8 +862,7 @@ __armv7_mmu_cache_on:
 		tst	r11, #0xf		@ VMSA
 		movne	r6, #CB_BITS | 0x02	@ !XN
 		blne	__setup_mmu
-		mov	r0, #0
-		v7dsb				@ drain write buffer
+		__dsb	r0			@ drain write buffer
 		tst	r11, #0xf		@ VMSA
 		mcrne	p15, 0, r0, c8, c7, 0	@ flush I,D TLBs
 #endif
@@ -864,11 +884,10 @@ __armv7_mmu_cache_on:
 		mcrne	p15, 0, r1, c3, c0, 0	@ load domain access control
 		mcrne   p15, 0, r6, c2, c0, 2   @ load ttb control
 #endif
-		v7isb
+		__isb	lr
 		mcr	p15, 0, r0, c1, c0, 0	@ load control register
 		mrc	p15, 0, r0, c1, c0, 0	@ and read it back
-		mov	r0, #0
-		v7isb
+		__isb	r0
 		mov	pc, r12
 
 __fa526_cache_on:
@@ -1169,8 +1188,8 @@ __armv7_mmu_cache_off:
 		mcr	p15, 0, r0, c8, c7, 0	@ invalidate whole TLB
 #endif
 		mcr	p15, 0, r0, c7, c5, 6	@ invalidate BTC
-		v7dsb
-		v7isb
+		__dsb	r0
+		__isb	r0
 		mov	pc, r12
 
 /*
@@ -1233,7 +1252,7 @@ __armv7_mmu_cache_flush:
 		mcr	p15, 0, r10, c7, c14, 0	@ clean+invalidate D
 		b	iflush
 hierarchical:
-		v7dmb
+		__dmb	r10
 		stmfd	sp!, {r0-r7, r9-r11}
 		mrc	p15, 1, r0, c0, c0, 1	@ read clidr
 		ands	r3, r0, #0x7000000	@ extract loc from clidr
@@ -1247,7 +1266,7 @@ loop1:
 		cmp	r1, #2			@ see what cache we have at this level
 		blt	skip			@ skip if no cache, or just i-cache
 		mcr	p15, 2, r10, c0, c0, 0	@ select current cache level in cssr
-		v7isb				@ isb to sych the new cssr&csidr
+		__isb	r1			@ isb to sych the new cssr&csidr
 		mrc	p15, 1, r1, c0, c0, 0	@ read the new csidr
 		and	r2, r1, #7		@ extract the length of the cache lines
 		add	r2, r2, #4		@ add 4 (line length offset)
@@ -1279,10 +1298,10 @@ finished:
 		mov	r10, #0			@ switch back to cache level 0
 		mcr	p15, 2, r10, c0, c0, 0	@ select current cache level in cssr
 iflush:
-		v7dsb
+		__dsb	r10
 		mcr	p15, 0, r10, c7, c5, 0	@ invalidate I+BTB
-		v7dsb
-		v7isb
+		__dsb	r10
+		__isb	r10
 		mov	pc, lr
 
 __armv5tej_mmu_cache_flush:

-- 
Jazz is not dead. It just smells funny...

  parent reply	other threads:[~2019-11-16 12:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-16  5:54 rmk/for-next bisection: boot on ox820-cloudengines-pogoplug-series-3 kernelci.org bot
2019-11-16  5:54 ` kernelci.org bot
2019-11-16 10:26 ` Ard Biesheuvel
2019-11-16 10:26   ` Ard Biesheuvel
2019-11-16 10:49   ` Russell King - ARM Linux admin
2019-11-16 10:49     ` Russell King - ARM Linux admin
2019-11-16 15:35     ` Ard Biesheuvel
2019-11-16 15:35       ` Ard Biesheuvel
2019-11-16 12:32   ` Marc Zyngier [this message]
2019-11-16 12:32     ` Marc Zyngier
2019-11-16 15:35     ` Ard Biesheuvel
2019-11-16 15:35       ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191116123244.7be79023@why \
    --to=maz@kernel.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bot@kernelci.org \
    --cc=broonie@kernel.org \
    --cc=enric.balletbo@collabora.com \
    --cc=guillaume.tucker@collabora.com \
    --cc=khilman@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=matthew.hart@linaro.org \
    --cc=mgalka@collabora.com \
    --cc=ndesaulniers@google.com \
    --cc=nico@fluxnic.net \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=stefan@agner.ch \
    --cc=tglx@linutronix.de \
    --cc=tomeu.vizoso@collabora.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.