I successfully run OP-TEE on QEMU and want to figure out how scheduler works.
I modified the source code to get the variable jiffies right before entering Secure World and after returning to Normal World. Here is a piece of code.
i=jiffies;
tee_smc_call(¶m);
j=jiffies
Here tee_smc_call is the asm function issuing SMC call. I find j will be greater 1 than i if timer interrupt results in leaving SW. I think it means the timer interrupt is handled somewhere. If my deduction is not right please correct me.
I go to the link https://lists.linaro.org/pipermail/tee-dev/2015-August/000160.html and https://github.com/OP-TEE/optee_os/issues/332. The OP-TEE developer says timer interrupt will be serviced by NW as soon as switching back to NW.
I read the source code of IRQ handler of SW. I thought the SW handler would find the VBAR of NW and change the return address to the NW handler. However I found no such code.
I have read some posts on this site
TrustZone: Scheduling processes from the two worlds and
ARM TrustZone - Behaviour of the scheduler in Secure and Non-Secure OS. The latter is similar to mine but the answer does not tell what happens in the OP-TEE implementation.
So I am wondering what is the magic making the timer interrupt be handled again after returning to NW because it has been service once in SW.
I am not familiar with OP-TEE. And this is my first question. Please forgive me if it is not clear or stupid. Thanks.
Since nobody answers my question for one year I will try to give my own explanation.
NOTE that it is just MY own understanding. I am not an expert on such things.
The timer interrupt is generated and GIC changes the state from inactive to pending.
GIC forwards the interrupt request to the processor in Secure state. This is a foreign IRQ for SecureOS.
The IRQ handler in SecureOS works as Forward IRQ from secure world to normal world. I look into the source code of thread_irq_handler and cannot find the read for Interrupt Acknowledge Register.
The processor returns to Normal World. The state of the timer interrupt is still pending according to Interrupt handling state machine in GIC architecture specification.
GIC will signal the interrupt request to CPU at appropriate time.
The interrupt is serviced in Normal World.
My chain of reasoning is like this.
Interrupt Acknowledge Register is not read in IRQ handler of Secure OS.
--> The interrupt state is still pending.
--> GIC will signal the interrupt request to CPU.
I'm trying to do something odd to which I've not found reference in the archives. On a Freescale iMX6 processor, there's an input line that generates an interrupt after being pressed (the 500mS delay does not work), the intent of which interrupt is to notify the system of a request for an orderly shutdown. On the system in question, the button attached is also attached to the Enter key GPIO. The generated interrupt appears to be a falling edge/rising edge (or vice versa, it matters not) separated by about 75mS or so. The interrupt does not repeat unless the key is released and pressed again.
The bit to clear the interrupt in the ISR is in a register allocated and held by the Real Time Clock driver (a side effect of the Freescale architecture) so I have to embed my interrupt handler inside the RTC driver, which of course has its own interrupt code.
I thought myself clever when I implemented the suggestion to question 18296686 regarding shutting down (embedded) Linux from kernel-space, but that fails to distinguish between Enter and power-off. I need to detect the power-off interrupt, wait ~750-1000mS, and check whether the button (the <Enter> key is attached to a GPIO) is still depressed, thus signalling a power-off.
I was thinking a poll(2) interface to the driver, but since the driver is really the RTC driver, the interface confuses me, and I'm looking for help in implementing this.
Basic question about linux interrupt handling
In my driver i disable the interrupt line of a peripheral and do some processing, during this time peripheral is sending interrupt. when i enable the interrupt line i received the pending interrupt which happened during that time.
is this correct understanding?
If yes how can i discard those interrupt which came during the interrupt disable period.
I can implement some work around using some delay, looking for linux API or clean way to do this.
Before enabling the interrupt we can set
desc = irq_to_desc(client->irq);
desc->istate &= ~IRQS_PENDING;
and enable the interrupt line it will clear all the pending interrupt, but the code says we should never modify these variable.
Thank you
May be I did not understood but I think what you must do is:
disable interupt on the device directly and not using kernel interrupt handling routines
the poll your device, fetching all event. may be you should do this in a threaded interrupt handler
when finished re-enable interrupts on the device
I was wondering what is the step by step sequence of a keyboard interrupt. I know that everytime a key is pressed an interrupt is triggered and the interrupt is queued. If there's no higher priority process the CPU will be allocated to the interrupting process. My question is: where is the interrupting process located in the diagram below (before and after the interruption ). Is it in the ready queue waiting for something to happen or somewhere else ?.
This question was partially answered here https://stackoverflow.com/a/719676.
So I'm learning about threads at the moment and I'm wondering how some things are handled. For example, say I have a program where one thread listens for input and another performs some calculation on a single processor. When the calculation thread is running, what happens if the user should press a button intended for the input thread? Won't the input get ignored by the input thread until it is switched to that specific thread?
It depends a good deal on how the input mechanism is implemented. One easy-but-very-inelegant way to implement I/O is continuous polling... in that scenario, the input thread might sit in a loop, reading a hardware register over and over again, and when the value in the register changes from 0 to 1, the input thread would know that the button is pressed:
void inputThread()
{
while(1)
{
if (some_register_indicates_the_button_is_pressed()) react();
}
}
The problem with this method is that it's horribly inefficient -- the input thread is using billions of CPU cycles just checking the register over and over again. In a multithreaded system running this code, the thread scheduler would switch the CPU between the busy-waiting input thread and the calculation thread every quantum (e.g. once every 10 milliseconds) so the input thread would use half of the CPU cycles and the calculation thread would use the other half. In this system, if the input thread was running at the instant the user pressed the button, the input would be detected almost instantaneously, but if the calculation thread was running, the input wouldn't be detected until the next time the input thread got to run, so there might be as much as 10mS delay. (Worse, if the user released the button too soon, the input thread might never notice it was pressed at all)
An improvement over continuous polling is scheduled polling. It works the same as above, except that instead of the input thread just polling in a loop, it polls once, then sleeps for a little while, then polls again:
void inputThread()
{
while(1)
{
if (some_register_indicates_the_button_is_pressed()) react();
usleep(3000); // sleep for 30 milliseconds
}
}
This is much less inefficient that the first case, since every time usleep() is called, the thread scheduler puts the input thread to sleep and the CPU is made immediately available for any other threads to use. usleep() also sets a hardware timer, and when that hardware timer goes off (30 milliseconds later) it raises an interrupt. The interrupt causes the CPU to leave off whatever it was doing and run the thread-scheduling code again, and the thread-scheduling code will (in most cases) realize that its time for usleep() to return, and wake up the input thread so it can do another iteration of its loop. This still isn't perfect: the inputThread is still using a small amount of CPU on an ongoing basis -- not much, but if you do many instances of this it starts to add up. Also, the problem of the thread being asleep the whole time the button is held down is still there, and potentially even more likely.
Which leads us to interrupt-driven I/O. In this model, the input thread doesn't poll at all; instead it tells the OS to notify it when the button is pressed:
void inputThread()
{
while(1)
{
sleep_until_button_is_pressed();
react();
}
}
The OS's notification facility, in turn, has to set things up so that the OS is notified when the button is pressed, so that the OS can wake up and notify the input thread. The OS does this by telling the button's control hardware to generate an interrupt when the button is pressed; once that interrupt goes off, it works much like the timer interrupt in the previous example; the CPU runs the thread scheduler code, which sees that it's time to wake up the input thread, and lets the input thread run. This mechanism has very nice properties: (1) the input thread gets woken up ASAP when the button is pressed (there's no waiting around for the calculation thread to finish its quantum first), and (2) the input thread doesn't eat up any CPU cycles at all, except when the button is pushed. Because of these advantages, it's this sort of mechanism that is used in modern computers for any non-trivial I/O.
Note that on a modern PC or Mac, there's much more going on than just two threads and a hardware button; e.g. there are dozens of hardware devices (keyboard, mouse, video card, hard drive, network card, sound card, etc) and dozens of programs running at once, and it's the operating system's job to mediate between them all as necessary. Despite all that, the general principles are still the same; let's say that in your example the button the user clicked wasn't a physical button but an on-screen GUI button. In that case, something like the following sequence of events would occur:
User's finger presses the left mouse button down
Mouse's internal hardware sends a mouse-button-pressed message over the USB cable to the computer's USB controller
Computer's USB controller generates an interrupt
Interrupt causes the CPU to break out of the calculation thread's code and run the OS's scheduler routine
The thread scheduler sees that the USB interrupt line indicates a USB event is ready, and responds by running the USB driver's interrupt handler code
USB driver's interrupt handler code reads in the event, sees that it is a mouse-button-pressed event, and passes it along to the window manager
Window manager knows which window has the focus, so it knows which program to forward the mouse-button-pressed event to
Window manager tells the OS to wake up the input thread associated with that window
Your input thread wakes up and calls react()
If you're running on a single processor system, then yes.
Short answer: yes, threads always interact. The problems start to appear when they interact in a non-predictable way. Every thread in a process has access to the entire process memory space, so changing memory in one thread may spoil the data for another thread.
Well, there are multiple ways the thread can comunicate with each other. One of them is having global variable and use it as a buffer for communication beteen threads.
When you asked about button there must be a thread containing event loader loop. Within this thread, input won't be ignored according to my experience.
You can see some of my threads about this topic:
Here, I was interested how to make 3 thread application that do communicate through events.
The thread waiting for user input will be made ready 'immediately'. On most OS, threads that were waiting on I/O and have become ready are given a temporary priority boost and, even on a single-core CPU, will 'immediately' preempt another thread that was running at the same priority.
So, if a single-core CPU is running a calculation and another, waiting, thread of the same priority gets input, it will probably run straightaway.