[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000001d63fd1$23430d80$69c92880$@samsung.com>
Date: Thu, 11 Jun 2020 18:17:32 +0900
From: "???" <wooy88.kim@...sung.com>
To: "'Dave Martin'" <Dave.Martin@....com>,
"'Mark Rutland'" <mark.rutland@....com>
Cc: "'Catalin Marinas'" <catalin.marinas@....com>,
"'Bhupesh Sharma'" <bhsharma@...hat.com>,
"'Julien Grall'" <julien.grall@....com>,
"'Vincenzo Frascino'" <vincenzo.frascino@....com>,
"'Will Deacon'" <will@...nel.org>, <yhwan.joo@...sung.com>,
"'Anisse Astier'" <aastier@...ebox.fr>,
"'Marc Zyngier'" <maz@...nel.org>,
"'Allison Randal'" <allison@...utok.net>,
"'Sanghoon Lee'" <shoon114.lee@...sung.com>,
<jihun.kim@...sung.com>, "'Kees Cook'" <keescook@...omium.org>,
"'Suzuki K Poulose'" <suzuki.poulose@....com>,
"'Wooki Min'" <wooki.min@...sung.com>,
"'Kristina Martsenko'" <kristina.martsenko@....com>,
"'Jeongtae Park'" <jtp.park@...sung.com>,
"'Thomas Gleixner'" <tglx@...utronix.de>,
<linux-arm-kernel@...ts.infradead.org>,
"'Steve Capper'" <steve.capper@....com>,
"'Greg Kroah-Hartman'" <gregkh@...uxfoundation.org>,
<linux-kernel@...r.kernel.org>,
"'James Morse'" <james.morse@....com>,
"'Sudeep Holla'" <sudeep.holla@....com>, <dh.han@...sung.com>
Subject: RE: [PATCH] arm64: fpsimd: Added API to manage fpsimd state inside
kernel
Dear Dave Martin & Mark Rutland
Thank you for your kind answer.
> On Fri, Jun 05, 2020 at 11:37:05AM +0100, Mark Rutland wrote:
> > Hi Wooyeon,
> >
> > There are a *lot* of people Cc' here, many of whomo will find this
> > irrelevant. Please try to keep the Cc list constrained to a reasonable
> > number of interested parties.
I have adjusted the mailing list according to your opinion.
> > 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)
In the case of the kernel_neon_begin / kernel_neon_end that you mentioned,
there is a limitation that cannot be used in hardirq context.
Also, if another kernel task switching occurs while kernel API is being
used,
fpsimd register corruption may occur.
In addition to kernel_neon_* API,
It was necessary to add and utilize API considering kernel context.
It is for this reason that I have tried to utilize efi_fpsimd_begin/end.
Regards
Wooyeon Kim
Powered by blists - more mailing lists