3. 上下文切换优化：减少进出TEE的切换次数

做TEE开发的朋友应该都有体会——进出TEE的开销，比你想象中大得多。我最早做第一个TEE项目时，天真地以为每次调用也就多花几微秒。结果一上性能测试，吞吐量直接腰斩。嗯，那时候我才真正意识到：上下文切换，是TEE性能的第一号杀手。

说白了，每次从REE（普通世界）切到TEE（安全世界），CPU都要保存现场、刷新缓存、切换页表、通知安全监控器。这一套下来，几十微秒就没了。你想想看，如果你的业务逻辑需要频繁进出TEE，那性能能好才怪。

3.1 上下文切换的成本到底有多高？

先看一组我在实际项目中测出来的数据。测试环境是ARM Cortex-A72，主频2.0GHz，TEE为OPTEE 3.12：

操作类型	平均耗时	说明
空调用（无数据传递）	8-12 µs	仅切换上下文，不做任何业务
单次小数据传递（64字节）	15-20 µs	含数据拷贝和共享内存映射
单次大数据传递（4KB）	40-60 µs	主要耗时在内存拷贝和TLB刷新
批量处理（10次合并）	25-35 µs	均摊后每次仅2.5-3.5 µs

看到没？批量处理后，单次开销下降了近80%。这就是优化的空间所在。

3.2 批处理（Batching）模式

批处理的核心思想很简单：把多次小切换合并成一次大切换。就像你去银行办事，与其跑三趟分别办三件事，不如攒到一起一次办完。

3.2.1 命令队列模式

这是最常用的批处理方式。REE侧先把多个操作请求打包成一个命令队列，一次性提交给TEE。TEE侧逐个处理，最后统一返回结果。

// REE侧：命令队列打包
struct tee_cmd_batch {
    uint32_t cmd_count;
    struct tee_cmd cmds[MAX_BATCH_SIZE];
    uint8_t *data_buffers[MAX_BATCH_SIZE];
    uint32_t data_sizes[MAX_BATCH_SIZE];
};

// 批量提交接口
int tee_invoke_batch(struct tee_cmd_batch *batch) {
    // 一次切换，处理多个命令
    return tee_invoke(TEE_CMD_BATCH_PROCESS, 
                      batch, 
                      sizeof(struct tee_cmd_batch));
}

// TEE侧：批量处理
TEE_Result handle_batch(struct tee_cmd_batch *batch) {
    for (int i = 0; i < batch->cmd_count; i++) {
        // 逐个处理命令
        process_single_cmd(&batch->cmds[i],
                          batch->data_buffers[i],
                          batch->data_sizes[i]);
    }
    return TEE_SUCCESS;
}

3.2.2 数据聚合策略

除了命令聚合，数据也要聚合。我习惯的做法是：

• 小数据合并：多个小数据包拼成一个大数据包，减少共享内存映射次数
• 增量更新：只传递变化的部分，而不是每次都全量同步
• 预分配缓冲区：在TEE侧预分配好内存池，避免每次切换都重新分配

3.3 异步调用（Async Call）模式

批处理解决的是「多次切换」的问题，但有时候业务逻辑要求必须实时响应。这时候就需要异步调用了。

异步调用的本质是：不让REE侧干等TEE处理完。REE发起调用后立刻返回，TEE处理完通过回调或轮询通知结果。

3.3.1 基于共享内存的异步模型

// 异步调用接口
struct async_request {
    uint32_t req_id;
    uint32_t cmd_type;
    void *input_data;
    size_t input_size;
    void *output_data;  // 预分配的输出缓冲区
    size_t output_size;
    volatile uint32_t *done_flag;  // 完成标志，放在共享内存中
};

// REE侧发起异步调用
int tee_async_invoke(struct async_request *req) {
    *req->done_flag = 0;
    
    int ret = tee_invoke(TEE_CMD_ASYNC_PROCESS, req, sizeof(*req));
    if (ret != 0) return ret;
    
    // 不等待，立即返回
    return 0;
}

// REE侧轮询结果
int tee_async_poll(struct async_request *req, int timeout_ms) {
    uint64_t start = get_current_ms();
    while (*req->done_flag == 0) {
        if (timeout_ms > 0 && (get_current_ms() - start) > timeout_ms) {
            return -ETIMEDOUT;
        }
        // 轻量级轮询，不切换上下文
        __asm__ volatile("yield");
    }
    return 0;
}

3.3.2 中断驱动的异步通知

比轮询更好的方式是用中断。TEE处理完任务后，通过安全中断通知REE。这样REE侧可以安心做其他事，不用一直盯着。

通知方式	延迟	CPU占用	适用场景
轮询（Polling）	低（微秒级）	高	高频小任务，延迟敏感
中断（Interrupt）	中（几十微秒）	极低	低频大任务，CPU资源紧张
混合模式	可配置	中等	大多数场景，推荐使用

3.4 实战：批处理+异步的混合架构

在实际项目中，我通常把批处理和异步调用结合起来用。下面是我在一个金融支付项目中用过的架构：

这个架构的核心思路：

1. 业务线程只管提交，不关心TEE什么时候处理完
2. 命令队列做缓冲，攒够一批才切一次
3. TEE侧并行处理，充分利用安全世界的多核能力
4. 结果异步返回，REE侧通过中断或轻量轮询获取结果

3.5 优化决策树

最后，我总结了一个决策树，帮你快速判断该用哪种优化策略：

场景特征	推荐策略	预期收益
高频小任务（每秒>1000次）	批处理+命令队列	切换次数降低90%+
低频大任务（每秒<100次）	异步调用+中断通知	CPU占用降低80%+
混合负载	批处理+异步混合架构	综合收益最佳
延迟极度敏感（<10µs）	保留单次调用，优化数据传递	保证最低延迟