问题
I have read a similar answer to question regarding context switching on StackOverflow: How does schedule()+switch_to() functions from linux kernel actually work?
However, i'm still puzzled by the internals and lack the understanding of how a newly switched process (previously preempted) will resume its execution in userland (assuming it was interrupted there) on Linux.
So far, the general flow of the context switch (on v4.20):
- a process is executing in userland (lets say
firefox) - the CPU clock generates an interrupt
- the scheduler is called
- __schedule() is called
- if the new task (lets say
systemd) is different than the current one, context_switch() is called - context_switch calls switch_to()
- At this point, the CPU context is switched to the next task, including stack and virtual address space
- the previous task is returned by context_switch()
At this point I don't understand what's happening:
-> Is this new task executing ? in the switch_to code, I didn't see any reference to the instruction pointer of the task_struct being used.
-> How does my systemd process continues its execution in userland ?
-> Are we supposed to hit an iret somewhere ? I saw the resume_kernel and resume_userspace symbols in entry_32.S but I don't understand how they are connected to the scheduler.
-> Why is there no instruction pointer field in the task_struct->thread structure ? How the IP is stored and restored ?
-> Does evey context switch involve an interrupt followed by an iret ? And therefore can i rely on this fact to catch a context switch (by catching the CR3 load) and singlestep until I execute an iret ?
Note: I'm asking the question because i'm trying to build a guest-aware, hypervisor-level debugger. Hence, I'm developping a PTRACE_ATTACH like functionality, but by only using the hypervisors-s VMI APIs
Thank you very much for your time and answers ! 🙂
来源：https://stackoverflow.com/questions/54771450/linux-context-switch-internals-how-does-a-process-goes-back-to-userland-after-t