Fwd: Is VFP or Neon supported in kernel-side code? <EOM>

[Nicolas Pitre]

On Thu, 14 Apr 2011, Tixy wrote:

> On Thu, 2011-04-14 at 13:33 -0400, Nicolas Pitre wrote:
> > On Thu, 14 Apr 2011, Tixy wrote:
> > 
> > > On Thu, 2011-04-14 at 17:02 +0100, Dave Martin wrote:
> > > > Currently, no.
> > > > 
> > > > There is some possible future work to see if we can enable this, to
> > > > allow acceleration of some number-crunching algorithms in the kernel,
> > > > but it's not implemented yet.
> > > > 
> > > > For now, I think it's reasonable simply to reject attempts to insert
> > > > kprobes on VFP/NEON instructions (as we must for cp15).  I think that
> > > > these instructions are never used at the entry/exit points of
> > > > compiler-generated functions -- in any case, we build the kernel with
> > > > -msoft-float, so actually the compiler should never implicitly
> > > > generate these instructions at all.
> > > 
> > > That'll save some tricky test code writing for now. I've tidied up and
> > > fixed the coprocessor instruction decoding for kprobes, but it sounds
> > > like there isn't much use for this and it could just be deleted.
> > > 
> > > Nicolas might have an opinion.
> > 
> > Yes, keeping things simple for now is certainly best.  Just save away 
> > your work in case it may become useful eventually.
> > 
> 
> There's about 100 lines of existing (and buggy) code to support
> coprocessor instructions, so is it OK to delete that and just return
> INSN_REJECTED? (In the commit notes I mention what the bugs are, so if
> someone gets tempted to resurrect the code they at least know what the
> problems are :-)

Well, certainly.


Nicolas