Re: [PATCH 0/1] ptrace_vm: let us simplify the code for ptrace and add useful features for VM

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Jeff Dike <jdike@...>
Cc: LKML <linux-kernel@...>, Roland McGrath <roland@...>
Date: Tuesday, June 17, 2008 - 3:08 pm

On Tue, Jun 17, 2008 at 12:25:11PM -0400, Jeff Dike wrote:
So, we agree on this.
Maybe we can find out better tag names.
In the patch I submitted PTRACE_VM_SKIPCALL implies PTRACE_VM_SKIPEXIT
as it is useless to have a notification after nothing has been done.
So, there are three behaviors after the first notification:
0 -> do the syscall and notify after it
PTRACE_VM_SKIPEXIT -> do the syscall and do not notify after it
PTRACE_VM_SKIPCALL -> skip everything.
Please help me to find better tag names.
There is a misunderstanding about what I meant with "some syscall gets
virtualized and some others do not". Obviously it if a fault of mine, it
was poorly explained. Let me briefly describe our partial virtual
machines to explain one possible application for these tags.
(the complete documentation of the project can be found here:
wiki.virtualsquare.org).

umview (and now kmview using a kernel module based on utrace) decides if
a syscall must be virtualized or not depending on the value of its
arguments, not on the syscall number. With "system call" I mean "call of
a system call", a "system call call";-)

For example, *mview {umview,kmview} can virtualize just a subtree of the
file system, thus a "open" system call gets virtualized only if the path
refers to a file in the subtree. Consequently a system call like "read"
becomes virtual if the file descriptor was created by a virtualized
open, otherwise the process executes the standard read provided by the
kernel.

In this way users can (virtually) mount file system images just for the
processes running inside a *mview instance, or run user-level network
stacks, virtual devices, define their own perspective on everything
(uid, gid, system name). We have virtualized even the pace of the time
flowing.

We do not "boot" a different kernel, there are just modules that users
can combine to virtualize different entities:
- umfuse for the file system
- umnet for networking
- umdev for devices
- umtime, umbinfmt, umtime, umname... 

We need all the different behaviors listed above.
PTRACE_VM_SKIPCALL -> for the system calls we virtualize.
PTRACE_VM_SKIPEXIT -> for the non virtualized system call.
0 -> sometimes we need the kernel to execute a different system call
or just we need to provide the process with a different output.
In the "open" situation above, we need the kernel to run something to
acquire a real file descriptor, as the process sees a mix of real and
virtual open files.

I think that other projects can benefit from this generalization, while
UML can use PTRACE_VM_SKIPCALL as it is currently using PTRACE_SYSEMU,
maybe extending this optimization to other architectures.

	renzo
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 0/1] ptrace_vm: let us simplify the code for ptra..., Renzo Davoli, (Tue Jun 17, 3:08 pm)