ARM SDEI事件处理机制详解与状态机分析

1. ARM SDEI事件处理机制概述

在ARM架构的嵌入式系统中，软件委托异常接口（Software Delegated Exception Interface，简称SDEI）提供了一种高效的事件处理机制。这种机制允许将特定事件（如硬件错误、看门狗定时器触发等）从固件层委托给操作系统或应用程序处理，实现了异常处理的灵活分层。

SDEI的核心设计理念是通过状态机来精确管理事件处理流程。这种状态机模型定义了三种基础状态和若干衍生状态，配合handler-running属性，构成了完整的事件生命周期管理体系。与传统的硬件中断处理相比，SDEI具有以下显著优势：

• 异步事件处理：允许在非中断上下文中处理事件，减少关键路径上的延迟
• 优先级管理：支持普通和关键两种优先级类别，确保重要事件优先处理
• 电源管理集成：与PSCI（Power State Coordination Interface）深度整合，保证低功耗状态下的事件处理可靠性
• 虚拟化支持：可在虚拟化环境中将物理事件转换为虚拟事件，供客户操作系统使用

提示：SDEI事件处理通常运行在EL1或EL2异常级别，具体取决于系统配置和虚拟化需求。在设计事件处理程序时，需要特别注意异常级别的上下文切换开销。

2. SDEI状态机详解

2.1 基础状态定义

SDEI状态机定义了三种基础状态，每种状态都有明确的语义和转换规则：

1. 未注册状态（handler-unregistered）

   • 初始状态，表示事件尚未被任何处理程序注册
   • 在此状态下，事件无法被触发或处理
   • 状态位向量表示为(0,0,0)
   • 可用接口调用：SDEI_EVENT_REGISTER、SDEI_EVENT_STATUS、SDEI_INTERRUPT_RELEASE

2. 已注册状态（handler-registered）

   • 表示事件已注册处理程序但尚未启用
   • 事件触发后会保持pending状态，直到被启用
   • 状态位向量表示为(1,0,0)
   • 可用接口调用：SDEI_EVENT_STATUS、SDEI_EVENT_ENABLE、SDEI_EVENT_DISABLE、SDEI_EVENT_GET_INFO、SDEI_EVENT_ROUTING_SET

3. 已启用状态（handler-enabled）

   • 表示事件已注册且启用，可以正常触发和处理
   • 状态位向量表示为(1,1,0)
   • 可用接口调用：SDEI_EVENT_STATUS、SDEI_EVENT_ENABLE、SDEI_EVENT_DISABLE、SDEI_EVENT_GET_INFO、SDEI_EVENT_UNREGISTER

2.2 状态转换规则

状态转换通过特定的接口调用触发，以下是主要的状态转换路径：

1. 注册转换：

   code复制handler-unregistered → SDEI_EVENT_REGISTER → handler-registered
   

2. 启用转换：

   code复制handler-registered → SDEI_EVENT_ENABLE → handler-enabled
   

3. 禁用转换：

   code复制handler-enabled → SDEI_EVENT_DISABLE → handler-registered
   

4. 注销转换：

   code复制handler-registered → SDEI_EVENT_UNREGISTER → handler-unregistered
   handler-enabled → SDEI_EVENT_UNREGISTER → handler-unregistered
   

下表总结了主要状态转换关系：

2.3 handler-running属性及其衍生状态

handler-running是SDEI状态机的一个重要属性，表示事件处理程序正在某个处理单元（PE）上执行。当handler-running为TRUE时，会衍生出三种特殊状态：

1. 未注册待处理状态（handler-unregister-pending）

   • 状态位向量：(0,0,1)
   • 发生在处理程序执行期间收到注销请求时
   • 处理程序完成执行后会自动转换到handler-unregistered状态

2. 已注册且运行状态（handler-registered and handler-running）

   • 状态位向量：(1,0,1)
   • 发生在已注册但未启用的事件处理程序执行期间

3. 已启用且运行状态（handler-enabled and handler-running）

   • 状态位向量：(1,1,1)
   • 发生在已启用事件处理程序执行期间

handler-running属性会在以下情况下发生变化：

• 设置为TRUE：当事件处理程序开始在某PE上执行时
• 设置为FALSE：当处理程序调用SDEI_EVENT_COMPLETE或SDEI_EVENT_COMPLETE_AND_RESUME时

3. SDEI接口调用与状态约束

3.1 状态相关的接口调用

不同状态下可用的接口调用存在严格限制，这是SDEI设计的重要约束条件。以下是各状态下可用的主要接口调用：

