Re: [User-mode-linux-devel] Implementation question...

[Jeff D. <jd...@ka...>]

sa...@sk... said:
> Each virtual linux process is actually a real linux cloned process
> that runs under the host linux environment.  When something
> interesting happens (trap, fault, syscall, signal, etc...) the virtual
> linux kernel takes over and fixes stuff. 

So far, so good.

> Given this, it seems like UM Linux isn't using ptrace to actually do
> memory reads and writes to the user process... so what could the
> memory map of the mondo linux process look like?  Are all linux
> processes sharing a 3G process space of the UM-Linux kernel?

You run into trouble here.  If you do a ps in the host, you'll see a 'tracing 
thread' process.  That thread is ptracing all of the other threads mostly to 
intercept their system calls.

When one of the virtual processes does a system call, the tracing thread warps 
the process onto its (the process) kernel stack by ptrace(PTRACE_GETREGS, ...) 
to save the process state and ptrace(PTRACE_SETREGS, ...) to set its state to 
some previously saved state that puts it in syscall_handler which actually 
executes the system call.

Since processes run their own system calls, kernel text and data is present in 
each address space.  The memory map of a typical thread looks like:

0x8000000 - 0x80xxxxx : process text and data
0x10000000 - 0x10xxxxxx : kernel text and data
0x40000000 - 0x40xxxxxx : process shared libraries
0x50000000 - 0x5xxxxxxx : kernel "physical" and virtual memory
0xb7fxxxxx - 0xb8000000 : process stack
0xbffxxxxx - 0xc0000000 : original kernel stack (not used for much except 
storing the name you see with ps in the host)

Every process gets its own address space.  Kernel data is made shared with a 
nasty bit of code that you can find in remap_data() in 
um/arch/um/kernel/user_util.c.

> I'm trying to change this a bit to be more seperated and use ptrace to
> do reads and writes...

You need to be more clear about what you're up to...

get_user and friends are trivial since the address space contains both kernel 
and process data.  They are essentially memcpy().  (Actually, I just finished 
making them a lot less trivial in order for them to detect bogus address 
correctly, but that's irrelevant here.)

> The problem, however, is that the "UM User" processes and "UM Kernel"
> processes can have data mapped into the same addresses...

There is no such thing as a "kernel" process.  Every process runs its own 
kernel code.

				Jeff