[lkml]   [2018]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RT v2] arm64: fpsimd: use a local_lock() in addition to local_bh_disable()
On 24 July 2018 at 16:45, Dave Martin <> wrote:
> On Wed, Jul 18, 2018 at 11:24:48AM +0200, Sebastian Andrzej Siewior wrote:
>> On 2018-07-18 11:12:10 [+0200], To Dave Martin wrote:
>> > > > - if (may_use_simd()) {
>> > > > + if (!IS_ENABLED(CONFIG_PREEMPT_RT_BASE) && may_use_simd()) {
>> > >
>> > > I suspect this is wrong -- see comments on the commit message.
>> I'm sorry, I pressed send too early, I was aiming for the draft folder.
>> So yes, based on that EFI that might be interruptible, let me try to
>> look at the initial issue again and maybe I get another idea how to deal
>> with this.
>> One question: If EFI is interruptible that means, we call into EFI - how
>> do we get out? Does EFI enable interrupts and the kernel receives an
>> interrupt and treats this EFI call like a regular context switch?
> AFAIK the only safe way to get out permanently is for the call to
> return. Note, I've not gone through the spec in fine detail myself.
> The OS may handle interrupts occurring during the EFI call, but we
> still have to return to EFI afterwards to finish off the call. From
> the Linux perspective, I think this means that EFI calls are non-
> preemptible.
> Under RT, I'm pretty sure that we can't safely resume the interrupted
> EFI call on a different cpu from the one it was interrupted on. Even
> if it doesn't say this explicitly in the UEFI spec, I think it will be
> assumed in implementations.

This is a can of worms I would rather not open, although I don't think
the UEFI spec makes it explicit that you cannot migrate runtime
service calls while in progress.

Also, I don't think EFI calls are worth obsessing about, given that
they shouldn't be that common under normal operation. I know that RT
is not about the common case but about the worst case, though. What
problem is migrating a non-preemptible task intended to solve?

> Certain EFI calls are not long-running and may need to be called from
> interrupt context in Linux,

This suggests that the need to be called in interrupt context is a
property of the firmware implementation but it is not.

In the kernel, we have efi-pstore which may attempt to invoke runtime
services to record the kernel's dying gasp into a EFI variable. Other
than that, I don't think there are any reasons to call EFI services
from non-process context.

> which means that there may be live kernel-
> mode NEON state. This is why there are separate FPSIMD/SVE percpu stash
> buffers for EFI specifically.

So given the above, and the fact that you can panic() in an interrupt
handler, we needed those buffers, although I wonder if we'd ever reach
the point where we end up resuming execution of the code that uses the
restored contents of those buffers.

> Does this make sense? It's is probably not very clear, but I'm trying
> to hide the fact that I haven't looked at the UEFI spec for ages...
> Cheers
> ---Dave
> _______________________________________________
> linux-arm-kernel mailing list

 \ /
  Last update: 2018-07-24 17:15    [W:0.053 / U:5.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site