[uml-devel] System Call Mechanism

[uml-devel] System Call Mechanism

[kuas]

Hello,

I'm posting this question to here since this is development problem, the 
other newsgroup seems to be more like users problem and I would think 
this forum would be able to explain more about my question. I will post 
to the other newsgroup if that's the  one where I should really be posting

I'm trying to find out how the system call mechanism presently works in 
UML. I have looked into the high level description in the slides. Any 
pointers to any other documents that I might missed are appreciated.

I seems to me the new or current implementation of system call involves 
conversion from interupt 80 at the host OS into signals back in UML 
kernel. Is this the same mechanism for the current TT and SKAS? Or  TT 
mode still using ptrace thread tracing mechanism to intercept the system 
call? If there is a signal from the host to UML kernel process, there 
must be a signal handler registered by the UML kernel.

Any quick deeper overview about this mechanism would be really welcome. 
Thanks in advance.


Kuas.



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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

Re: [uml-devel] System Call Mechanism

[BlaisorBlade]

Alle 22:30, giovedì 19 febbraio 2004, kuas ha scritto:
> Hello,
>
> I'm posting this question to here since this is development problem, the
> other newsgroup seems to be more like users problem and I would think
> this forum would be able to explain more about my question. I will post
> to the other newsgroup if that's the  one where I should really be posting

Perfect choice. I'll try to answer, for things I know or I *think* to know.

> I seems to me the new or current implementation of system call involves
> conversion from interupt 80 at the host OS into signals back in UML
> kernel. Is this the same mechanism for the current TT and SKAS? Or  TT
> mode still using ptrace thread tracing mechanism to intercept the system
> call?

SKAS mode, the more modern one, still uses the same interception mechanism as 
TT: i.e. ptraces the child, intercepts the syscall, nullifies it (i.e. the 
host kernel receives a getpid syscall) and goes on. Look at these files:

arch/um/kernel/skas/process.c: handle_trap () and userspace().
arch/um/kernel/skas/syscall_*.c

Only difference is that in SKAS mode you have one single child process being 
ptraced, on the host; it runs the virtual processes code, and does syscall 
with int 0x80 which are intercepted. To do a context switch, UML uses setjmp 
and longjmp to switch the stack state and PTRACE_SWITCH_MM (implemented on 
the host inside arch/i386/kernel/ptrace.c, read the skas patch) to switch the 
virtual mappings of the child at once. More details about memory handling at 
request, since you asked for one exact thing and maybe are not interested in 
this.

> If there is a signal from the host to UML kernel process, there
> must be a signal handler registered by the UML kernel.
>
> Any quick deeper overview about this mechanism would be really welcome.
> Thanks in advance.


-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] System Call Mechanism

[Kuas]

Hi Blaisor,

