Linux Process switching issues

Source: Internet
Author: User

#define SWITCH_TO (Prev,next,last) do {         unsigned long esi,edi;         ASM volatile ("pushfl\n\t"                      "PUSHL%%ebp\n\t"                      "MOVL%%esp,%0\n\t"/* Save ESP */                      "MOVL%5,%%esp\n\t"/* Restore ESP */"                      MOVL $1f,%1\n\t"/* Save EIP */"                      PUSHL%6\n\t"/* Restore EIP */                      "jmp __switch_to\n"                      "1:\t "                      popl%%ebp\n\t" "                      POPFL"                      : "=m" (PREV->THREAD.ESP), "=m" (PREV->THREAD.EIP),                       "=a" (last), "=s" (ESI), "=d" (EDI)                      : "M" (Next->thread.esp), "M" (NEXT->THREAD.EIP),                       "2" (prev), "D" (Next));} while ( 0)

Note: Switch_to is a macro, so the Prev,next,last parameter is passed through the register, is directly in the stack of local variables, switch_to Note: This is a macro, not a function, its parameters prev, next, last is not a value copy, It is the local variable of its caller Context_switch (). Local variables are indexed by%EBP registers, that is, by N (%EBP), n is the compile-time decision, and N is the same local variable in the same piece of code in different processes.

Prev and next in the a process are its local variables, which can be prev_a,next_b, referring to the memory address of the process descriptor

In a process, switch_to (Prev,next,prev)

Prev,next,last These three are local variables of the Schedue function, and the addresses are all based on the EBP

Step1: copy two local variables to register:

EAX <== prev_a or eax <==%p (%ebp_a)
EdX <== next_a or edx <==%n (%ebp_a)
Here both Prev and next are local variables of the a process.

Step2: Save the EBP and eflags of process a
Pushfl
PUSHL%EBP
Note that since ESP is still in the stack of a, these two items are saved to the kernel stack of the a process.

Step3: saves the current ESP to the a process kernel descriptor://thread_struct the Thread field: stores most registers such as ESP and EIP
"Movl%%esp,%[prev_sp]/n/t"/*save ESP */
It can be expressed as: Prev_a->thread.sp <== esp_a
When Switch_to is called, Prev is the process descriptor that points to the a process itself.

step4: The esp_b that was saved from the descriptor of next (process B) before switching out from B: actually loading NEXT->THREAD.ESP into ESP

"MOVL%[NEXT_SP],%%ESP/N/T"/* Restore ESP */
It can be expressed as: esp_b<== next_a->thread.sp
Note that next in the a process is the process descriptor that points to B.
From this point on, the current process of CPU execution is already a B process, because ESP already points to B's kernel stack. However, the current EBP still points to the kernel stack of the a process, so all local variables are still local variables in a, such as Next is essentially%n (%ebp_a), which is next_a, the process descriptor that points to B.

At this point, the stack of the process has been switched, but EBP is pointing to the kernel stack of the a process.

step5,6: Save the instruction address labeled 1 to the IP domain of the a process descriptor:

STEP6: Save the return address to the stack, then call the __switch_to () function, and the __switch_to () function completes the hardware context switch.
"Pushl%[next_ip]/n/t"/*restore EIP * * because ESP and EBP are not pointing to the same stack because of the previous step, the next variable is part of the a process's local variable, which represents the process descriptor pointer of B,next-> Thread.ip the kernel stack (that is, the kernel stack of B) pressed into next
"JMP __switch_to/n"/* regparmcall */

STEP7: after returning from __switch_to (), proceed from the 1: label, modify the kernel stack of EBP to B, and restore the eflags of B:
"Popl%%ebp/n/t"/* Restore EBP */
"popfl/n"/* Restore Flags */
If you return from __switch_to () and continue running from here, then B must have been switch_to recalled before, so it was definitely backed up by Ebp_b and Flags_b, where the recovery operation was performed.

Note that this time the EBP has pointed to the kernel stack of B, so the above prev,next and other local variables are not already in the a process stack, but rather in the B process stack (b was previously switched out before the two variables, so represent the B stack prev, next value), because prev = =%p (%ebp_b), and before B was last switched out, that location holds the descriptor address of the B process. If this is the end of the switch_to, the prev variable in the later code (i.e. the code after switch_to in the Context_switch () function) points to the B process, so that process B does not know which process to switch back from. In the code after switch_to from Context_switch (), we see that Finish_task_switch (This_rq (), prev) needs to know which process was switched from before, so We have to find a way to save the descriptor of a process to the stack of B, which is the last function.

STEP8: writes EAX to last to save the correct prev information in the stack of B.
"=a" (last) is Last_b <==%eax
The method of calling Switch_to from Context_switch () is:
Switch_to (prev, Next, prev);
So, this last is essentially prev, so after the SWITCH_TO macro executes, Prev_b is the correct process descriptor for a.
Here, last is the equivalent of copying a process descriptor address from the process a stack to the stack of process B.

EAX always keep the value of the process being switched

Linux Process switching issues

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.