Re: [PATCH] arm64: fpsimd: Added API to manage fpsimd state inside kernel

[Mark Rutland <mark.rutland@arm.com>]

On Thu, Jun 11, 2020 at 06:17:32PM +0900, ??? wrote:
> > On Fri, Jun 05, 2020 at 11:37:05AM +0100, Mark Rutland wrote:
> > > Please introduce the problem you are trying to solve in more detail.
> > > We already have kernel_neon_{begin,end}() for kernel-mode NEON; why is
> > > that not sufficient for your needs? Please answer this before
> > > considering other details.
> > >
> > > What do you want to use this for?
> 
> > Ack, this looks supicious.  Can you explain why your usecase _requires_
> > FPSIMD in hardirq context?
> > 
> > For now, these functions are strictly for EFI use only and should never be
> > used by modules.
> 
> I am in charge of camera driver development in Samsung S.LSI division.
> 
> In order to guarantee real time processing
> such as Camera 3A algorithm in current or ongoing projects,
> prebuilt binary is loaded and used in kernel space, rather than user space.
> Because the binary is built with other standard library which could use
> FPSIMD register,
> kernel API should keep the original FPSIMD state for other user tasks.
> It is mostly used for internal kernel operation including hardirq context.
> (ex> hardIRQ context, kernel API called by user, kernel task)

That sounds incredibly dodgy to me, both from a correctness perspective
and a licensing perspective. Upstream doesn't support out-of-tree
modules, nor does upstream support binary blobs within the kernel, so
the above cannot justify this change to the kernel.

If you wish to do such processing within the kernel, I think you'll need
to post a more complete in-tree solution for inclusion in mainline.
However, I suspect that it will be difficult to justify NEON in hardirq
context given preempt rt and friends.

Thanks,
Mark.