Thanks for the response and info. I am still confused in how the system 
call arrive at process.c->userspace(). I guess the proposal in the 
presentation 
(http://user-mode-linux.sourceforge.net/slides/ols2002/img21.html), it 
said the next implementation would be to convert trap call to signal has 
never been implemented.

I checked in SKAS and TT mode, the idtr value is the same as the host 
machine and I can see from where you pointed, SKAS and TT has the same 
trap handler for system_call. But I don't really understand ptrace 
control, I am not totally sure how the system call is being intercepted 
and sent back to uml ends up in process.c->userspace(). Does every time 
interrupt is called, it will be caught by the host kernel ptrace and for 
system call (int 0x80) will be redirected back to the UML process. How 
does the information about the process that's requesting system call, 
syscall#, and arguments being passed to the UML Kernel. I understand 
since SKAS mode has collection of Virtual Address Spaces. Correct me if 
I'm wrong, will PTRACE_SWITCH_MM first change to the UML kernel process 
Address Space. But in SKAS mode, the UML kernel is also in the host 
address space (>0xc0000000), during this state we are already in the 
kernel space. So which child memory that PTRACE_SWITCH_MM switches when 
the system call? I am assuming the active Virtual Memory that's being 
replaced in UML process is the current uml process that generate the 
system call.


Kuas


BlaisorBlade wrote:

>>I seems to me the new or current implementation of system call involves
>>conversion from interupt 80 at the host OS into signals back in UML
>>kernel. Is this the same mechanism for the current TT and SKAS? Or  TT
>>mode still using ptrace thread tracing mechanism to intercept the system
>>call?
>>    
>>
>
>SKAS mode, the more modern one, still uses the same interception mechanism as 
>TT: i.e. ptraces the child, intercepts the syscall, nullifies it (i.e. the 
>host kernel receives a getpid syscall) and goes on. Look at these files:
>
>arch/um/kernel/skas/process.c: handle_trap () and userspace().
>arch/um/kernel/skas/syscall_*.c
>
>Only difference is that in SKAS mode you have one single child process being 
>ptraced, on the host; it runs the virtual processes code, and does syscall 
>with int 0x80 which are intercepted. To do a context switch, UML uses setjmp 
>and longjmp to switch the stack state and PTRACE_SWITCH_MM (implemented on 
>the host inside arch/i386/kernel/ptrace.c, read the skas patch) to switch the 
>virtual mappings of the child at once. More details about memory handling at 
>request, since you asked for one exact thing and maybe are not interested in 
>this.
>
>  
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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

Re: [uml-devel] System Call Mechanism

[BlaisorBlade]

Alle 03:29, sabato 28 febbraio 2004, Kuas ha scritto:
> Hi Blaisor,
> Thanks for the response and info.

Hi Kuas, sorry for answering this late. However, next time be clearer in how 
you write your email. I skipped to other things when I first noticed your 
mail was not enough fast to read - caring about spaces and marks is 
important; writing the way one speaks makes a harder job for the reader.

> I am still confused in how the system
> call arrive at process.c->userspace().

And I am learning it while answering you since I never started learning it 
properly. So, thanks for the stimulus to learn it.

> I guess the proposal in the
> presentation
> (http://user-mode-linux.sourceforge.net/slides/ols2002/img21.html), it
> said the next implementation would be to convert trap call to signal has
> never been implemented.

No idea, not yet read that.

> I checked in SKAS and TT mode, the idtr value is the same as the host
> machine and I can see from where you pointed, SKAS and TT has the same
> trap handler for system_call. But I don't really understand ptrace
> control, I am not totally sure how the system call is being intercepted
> and sent back to uml ends up in process.c->userspace().

> Does every time
> interrupt is called, it will be caught by the host kernel ptrace and for
> system call (int 0x80) will be redirected back to the UML process. 

This means you'll soon read "man ptrace" and check for PTRACE_SYSCALL.
However, for SKAS mode: every time a process is created, a thread is created 
which executes new_thread_handler or fork_handler. They call userspace(), and 
it has a while(1) loop which wait()'s for the child stopping and when it gets 
a SIGTRAP, executes handle_trap which handles the syscall.

grep -e '\<userspace\>' arch/um/kernel/skas/*.c

> How
> does the information about the process that's requesting system call,
> syscall#, and arguments being passed to the UML Kernel.

This is done by inspecting the registers. See this:

static void handle_trap(int pid, union uml_pt_regs *regs)
{
        int err, syscall_nr, status;

        syscall_nr = PT_SYSCALL_NR(regs->skas.regs);

PT_SYSCALL_NR is defined in arch/um/include/sysdep-i386/ptrace_user.h and 
means read_PTrace_SYSCALL_NumbeR.

Note: I hope for you that you use either LXR or Exuberant Ctags with an editor 
supporting it, or Freescope (I do not use it but it's good): i.e. from an 
identifier get its definition and where it is used (ctags gives you only the 
definition). Google is your friend while searching for these tools. If you do 
not use them, do not hope to understand anything (yes, the code is there, but 
avoiding using those tools is like reading directly the disassembled vmlinux 
file)

> I understand
> since SKAS mode has collection of Virtual Address Spaces. Correct me if
> I'm wrong, will PTRACE_SWITCH_MM first change to the UML kernel process
> Address Space.

No - it changes the address space, but see below.

> But in SKAS mode, the UML kernel is also in the host
> address space (>0xc0000000), during this state we are already in the
> kernel space.

Wait a moment - the host kernel lives at addresses >0xc0000000. The UML kernel 
lives below that address - it starts from the START address defined in the 
linker script - see arch/um/Makefile:
 -DSTART=$$(($(TOP_ADDR) - $(SIZE)))
Where TOP_ADDR is normally 0xc0000000 (changes with CONFIG_HOST_2g_2g), while 
SIZE is 512 Mega * CONFIG_KERNEL_HALF_GIGS.

> So which child memory that PTRACE_SWITCH_MM switches when
> the system call? I am assuming the active Virtual Memory that's being
> replaced in UML process is the current uml process that generate the
> system call.

1)There is one virtual address space for each process (i.e. one mm_struct, 
task_struct->mm). Multiple thread share one single mm_struct.

2)What Uml does in SKAS mode is to have:
- one ptraced host thread which runs the guest userspace code, called 
userspace thread (with ps auxw, it gets a T in his state because it's 
ptraced);
- one ptracing host thread, called kernel thread, which executes only code 
from the Uml binary, called UML kernel thread. It is the one with lower pid, 
normally.

3)When it must switch to another guest process, the UML kernel thread stops 
the userspace thread and resumes it with a different EIP; but it must also 
make sure that it uses the correct mm_struct and correct memory mappings. 
Those mappings are not done directly through the hardware MMU but with mmaps 
from the /tmp/vmfile-XXXXXX which contains the "physical" memory of the 
guest; the host kernel then uses the hardware MMU to realize those mmaps.

So, the UML kernel thread sends a PTRACE_SWITCH_MM to the userspace thread. So 
in sys_ptrace current is the kernel thread. With the supplied pid, sys_ptrace 
finds the userspace thread, and changes its ->mm field. The next time it 
runs, the kernel will load the mappings of the other guest process.

PTRACE_MMAP and so on are to modify the various mm_struct's the child can use.

Reference about 2.4 kernel internals (this explains in 2.2 what active_mm is):
http://www.moses.uklinux.net/patches/lki.html
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&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