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

Dave Martin dave.martin at linaro.org
Fri Apr 15 11:25:37 UTC 2011


On Thu, Apr 14, 2011 at 6:49 PM, Nicolas Pitre <nicolas.pitre at linaro.org> wrote:
> 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.
>

Yes, I think that coprocessor instructions are

  a) rare
  b) scary
  c) impossible to emulate, or
  d) all of the above

... and I think if kprobes rejects all these it's unlikely to
inconvenience people in practice.

It can be addressed later if necessary.

Less code = fewer bugs :)

Cheers
---Dave



More information about the linaro-kernel mailing list