* [PATCH 0/2] arm64: Clear OS Double Lock Register @ 2019-04-08 17:17 Jean-Philippe Brucker 2019-04-08 17:17 ` [PATCH 1/2] arm64: Clear OSDLR_EL1 on CPU boot Jean-Philippe Brucker 2019-04-08 17:17 ` [PATCH 2/2] arm64: Save and restore OSDLR_EL1 Jean-Philippe Brucker 0 siblings, 2 replies; 5+ messages in thread From: Jean-Philippe Brucker @ 2019-04-08 17:17 UTC (permalink / raw) To: catalin.marinas, will.deacon; +Cc: linux-arm-kernel Some firmwares may boot Linux with the OS Double Lock Register set to 1, even though it normally resets to 0. This happens for example on my ThunderX2 machine when hotplugging a CPU or rebooting via kexec. As a result the affected CPU cannot generate debug exceptions from HW breakpoints or single-step. Sanitize the OSDLR value on CPU boot and resume. Jean-Philippe Brucker (2): arm64: Clear OS Double Lock on CPU boot arm64: Save and restore OSDLR_EL1 arch/arm64/kernel/debug-monitors.c | 1 + arch/arm64/mm/proc.S | 34 ++++++++++++++++-------------- 2 files changed, 19 insertions(+), 16 deletions(-) -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 1/2] arm64: Clear OSDLR_EL1 on CPU boot 2019-04-08 17:17 [PATCH 0/2] arm64: Clear OS Double Lock Register Jean-Philippe Brucker @ 2019-04-08 17:17 ` Jean-Philippe Brucker 2019-04-08 17:17 ` [PATCH 2/2] arm64: Save and restore OSDLR_EL1 Jean-Philippe Brucker 1 sibling, 0 replies; 5+ messages in thread From: Jean-Philippe Brucker @ 2019-04-08 17:17 UTC (permalink / raw) To: catalin.marinas, will.deacon; +Cc: linux-arm-kernel Some firmwares may reboot CPUs with OS Double Lock set. Make sure that it is unlocked, in order to use debug exceptions. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> --- arch/arm64/kernel/debug-monitors.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c index d7bb6aefae0a..0fa6db521e44 100644 --- a/arch/arm64/kernel/debug-monitors.c +++ b/arch/arm64/kernel/debug-monitors.c @@ -135,6 +135,7 @@ NOKPROBE_SYMBOL(disable_debug_monitors); */ static int clear_os_lock(unsigned int cpu) { + write_sysreg(0, osdlr_el1); write_sysreg(0, oslar_el1); isb(); return 0; -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH 2/2] arm64: Save and restore OSDLR_EL1 2019-04-08 17:17 [PATCH 0/2] arm64: Clear OS Double Lock Register Jean-Philippe Brucker 2019-04-08 17:17 ` [PATCH 1/2] arm64: Clear OSDLR_EL1 on CPU boot Jean-Philippe Brucker @ 2019-04-08 17:17 ` Jean-Philippe Brucker 2019-04-09 10:37 ` Will Deacon 1 sibling, 1 reply; 5+ messages in thread From: Jean-Philippe Brucker @ 2019-04-08 17:17 UTC (permalink / raw) To: catalin.marinas, will.deacon; +Cc: linux-arm-kernel When the CPU comes out of suspend, the firmware may have modified the OS Double Lock Register. Save it in an unused slot of cpu_suspend_ctx, and restore it on resume. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> --- arch/arm64/mm/proc.S | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S index aa0817c9c4c3..3a621f83e938 100644 --- a/arch/arm64/mm/proc.S +++ b/arch/arm64/mm/proc.S @@ -65,24 +65,25 @@ ENTRY(cpu_do_suspend) mrs x2, tpidr_el0 mrs x3, tpidrro_el0 mrs x4, contextidr_el1 - mrs x5, cpacr_el1 - mrs x6, tcr_el1 - mrs x7, vbar_el1 - mrs x8, mdscr_el1 - mrs x9, oslsr_el1 - mrs x10, sctlr_el1 + mrs x5, osdlr_el1 + mrs x6, cpacr_el1 + mrs x7, tcr_el1 + mrs x8, vbar_el1 + mrs x9, mdscr_el1 + mrs x10, oslsr_el1 + mrs x11, sctlr_el1 alternative_if_not ARM64_HAS_VIRT_HOST_EXTN - mrs x11, tpidr_el1 + mrs x12, tpidr_el1 alternative_else - mrs x11, tpidr_el2 + mrs x12, tpidr_el2 alternative_endif - mrs x12, sp_el0 + mrs x13, sp_el0 stp x2, x3, [x0] - stp x4, xzr, [x0, #16] - stp x5, x6, [x0, #32] - stp x7, x8, [x0, #48] - stp x9, x10, [x0, #64] - stp x11, x12, [x0, #80] + stp x4, x5, [x0, #16] + stp x6, x7, [x0, #32] + stp x8, x9, [x0, #48] + stp x10, x11, [x0, #64] + stp x12, x13, [x0, #80] ret ENDPROC(cpu_do_suspend) @@ -105,8 +106,8 @@ ENTRY(cpu_do_resume) msr cpacr_el1, x6 /* Don't change t0sz here, mask those bits when restoring */ - mrs x5, tcr_el1 - bfi x8, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH + mrs x7, tcr_el1 + bfi x8, x7, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH msr tcr_el1, x8 msr vbar_el1, x9 @@ -132,6 +133,7 @@ alternative_endif */ ubfx x11, x11, #1, #1 msr oslar_el1, x11 + msr osdlr_el1, x5 reset_pmuserenr_el0 x0 // Disable PMU access from EL0 alternative_if ARM64_HAS_RAS_EXTN -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] arm64: Save and restore OSDLR_EL1 2019-04-08 17:17 ` [PATCH 2/2] arm64: Save and restore OSDLR_EL1 Jean-Philippe Brucker @ 2019-04-09 10:37 ` Will Deacon 2019-04-09 11:29 ` Jean-Philippe Brucker 0 siblings, 1 reply; 5+ messages in thread From: Will Deacon @ 2019-04-09 10:37 UTC (permalink / raw) To: Jean-Philippe Brucker; +Cc: catalin.marinas, linux-arm-kernel Hi Jean-Philippe, On Mon, Apr 08, 2019 at 06:17:19PM +0100, Jean-Philippe Brucker wrote: > When the CPU comes out of suspend, the firmware may have modified the OS > Double Lock Register. Save it in an unused slot of cpu_suspend_ctx, and > restore it on resume. > > Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> > --- > arch/arm64/mm/proc.S | 34 ++++++++++++++++++---------------- > 1 file changed, 18 insertions(+), 16 deletions(-) [...] > @@ -105,8 +106,8 @@ ENTRY(cpu_do_resume) > msr cpacr_el1, x6 > > /* Don't change t0sz here, mask those bits when restoring */ > - mrs x5, tcr_el1 > - bfi x8, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH > + mrs x7, tcr_el1 > + bfi x8, x7, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH > > msr tcr_el1, x8 > msr vbar_el1, x9 > @@ -132,6 +133,7 @@ alternative_endif > */ > ubfx x11, x11, #1, #1 > msr oslar_el1, x11 > + msr osdlr_el1, x5 Just one oddity, but I notice you restore these in the opposite order from the order in which initialise them on the boot path. Is that ok? Also, did you test a suspend/resume cycle with this change? Cheers, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 2/2] arm64: Save and restore OSDLR_EL1 2019-04-09 10:37 ` Will Deacon @ 2019-04-09 11:29 ` Jean-Philippe Brucker 0 siblings, 0 replies; 5+ messages in thread From: Jean-Philippe Brucker @ 2019-04-09 11:29 UTC (permalink / raw) To: Will Deacon; +Cc: catalin.marinas, linux-arm-kernel On 09/04/2019 11:37, Will Deacon wrote: > Hi Jean-Philippe, > > On Mon, Apr 08, 2019 at 06:17:19PM +0100, Jean-Philippe Brucker wrote: >> When the CPU comes out of suspend, the firmware may have modified the OS >> Double Lock Register. Save it in an unused slot of cpu_suspend_ctx, and >> restore it on resume. >> >> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> >> --- >> arch/arm64/mm/proc.S | 34 ++++++++++++++++++---------------- >> 1 file changed, 18 insertions(+), 16 deletions(-) > > [...] > >> @@ -105,8 +106,8 @@ ENTRY(cpu_do_resume) >> msr cpacr_el1, x6 >> >> /* Don't change t0sz here, mask those bits when restoring */ >> - mrs x5, tcr_el1 >> - bfi x8, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH >> + mrs x7, tcr_el1 >> + bfi x8, x7, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH >> >> msr tcr_el1, x8 >> msr vbar_el1, x9 >> @@ -132,6 +133,7 @@ alternative_endif >> */ >> ubfx x11, x11, #1, #1 >> msr oslar_el1, x11 >> + msr osdlr_el1, x5 > > Just one oddity, but I notice you restore these in the opposite order from > the order in which initialise them on the boot path. Is that ok? I haven't found any documentation about the unlock order. Given that OS Lock is locked before OS Double Lock, I think restoring OSDLR before OSLAR makes more sense, so I can change the order in this patch for consistency. > Also, did you test a suspend/resume cycle with this change? Yes but only on Juno, because the suspend/resume code doesn't seem to be used on TX2 Thanks, Jean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-04-09 11:30 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-08 17:17 [PATCH 0/2] arm64: Clear OS Double Lock Register Jean-Philippe Brucker 2019-04-08 17:17 ` [PATCH 1/2] arm64: Clear OSDLR_EL1 on CPU boot Jean-Philippe Brucker 2019-04-08 17:17 ` [PATCH 2/2] arm64: Save and restore OSDLR_EL1 Jean-Philippe Brucker 2019-04-09 10:37 ` Will Deacon 2019-04-09 11:29 ` Jean-Philippe Brucker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).