Re: [uml-devel] Explaination of system call function flow in TT mode

[Bodo Stroesser <bstroesser@fujitsu-siemens.com>]

Blaisorblade wrote:
> On Wednesday 18 May 2005 15:24, Young Koh wrote:
> 
>>>>Yeah, this is reasonable.  You have to be careful that you save and
>>>>restore any registers that might be used by one of the stubs, but they
>>>>don't use FP.
>>>
>>>I also thought about not saving FP-regs on each kernel entry. But if you
>>>do this optimization, you need to save / restore FP-regs on switch_to.
>>>Also you need to get the FP-regs when setting up a signal-handler
>>>stackframe. And they have to be restored on sys_(rt_)sigreturn from the
>>>values found in the stackframe.
>>
>>Thanks for the replies. let me understand them. In a SKAS mode UML
>>kernel, the pseudo code of a system call invocation would be like the
>>following.
>>
>>wait4(); // wait until a user process raises a syscall
>>save_registers(); // copy the user process' registers to UML kernel space
>>execute_syscall(); // execute the syscall in UML kernel context
>>restore_registers(); // copy the user registers back to the user process
>>
>>but, during execute_syscall(), even if its stubs use all the registers
>>and/or it happens to invoke switch_to(), it will happen all in the UML
>>kernel's context. that means the user process's context will be
>>protected by host kernel's context switching mechanism. doesn't it?
>>because the host kernel will automatically save/restore a process'
>>registers when the process is stopped and resumed, all we care about
>>in the above routine should be to get system call parameters from the
>>tracee and save the return value to it. shouldn't it? (again, only for
>>SKAS)
> 
> 
> Wait a moment, we have two cases:
> 
> 1) For the syscall execution, everything should be ok (apart the case the 
> syscall code needs to explicitly access the guest's registers).
> 
> 2) switch_to is used for process context switching, so is a different thing 
> from syscall execution. It's called by schedule() (which is called, mainly, 
> both by syscalls which do explicitly scheduling and by the timer tick; there 
> are also some additional cases when using preemption, but UML does not use 
> them; look for cond_resched() and similar things in kernel sources).
> 
> In this case, instead, for SKAS mode, we must switch the registers manually, 
> since we have collapsed everything in one host process. For TT and SKAS0 
> mode, instead, it's not needed, right Jeff and Bodo?

That's correct, nearly.

For SKAS0, it's not totally right, as there may be some threads on SKAS0
that have the same mm, i.e. threads in UML are created using CLONE_VM.

For those threads, SKAS0 works in the same way as SKAS3 generally does.
That means, there is one host-process only representing all those threads.
So registers have to be saved and restored when switching in this case, too.

	Bodo


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel