On Wed, Apr 20, 2011 at 2:48 PM, Arnd Bergmann arnd@arndb.de wrote:
Hi Tixy,
In general, you cannot use any FP code in the kernel, and there are few exceptions to that. I'm not sure about Neon here, but in general, you have to save the FP registers of the user process and enable the FPU using kernel_fpu_begin() or enable_kernel_fp() and release the FPU context using kernel_fpu_end() or disable_kernel_fp() depending on the architecture, before returning to user space.
NEON shares the register set used by VFP, so yes -- the same arguments apply.
I could not find these functions for ARM, maybe they have yet another name. If they don't exist, you might have to add them. In either way, saving the FPU state is generally expensive, so it's worth it only if we use many FP operations at once.
You're right; ARM doesn't currently have these so far as I can tell -- this is a possible area of investigation for linaro. Although we don't want to see sporadic FP operations dotted around the kernel, it may be worth saving/restoring the registers for specific bulk integer processing operations which we could using NEON, such as packet checksums, CRCs and crypto operations for example. It's hard to quantify the advantages (if any) without doing some investigation and benchmarking, though.
However, the benefit of allowing kprobes to be set in such code may still not merit the effort. We can revisit it later if it looks important.
Cheers ---Dave