lkml.org 
[lkml]   [2020]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectQueries on ARM SDEI Linux kernel code
Date
Hi James,

Have few queries on ARM SDEI Linux code. Queries are listed below; can
you please help provide your insights on these?

1. Looks like interrupt bind interface (SDEI_1_0_FN_SDEI_INTERRUPT_BIND)
is not available for clients to use; can you please share information on
why it is not provided?

While trying to dig information on this, I saw that [1] says:
Now the hotplug callbacks save nothing, and restore the OS-view of
registered/enabled. This makes bound-interrupts harder to work with.

Based on this comment, the changes from v4 [2], which I could understand
is, cpu down path does not save the current event enable status, and we
rely on the enable status `event->reenable', which is set, when
register/unregister, enable/disable calls are made; this enable status
is used during cpu up path, to decide whether to reenable the interrupt.

Does this make, bound-interrupts harder to work with? how? Can you
please explain? Or above save/restore is not the reason and you meant
something else?

Also, does shared bound interrupts also have the same problem, as
save/restore behavior was only for private events?

2. SDEI_EVENT_SIGNAL api is not provided? What is the reason for it? Its
handling has the same problems, which are there for bound interrupts?

Also, if it is provided, clients need to register event 0 ? Vendor
events or other event nums are not supported, as per spec.

3. Can kernel panic() be triggered from sdei event handler? Is it a safe
operation? The spec says, synchronous exceptions should not be
triggered; I think panic won't do it; but anything which triggers a WARN
or other sync exception in that path can cause undefined behavior. Can
you share your thoughts on this?

"The handler code should not enable asynchronous exceptions by clearing
any of the PSTATE.DAIF bits, and should not cause synchronous exceptions
to the client Exception level."


[1] https://lwn.net/Articles/740817/
[2] https://www.spinics.net/lists/kvm-arm/msg27784.html

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation

\
 
 \ /
  Last update: 2020-10-15 08:08    [W:0.063 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site