3.2 状态无关的接口调用

部分接口调用不受状态限制，可在任何状态下使用：

• SDEI_VERSION
• SDEI_EVENT_STATUS
• SDEI_PE_MASK
• SDEI_PE_UNMASK
• SDEI_INTERRUPT_BIND
• SDEI_EVENT_SIGNAL
• SDEI_FEATURES
• SDEI_PRIVATE_RESET
• SDEI_SHARED_RESET

注意：SDEI_EVENT_GET_INFO的可用性取决于参数设置，在某些参数组合下可能不可用。

4. SDEI事件分发机制

4.1 事件分发条件

SDEI事件分发器仅在满足以下所有条件时才会分发事件：

1. 事件已启用（对于私有事件，需要在目标PE上启用；对于共享事件，只需全局启用）
2. 目标PE已解除屏蔽（通过SDEI_PE_UNMASK）
3. 目标PE当前没有处理相同或更高优先级的事件

如果上述任一条件不满足，事件将保持pending状态，直到所有条件满足为止。对于同一优先级类别的多个pending事件，分发顺序由具体实现定义。

4.2 私有事件与共享事件分发

SDEI事件分为私有事件和共享事件，两者的分发逻辑有所不同：

1. 私有事件分发伪代码：

c复制Dispatcher(Client C) {
    For each P in PE {
        For each E in PrivateEvents {
            if (IsSignaled(E, P) && 
                IsEnabled(E, P) && 
                IsUnmasked(P) &&
                ((IsCriticalEvent(E) && !CriticalEventRunning(P, C)) ||
                (!IsCriticalEvent(E) && !EventRunning(P, C)))) {
                // 分发事件到处理程序
            }
        }
    }
}

2. 共享事件分发伪代码：

c复制Dispatcher(Client C) {
    For each P in PE {
        For each E in SharedEvents {
            if (IsSignaled(E) && 
                IsEnabled(E) && 
                IsEventTarget(E, P) &&
                IsUnmasked(P) &&
                ((IsCriticalEvent(E) && !CriticalEventRunning(P, C)) ||
                (!IsCriticalEvent(E) && !EventRunning(P, C)))) {
                // 分发事件到处理程序
            }
        }
    }
}

4.3 重复事件处理

对于重复触发的事件，SDEI有以下处理规则：

• 如果事件在处理程序完成执行后再次触发，处理程序将再次执行
• 如果事件在处理程序执行期间再次触发，处理程序可能在完成后再次执行（取决于事件源和系统交互方式）
• 共享事件在任何时候只能有一个实例在系统中被处理，并发处理不被允许

5. SDEI与电源管理（PSCI）的协同

5.1 电源管理场景下的SDEI行为

SDEI与PSCI的协同工作确保了在各种电源状态下事件处理的可靠性：

1. 上电序列（Power-on）：

   • 每次PE复位后，分发器必须确保SDEI事件对该客户端处于屏蔽状态
   • 客户端完成初始化后，应调用SDEI_PE_UNMASK解除屏蔽

2. 关机序列（CPU_OFF）：

   • 客户端在调用CPU_OFF前必须：
     • 注销或禁用所有私有事件
     • 将目标为此PE的共享事件路由到其他PE
     • 屏蔽此PE的SDEI事件
   • 分发器必须确保没有SDEI事件能重新唤醒已关机的核心

3. 挂起到内存（CPU_SUSPEND with powerdown）：

   • 可能被事件唤醒的PE需要特殊处理
   • 客户端在挂起前应：
     • 禁用不作为唤醒源的私有/共享事件
     • 重新路由不作为唤醒源的共享事件
     • 屏蔽SDEI事件
   • 唤醒后，事件保持pending直到客户端调用SDEI_PE_UNMASK

4. 挂起到待机（CPU_SUSPEND with standby）：

   • 所有事件状态和屏蔽状态被保留
   • 唤醒后，若PE之前未屏蔽，可立即接收事件

5.2 SDEI处理程序中的PSCI调用

SDEI处理程序中允许调用部分PSCI功能，最小支持集合包括：

• PSCI_VERSION
• AFFINITIY_INFO
• PSCI_FEATURES
• SYSTEM_RESET
• SYSTEM_OFF
• CPU_OFF
• CPU_FREEZE
• CPU_ON

在SDEI处理程序中调用SYSTEM_RESET、SYSTEM_OFF、CPU_OFF和CPU_FREEZE会隐式完成所有SDEI处理程序，然后执行电源操作。

6. SDEI典型应用场景

