Wie funktioniert der Linux-Scheduler von OP-TEE nach dem Wechsel zu Secure World?

Question

Ich führe OP-TEE erfolgreich auf QEMU aus und möchte herausfinden, wie Scheduler funktioniert. Ich änderte den Quellcode, um die Variable Jiffies direkt vor dem Eintritt in Secure World und nach der Rückkehr in die normale Welt zu erhalten. Hier ist ein Stück Code.

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

Hier tee_smc_call ist die asm-Funktion Ausgabe SMC Anruf. Ich finde, j wird größer 1 als i, wenn Timer Interrupt Ergebnisse in SW verlassen. Ich denke, es bedeutet, dass der Timer-Interrupt irgendwo behandelt wird. Wenn mein Abzug nicht stimmt, korrigiere mich bitte.

Ich gehe auf den Link https://lists.linaro.org/pipermail/tee-dev/2015-August/000160.html und https://github.com/OP-TEE/optee_os/issues/332. Der OP-TEE-Entwickler sagt, dass der Timer-Interrupt von NW bedient wird, sobald er wieder in NW wechselt.
Ich habe den Quellcode des IRQ-Handlers von SW gelesen. Ich dachte, der SW-Handler würde den VBAR von NW finden und die Rückkehradresse zum NW-Handler ändern. Ich habe jedoch keinen solchen Code gefunden.
Ich habe einige Beiträge auf dieser Website TrustZone: Scheduling processes from the two worlds und ARM TrustZone - Behaviour of the scheduler in Secure and Non-Secure OS gelesen. Letzteres ist meinem ähnlich, aber die Antwort sagt nicht, was in der OP-TEE-Implementierung passiert.

Also frage ich mich, was ist die Magie, die den Timer-Interrupt wieder nach der Rückkehr nach NW behandelt werden, weil es Service einmal in SW gewesen ist.

Ich bin nicht vertraut mit OP-TEE. Und das ist meine erste Frage. Bitte vergib mir, wenn es nicht klar oder dumm ist. Vielen Dank.

Answer 1

Da niemand meine Frage für ein Jahr beantwortet, werde ich versuchen, meine eigene Erklärung zu geben.

HINWEIS, dass es nur mein eigenes Verständnis ist. Ich bin kein Experte für solche Dinge.

1. Der Timer-Interrupt wird generiert und GIC ändert den Status von inaktiv in ausstehend.
2. GIC leitet die Interrupt-Anforderung im sicheren Status an den Prozessor weiter. Dies ist ein Fremd-IRQ für SecureOS.
3. Der IRQ-Handler in SecureOS funktioniert wie Forward IRQ from secure world to normal world. Ich schaue in den Quellcode von thread_irq_handler und kann das Lesen für das Unterbrechungsbestätigungsregister nicht finden.
4. Der Prozessor kehrt zu Normal World zurück. Der Status des Timer-Interrupts ist nach Interrupt handling state machine in GIC architecture specification noch anstehend.
5. GIC wird die Interrupt-Anfrage zur richtigen Zeit an die CPU senden.
6. Der Interrupt wird in Normal World bedient.

Meine Argumentationskette ist so.

Interrupt-Bestätigungsregister wird im IRQ-Handler des sicheren Betriebssystems nicht gelesen.

-> Der Interrupt-Status steht noch aus.

-> GIC wird die Interrupt-Anfrage an die CPU signalisieren.