Messages in this thread | | | Date | Fri, 12 Feb 2021 13:19:44 +0000 | From | Catalin Marinas <> | Subject | Re: [PATCH v13 6/7] arm64: mte: Report async tag faults before suspend |
| |
On Fri, Feb 12, 2021 at 12:00:15PM +0000, Lorenzo Pieralisi wrote: > On Thu, Feb 11, 2021 at 03:33:52PM +0000, Vincenzo Frascino wrote: > > +void mte_suspend_enter(void) > > +{ > > + if (!system_supports_mte()) > > + return; > > + > > + /* > > + * The barriers are required to guarantee that the indirect writes > > + * to TFSR_EL1 are synchronized before we report the state. > > + */ > > + dsb(nsh); > > + isb(); > > + > > + /* Report SYS_TFSR_EL1 before suspend entry */ > > + mte_check_tfsr_el1(); > > +} > > + > > void mte_suspend_exit(void) > > { > > if (!system_supports_mte()) > > return; > > > > update_gcr_el1_excl(gcr_kernel_excl); > > + > > + /* Clear SYS_TFSR_EL1 after suspend exit */ > > + write_sysreg_s(0, SYS_TFSR_EL1); > > AFAICS it is not needed, it is done already in __cpu_setup() (that is > called by cpu_resume on return from cpu_suspend() from firmware). > > However, I have a question. We are relying on context switch to set > sctlr_el1_tfc0 right ? If that's the case, till the thread resuming from > low power switches context we are running with SCTLR_EL1_TCF0 not > reflecting the actual value.
I think you have a point here, though not for SCTLR_EL1 as it is already restored. GCR_EL1 is only updated after some C code has run and may mess up stack tagging when/if we ever support it. Anyway, something to worry about later, I think even the boot path gets this wrong.
-- Catalin
| |