linux - 切换到Secure world后OP-TEE的Linux调度器如何工作

Question

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

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

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

我去链接 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 - Behaviour of the scheduler in Secure and Non-Secure OS .后者与我的类似，但答案并未说明 OP-TEE 实现中发生了什么。

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

我不熟悉 OP-TEE。这是我的第一个问题。说的不清楚或者笨的请见谅。谢谢。

Answer 1

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

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

1. 生成定时器中断，GIC 将状态从非事件更改为挂起。
2. GIC 将中断请求转发给处于安全状态的处理器。这是 SecureOS 的外部 IRQ。
3. SecureOS 中的 IRQ 处理程序作为 Forward IRQ from secure world to normal world 工作。 .我查看了 thread_irq_handler 的源代码，找不到中断确认寄存器的读取。
4. 处理器返回正常世界。根据 Interrupt handling state machine in GIC architecture specification，定时器中断的状态仍处于挂起状态.
5. GIC 会在适当的时候向 CPU 发出中断请求信号。
6. 中断在正常世界中得到服务。

我的推理链是这样的。

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

--> 中断状态还是pending。

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