Lines Matching refs:secure

63    ELs. In this scheme, the handling spans various secure ELs.
66    processing of the error to dedicated software stack running at lower secure
147 -  On GICv3 systems, when executing in S-EL1, pending Non-secure interrupts of
149    EL3. As a result, S-EL1 software cannot expect to handle Non-secure
153    In order for S-EL1 software to handle Non-secure interrupts while having
154    |EHF| enabled, the dispatcher must adopt a model where Non-secure interrupts
162    lowest Secure priority. This means that no Non-secure interrupts can preempt
184    (secure space).
190    6 and 5), the platform can partition into 4 secure priority ranges: ``0x0``,
236 The :ref:`Firmware Design guide<configuring-secure-interrupts>` explains methods
237 for configuring secure interrupts. |EHF| requires the platform to enumerate
239 priority of secure interrupts must match that as determined in the
454 In general, Secure execution is regarded as more important than Non-secure
458 call ``ehf_activate_priority()``. As a result, Non-secure interrupts cannot
461 SMCs from Non-secure world are synchronous exceptions, and are mechanisms for
462 Non-secure world to request Secure services. They're broadly classified as
469    Any Non-secure interrupts that become pending meanwhile cannot preempt Secure
473    A pending Non-secure interrupt can preempt Secure execution handling a
480    #. A Non-secure interrupt preempts Secure execution. Non-secure interrupt is
481       handled, and Non-secure execution resumes after ``SMC`` instruction.
484    to the Non-secure caller to distinguish the latter case. This return code,
488 For the latter case above, dispatchers before |EHF| expect Non-secure interrupts
490 preempted error code before yielding to Non-secure world.
495 When |EHF| is enabled, in order to allow Non-secure interrupts to preempt
497 API. The API takes one argument, the error code to be returned to the Non-secure
500 .. [#irq] In case of GICv2, Non-secure interrupts while in S-EL1 were signalled