5

我在 QEMU 上成功运行了 OP-TEE，并想弄清楚调度程序是如何工作的。我修改了源代码以在进入 Secure World 之前和返回 Normal World 之后获取变量jiffies 。这是一段代码。

i=jiffies;
tee_smc_call(&param);
j=jiffies

这里tee_smc_call是发出SMC调用的 asm 函数。如果定时器中断导致离开 SW，我发现j将大于i 。我认为这意味着定时器中断在某处处理。如果我的推论不正确，请纠正我。

我转到链接https://lists.linaro.org/pipermail/tee-dev/2015-August/000160.html和https://github.com/OP-TEE/optee_os/issues/332。OP-TEE 开发人员表示，一旦切换回 NW，定时器中断将由 NW 提供服务。
我阅读了 SW 的 IRQ 处理程序的源代码。我以为 SW 处理程序会找到 NW 的 VBAR 并将返回地址更改为 NW 处理程序。但是我发现没有这样的代码。
我在这个站点上阅读了一些帖子 TrustZone: Scheduling processes from the two worlds和 ARM TrustZone - Behavior of the scheduler in Secure and Non-Secure OS。后者与我的相似，但答案并未说明 OP-TEE 实现中发生了什么。

所以我想知道在返回 NW 后再次处理定时器中断的魔力是什么，因为它已经在 SW 中服务过一次。

我不熟悉 OP-TEE。这是我的第一个问题。如果不清楚或愚蠢，请原谅我。谢谢。

4

1 回答 1

2

由于一年没有人回答我的问题，我将尝试给出自己的解释。

请注意，这只是我自己的理解。我不是这类事情的专家。

  1. 生成定时器中断，GIC 将状态从非活动更改为挂起。
  2. GIC 将中断请求转发给处于安全状态的处理器。这是 SecureOS 的外部 IRQ。
  3. SecureOS 中的 IRQ 处理程序用作从安全世界到正常世界的转发 IRQ。我查看了 thread_irq_handler 的源代码，找不到中断确认寄存器的读取。
  4. 处理器返回正常世界。根据GIC 架构规范中的中断处理状态机，定时器中断的状态仍处于未决状态。
  5. GIC 会在适当的时候向 CPU 发出中断请求。
  6. 中断在 Normal World 中得到服务。

我的推理链是这样的。

在 Secure OS 的 IRQ 处理程序中未读取中断确认寄存器。

--> 中断状态仍然是未决的。

--> GIC 将向 CPU 发出中断请求。

于 2017-08-02T08:05:16.353 回答