Re: [PATCH v1] ARM: A9: Add ARM ERRATA 764319 workaround

[Robin Murphy]

On 2022-05-10 08:19, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 9:29 PM <nick.hawkins@xxxxxxx> wrote:
> > From: Nick Hawkins <nick.hawkins@xxxxxxx>
> >
> > Enable the workaround for the 764319 Cortex A-9 erratum.
> > CP14 read accesses to the DBGPRSR and DBGOSLSR registers generate an
> > unexpected Undefined Instruction exception when the DBGSWENABLE external
> > pin is set to 0, even when the CP14 accesses are performed from a
> > privileged mode. The work around catches the exception in a way
> > the kernel does not stop execution with the use of undef_hook. This
> > has been found to effect the HPE GXP SoC.
> >
> > Signed-off-by: Nick Hawkins <nick.hawkins@xxxxxxx>
> > ---
> >   arch/arm/Kconfig                | 11 +++++++++++
> >   arch/arm/kernel/hw_breakpoint.c | 26 ++++++++++++++++++++++++++
> >   2 files changed, 37 insertions(+)
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 13f77eec7c40..6944adfb0fae 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -974,6 +974,17 @@ config ARM_ERRATA_764369
> >            relevant cache maintenance functions and sets a specific bit
> >            in the diagnostic control register of the SCU.
> >
> > +config ARM_ERRATA_764319
> > +       bool "ARM errata: Read to DBGPRSR and DBGOSLSR may generate Undefined instruction"
> > +       depends on CPU_V7
> > +       help
> > +         This option enables the workaround for the 764319 Cortex A-9 erratum.
> > +         CP14 read accesses to the DBGPRSR and DBGOSLSR registers generate an
> > +         unexpected Undefined Instruction exception when the DBGSWENABLE
> > +         external pin is set to 0, even when the CP14 accesses are performed
> > +         from a privileged mode. This work around catches the exception in a
> > +         way the kernel does not stop execution.
> > +
> >   config ARM_ERRATA_775420
> >          bool "ARM errata: A data cache maintenance operation which aborts, might lead to deadlock"
> >          depends on CPU_V7
> > diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
> > index b1423fb130ea..c41a8436a796 100644
> > --- a/arch/arm/kernel/hw_breakpoint.c
> > +++ b/arch/arm/kernel/hw_breakpoint.c
> > @@ -941,6 +941,23 @@ static int hw_breakpoint_pending(unsigned long addr, unsigned int fsr,
> >          return ret;
> >   }
> >
> > +#ifdef CONFIG_ARM_ERRATA_764319
> > +int oslsr_fault;
> > +
> > +static int debug_oslsr_trap(struct pt_regs *regs, unsigned int instr)
> > +{
> > +       oslsr_fault = 1;
> > +       instruction_pointer(regs) += 4;
> > +       return 0;
> > +}
> > +
> > +static struct undef_hook debug_oslsr_hook = {
> > +       .instr_mask  = 0xffffffff,
> > +       .instr_val = 0xee115e91,
> > +       .fn = debug_oslsr_trap,
> > +};
> > +#endif
> > +
>
> Hi Nick,
>
> This seems a bit more complex than necessary. Can't you just use a custom
> inline asm with an ex_table entry to catch the fault? Have a look at
> __get_user_asm() for an example.

Indeed, according to the Cortex-A9 documentation the register should 
always read as zero anyway, so all we should need to do is initialise 
the local oslsr variable to 0 and have the fault handler just return to 
the next instruction.

Robin.