[RFC v2 PATCH 1/1] ARM64: KGDB: Add FP/SIMD debug support

[will.deacon@arm.com (Will Deacon)]

On Sun, Mar 02, 2014 at 01:08:56PM +0000, Ard Biesheuvel wrote:
> On 28 February 2014 18:36, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Feb 28, 2014 at 11:08:58AM +0000, Vijay Kilari wrote:
> >> On Fri, Nov 29, 2013 at 3:27 PM, Vijay Kilari <vijay.kilari@gmail.com> wrote:
> >> >>> KGDB, being kernel debugger it was thought that allow
> >> >>> debugging only if kernel mode is supported.
> >> >>> In fact, I proposed (previous email)  to remove this condition and
> >> >>> allow to reading neon
> >> >>> registers always and allow write only if neon is in kernel mode.
> >> >>>
> >> >>
> >> >> I think KGDB is a special case here and should not considered as a
> >> >> user of kernel mode NEON. So even writing the registers should
> >> >> allowable regardless of this setting imo.
> >> >>
> >>
> >>  Can we avoid checking on NEON state and allow debugger to
> >> access NEON registers irrespective of state to keep it simple?
> >> and just compile config is enough?
> >
> > I'm afraid I don't follow... I think we *do* need to do the relevant
> > flush/sync operations, I just don't think it should be predicated on
> > KERNEL_MODE_NEON.
> 
> Could you elaborate a bit on what you consider flush/sync operations?
> 
> The point I was making is that, from kgdb's point of view, it is
> irrelevant whether the FPSIMD registers contain current's userland
> FPSIMD state or something else. kgdb should return and/or manipulate
> what the kernel itself sees when it accesses the FPSIMD registers
> directly, regardless of whether those contents belong to current's
> userland or not. (please refer to my pending series on kernel mode
> NEON optimizations)

Ok, point taken. So we just allow KGDB to access the hardware directly,
without any saving/restoring of state.

Will