切换到安全世界后，OP-TEE的Linux调度程序如何工作

Question

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

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

这里tee_smc_call是asm函数发出SMC电话。如果定时器中断导致SW离开，我发现j将比1更大1 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 - 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. 该中断在正常世界中被服务。

我的推理链是这样的。

在安全OS的IRQ处理程序中没有读取中断应答寄存器。

- >中断状态仍然未决。 - > GIC将向CPU发出中断请求信号。