Re: [uml-devel] high-performance system calls using vsyscall

[Blaisorblade <blaisorblade@yahoo.it>]

On Friday 13 January 2006 00:38, Jeff Dike wrote:
> On Thu, Jan 12, 2006 at 12:02:16PM -0500, Young Koh wrote:
> > I found an old post discussing the possibility of turning a system
> > call into a procedure call using vsyscall. Is it really implemented in
> > recent versions? I tested with recent Linux/UML kernels and glibcs but
> > system calls don't seem that fast. so, i guess it's not implemented
> > yet?

> In the generic kernel (or in whatever arches have the vsyscall page),
> it's used for only a small number of system calls.

No, wrong - on x86 it's used for everything, depending on userspace (it's 
replacing int 0x80 with sysenter). For some reason, on x86-64 it was that 
way, but it switched to what you say (implementing only a few syscalls 
directly in userspace).

> In a tt-style UML, where the UML kernel is in the same address space
> as the process, this could be used for all system calls, where you
> would just jump from there into the UML kernel.

1st, TT mode is kept there only until SKAS0 will be damn stable (it seems 
we're probably reaching that, no foreseen problems, except maybe my new TLS 
code doesn't work for SKAS0 yet IMHO), and because it's the only SMP 
supporting mode.

However, going through ptrace for interprocess comunication is far from 
optimal - using something like, say, POSIX message queues (it's a wild guess) 
would be probably faster. Something purely in userspace seems difficult. 
However, as shown below, if it's not purely in userspace ptrace will 
intercept it, so we stop any gain.

> I think you would have to fiddle libc to make all of the system calls for 
this.

No, you have to do worse - newer libc (more or less NPTL ones) link to a DSO 
which is the vsyscall page, which we can't replace. However maybe the address 
is not fixed, so we could pass the address of another vsyscall page with our 
code.

Obviously ptrace can't be disabled, as int 0x80 is still usable inside UML, 
and you must catch that. Also the normal vsyscall page is still mapped and 
could be run, so sysenter must be also caught.

Once you pass another vsyscall page to glibc, you must only write the 
implementation, distinguish the syscalls from that page (which must go in) 
from the syscalls coming from everywhere else (which must still be 
intercepted the normal way). Indeed, you still get to trace even new-style 
syscalls this way (adding an API for checking something in kernel before 
switching to the debugger is ugly, especially because we indeed must inspect 
the stack to see where the syscall come from).

> 				Jeff

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade


	
	
		
___________________________________ 
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive 
http://it.messenger.yahoo.com



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&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