---------- Forwarded message ---------- From: Dave Martin dave.martin@linaro.org Date: Thu, Apr 14, 2011 at 5:01 PM Subject: Re: Is VFP or Neon supported in kernel-side code? <EOM> To: Tixy tixy@yxit.co.uk
Is VFP or Neon supported in kernel-side code?
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.
Cheers ---Dave
On Thu, Apr 14, 2011 at 2:21 PM, Tixy tixy@yxit.co.uk wrote:
linaro-kernel mailing list linaro-kernel@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel
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.
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.
Nicolas
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 :-)
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
On Thu, Apr 14, 2011 at 6:49 PM, Nicolas Pitre nicolas.pitre@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
linaro-kernel@lists.linaro.org
-
Dave Martin -
Nicolas Pitre -
Tixy