6.1 物理中断作为SDEI事件

这种模式适用于看门狗定时器、性能分析器等场景，典型流程如下：

1. 平台定义中断的事件号，或客户端通过SDEI_INTERRUPT_BIND创建绑定事件
2. 客户端软件注册并启用事件
3. 事件触发时，分发器通过注册的入口点将事件传递给客户端
4. 处理程序（类似中断处理程序）处理事件，清除设备中断，完成事件

这种模式下，事件的启用/禁用操作会直接启用/禁用物理中断，适合分发器提供服务的情况。

6.2 隔离的物理中断作为SDEI事件

这种模式适用于错误处理等复杂场景，典型流程如下：

1. 客户端从分发器获取事件号或创建绑定事件
2. 操作系统注册并启用事件
3. 硬件事件触发时，分发器异常级别的软件进行第一级处理
4. 分发器触发SDEI事件并传递给操作系统处理程序
5. 操作系统处理并完成事件

在这种模式下，事件的启用/禁用操作仅影响对客户端的事件生成，即使客户端禁用事件，分发器仍可处理事件。

6.3 虚拟SDEI事件

在虚拟化环境中，运行在hypervisor下的客户OS可以注册虚拟SDEI事件。存在两级委托：

1. 固件到hypervisor
2. hypervisor到客户OS

hypervisor处理物理事件时有三种选择：

1. 在hypervisor内部处理事件
2. 将虚拟事件委托给当前执行的客户OS
3. 将虚拟事件委托给所有已注册的客户OS

虚拟事件的共享行为由具体hypervisor实现决定，某些实现可能允许共享物理事件分发给多个客户OS。

7. 实现注意事项

7.1 GICv2架构下的实现

在GICv2系统中实现SDEI需要考虑以下要点：

• Group 0中断（安全）需要在EL3和Secure EL1之间共享
• 一种实现方式是将安全Group 0中断陷入EL3，由EL3分发器代理给非安全客户端
• 另一种方式是安全中断陷入Secure EL1，未知中断（如SDEI）传递给EL3处理

7.2 GICv3架构下的实现

GICv3提供了更灵活的中断分组机制：

• Group 0：安全中断
• Secure Group 1：安全中断
• Non-secure Group 1：非安全中断

在Secure EL1处理Secure Group 1中断时，可以通过以下方式确保SDEI事件处理：

1. Secure EL1软件禁用Non-secure Group 1中断组
2. 通过中断优先级分配确保：
   • Group 0中断优先于Secure Group1中断
   • Secure Group 1中断优先于Non Secure Group 1中断

7.3 ACPI表定义

SDEI ACPI表（表签名'SDEI'）通告平台固件或hypervisor实现的SDEI接口存在，主要字段包括：

• 签名（'SDEI'）
• 长度
• 修订版（本文档描述修订版1）
• 校验和（整个表必须校验和为0）
• OEM信息
• 创建者信息

在解析APEI HEST表的GHES条目时，操作系统应使用SDEI调用注册使用SDEI作为通知方法的事件（通知类型11）。事件号存储在vector字段中。

8. 开发实践与经验分享

在实际开发中，使用SDEI时需要注意以下关键点：

1. 事件处理程序设计：

   • 保持处理程序简洁高效，避免长时间运行
   • 注意处理程序中的内存访问权限，确保相关内存区域可访问
   • 考虑嵌套事件处理的可能性，合理设计优先级

2. 状态管理最佳实践：

   • 在注册事件前，确保处理程序地址有效且可访问
   • 启用事件前，完成所有必要的配置（如路由设置）
   • 注销事件前，确保处理程序不在运行状态

3. 电源管理集成：

   • 在CPU_OFF或CPU_SUSPEND前，严格遵循状态转换规则
   • 特别注意共享事件在电源状态转换时的路由管理
   • 合理处理唤醒事件与普通事件的关系

4. 错误处理：

   • 为关键事件设计备用处理路径
   • 监控事件pending状态，防止事件堆积
   • 实现适当的超时机制，防止事件处理卡死

5. 性能考量：

   • 评估事件处理延迟对系统性能的影响
   • 对于高频事件，考虑批处理或延迟处理策略
   • 监控事件分发器的负载情况

在调试SDEI相关问题时，可以重点关注以下方面：

• 使用SDEI_EVENT_STATUS检查事件状态
• 验证处理程序注册地址的正确性
• 检查PE的屏蔽状态
• 确认电源状态转换时的事件行为是否符合预期
• 对于虚拟化环境，检查物理事件到虚拟事件的映射关系