From: Jeff D. <jd...@ka...> - 2001-05-23 01:00:26
|
bod...@bo... said: > rfork(), actually... I have no idea what the 'r' stands for, though ;) Oops :-) > Hmm, yes, I'm fooling around with #include right now, it really wants > the Linux headers installed elsewhere... it's quite a bother... There are going to be two types of includes, Posix and non-Posix. If a Posix include isn't found on BSD, it's because I included by the wrong name. There ought to be a path by which I can include it which is the same on Linux and BSD. In these cases, I need to know the Posix name so I can fix it. The non-Posix headers which aren't on BSD are Linux-specific should be in Linux-specific code which isn't compiled on BSD. So, I think the thing to do is start figuring out Posix names for headers that have them and splitting Linux-specific code and includes from the generic stuff. Fiddling around with -I's at this point is probably like pounding a square peg through a round hole. The system probably wants you to do things differently and it's probably right. Jeff |
From: Jeff D. <jd...@ka...> - 2001-05-23 14:25:19
|
ja...@en... said: > There are using it to intercept the syscall entry (S_SCE) and the > syscall exit (S_SCX) in the FreeBSD' s truss program(http:// > www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/truss/). Truss doesn't look like it can nullify system calls. Also, it intercepts BSD system calls, not Linux system calls. > What do you think about ? Are they the IOCTLs on a process' s PROC > file descriptor (I mean "/proc/<PID>/mem") ? OK, the plan is to just execute the Linux processes, and let them fault whenever they do an int 0x80 syscall (BSD apparently uses a different entry mechanism, so int 0x80 just causes a SEGV or something). The tracing thread will intercept the fault, examine the process to see if a system call caused it, execute it normally, and nullify the int 0x80 instruction by ip += 2. I thought that was a bit gross at first, but it's growing on me for another reason. That reason is that it will ultimately let us run UML without the tracing thread on FreeBSD. The system call interception will be done in the fault handler, which means that there won't be the context switching back and forth on each system call. That means that FreeBSD will run UML much faster than Linux can, which amuses me greatly. I'm planning on adding a similar mechanism to the host Linux at some point, but it can be done now without kernel mods on any OS that uses a different system call entry than Linux and faults Linux system calls. Linux obviously can't fault its own system calls, which is why a new mechanism is needed. Also, this provides automatic mode switching between kernel and user mode. UML will be a native FreeBSD app using FreeBSD system calls, and its processes will be executing Linux system calls which mean nothing to the FreeBSD kernel. So, the only code that can run system calls on the host is the kernel part of UML. Jeff |
From: Henrik N. <hn...@ma...> - 2001-05-23 16:45:43
|
Jeff Dike wrote: > Also, this provides automatic mode switching between kernel and user mode. > UML will be a native FreeBSD app using FreeBSD system calls, and its processes > will be executing Linux system calls which mean nothing to the FreeBSD kernel. > So, the only code that can run system calls on the host is the kernel part of > UML. And UML tasks knowing the method for making syscalls on FreeBSD, unless of course if you have a trancer thread which intercepts these.. which brings you back more or less to the Linux design but with the tracer thread looking for Linux syscalls on SEGV (or whatever), and SEGV the process on a direct FreeBSD syscall... Note: Running UML without the tracer thread may seem like a good idea, but then you will have serious "SMP" issues to deal with as each task will effectively run on it's own "CPU"... not sure if the Linux kernel is prepared for such a design, and the locking for sure isn't unless you also redesign spinlocks to reschedule the host task (kernel portion) rather than busy-wait (this change is probably a good idea to do for UML anyway as there is no direct correlation between host CPU and UML "CPU"). -- Henrik Nordstrom |
From: Me <bod...@bo...> - 2001-05-23 20:05:38
|
On Wednesday 23 May 2001 08:38, Jeff Dike wrote: > Truss doesn't look like it can nullify system calls. Also, it intercepts > BSD system calls, not Linux system calls. Save that idea for usermode FreeBSD ;) > OK, the plan is to just execute the Linux processes, and let them fault > whenever they do an int 0x80 syscall (BSD apparently uses a different entry > mechanism, so int 0x80 just causes a SEGV or something). The tracing > thread will intercept the fault, examine the process to see if a system > call caused it, execute it normally, and nullify the int 0x80 instruction > by ip += 2. Yes. > I thought that was a bit gross at first, but it's growing on me for another > reason. > > That reason is that it will ultimately let us run UML without the tracing > thread on FreeBSD. The system call interception will be done in the fault > handler, which means that there won't be the context switching back and > forth on each system call. That means that FreeBSD will run UML much > faster than Linux can, which amuses me greatly. Hmmm, good thought... my first version would be very similar to how it's currently done on Linux, with slight modifications as mentioned above. However, the lack of tracing thread is a good ultimate goal... but it might add some disparity between the ports until a similar hack gets working on Linux. > I'm planning on adding a similar mechanism to the host Linux at some point, > but it can be done now without kernel mods on any OS that uses a different > system call entry than Linux and faults Linux system calls. Linux > obviously can't fault its own system calls, which is why a new mechanism is > needed. Yes, hopefully Linus will let you sneak in a UML hook like he did for the DOSEmu folks. It can be a generic hook, of course. > Also, this provides automatic mode switching between kernel and user mode. > UML will be a native FreeBSD app using FreeBSD system calls, and its > processes will be executing Linux system calls which mean nothing to the > FreeBSD kernel. So, the only code that can run system calls on the host is > the kernel part of UML. Let's just hope that FreeBSD's Linux emulation enviroment isn't clever enough to intercept the Linux system calls, I'll have to look in to this. I'd hate to have to run User Mode Linux with FreeBSD's Linux emulation disabled because they were battling over syscalls... -Ryan |
From: Jeff D. <jd...@ka...> - 2001-05-23 17:44:48
|
hn...@ma... said: > And UML tasks knowing the method for making syscalls on FreeBSD, > unless of course if you have a trancer thread which intercepts these.. > which brings you back more or less to the Linux design Yup. Good point. > Running UML without the tracer thread may seem like a good idea, but > then you will have serious "SMP" issues to deal with as each task will > effectively run on it's own "CPU" Not quite. ps may make it look like that, but on a n-processor virtual machine, there no more than n tasks runnable on the host. That gives it n virtual processors, not one virtual processor per task. > ... not sure if the Linux kernel is > prepared for such a design Sure it is. That's the whole point of SMP. > , and the locking for sure isn't unless you > also redesign spinlocks to reschedule the host task (kernel portion) The current spinlocks aren't a correctness problem. > rather than busy-wait (this change is probably a good idea to do for > UML anyway as there is no direct correlation between host CPU and UML > "CPU"). They're a performance problem. One processor may spin for its entire quantum while the processor that holds the lock is switched out. What's more, once the lock is released and the spinner gets it, there's a good chance that the two (or more) processors will convoy through the rest of the code and contend for the remaining locks. Jeff |
From: <r1s...@in...> - 2001-05-24 06:20:04
|
Is it possible to eliminate the tracing thread totally? How will context switches be possible then? If the "previous" thread continues the "next" thread and then stops itself, that may not a true "emulation" of context switch. Jeff Dike <jd...@ka...> on 05/24/2001 12:28:25 AM Please respond to Jeff Dike <jd...@ka...> To: Henrik Nordstrom <hn...@ma...> cc: use...@li... (bcc: V Srivatsa/India/IBM) Subject: Re: [uml-devel] "clone"-like on FreeBSD hn...@ma... said: > And UML tasks knowing the method for making syscalls on FreeBSD, > unless of course if you have a trancer thread which intercepts these.. > which brings you back more or less to the Linux design Yup. Good point. > Running UML without the tracer thread may seem like a good idea, but > then you will have serious "SMP" issues to deal with as each task will > effectively run on it's own "CPU" Not quite. ps may make it look like that, but on a n-processor virtual machine, there no more than n tasks runnable on the host. That gives it n virtual processors, not one virtual processor per task. > ... not sure if the Linux kernel is > prepared for such a design Sure it is. That's the whole point of SMP. > , and the locking for sure isn't unless you > also redesign spinlocks to reschedule the host task (kernel portion) The current spinlocks aren't a correctness problem. > rather than busy-wait (this change is probably a good idea to do for > UML anyway as there is no direct correlation between host CPU and UML > "CPU"). They're a performance problem. One processor may spin for its entire quantum while the processor that holds the lock is switched out. What's more, once the lock is released and the spinner gets it, there's a good chance that the two (or more) processors will convoy through the rest of the code and contend for the remaining locks. Jeff _______________________________________________ User-mode-linux-devel mailing list Use...@li... http://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel |
From: Jeff D. <jd...@ka...> - 2001-05-24 13:06:09
|
r1s...@in... said: > How will context switches be possible then? If the "previous" thread > continues the "next" thread and then stops itself, that may not a true > "emulation" of context switch. Why not? Do you consider that the small period of time where there are two runnable processes to break the emulation of context switching? In fact, my first _switch_to did essentially that: kill(SIGCONT, next_pid); kill(SIGSTOP, getpid()); but that's unfixably racy. The next process would often immediately run, consume its quantum, switch back, and the current process would finish _switch_to and stop itself. It might be possible to make something like this work: block SIGSOMETHING kill(SIGSOMETHING, next_pid); sigsuspend(/* with SIGSOMETHING enabled */); However, my real plan is to add userspace address space manipulation to the host, so that UML can have one process per virtual processor, which switches address spaces during a context switch. That would eliminate the transfer of control between threads, plus whatever races that entails. Jeff |
From: <r1s...@in...> - 2001-05-24 13:53:47
|
My only concern was the "small" window that will be present during context switch when we have two processes running simultaneously. If the "previous" thread has all signals blocked when it is doing context switch, then this window is probably OK. Jeff Dike <jd...@ka...> on 05/24/2001 07:49:42 PM Please respond to Jeff Dike <jd...@ka...> To: V Srivatsa/India/IBM@IBMIN cc: use...@li... Subject: Re: [uml-devel] "clone"-like on FreeBSD r1s...@in... said: > How will context switches be possible then? If the "previous" thread > continues the "next" thread and then stops itself, that may not a true > "emulation" of context switch. Why not? Do you consider that the small period of time where there are two runnable processes to break the emulation of context switching? In fact, my first _switch_to did essentially that: kill(SIGCONT, next_pid); kill(SIGSTOP, getpid()); but that's unfixably racy. The next process would often immediately run, consume its quantum, switch back, and the current process would finish _switch_to and stop itself. It might be possible to make something like this work: block SIGSOMETHING kill(SIGSOMETHING, next_pid); sigsuspend(/* with SIGSOMETHING enabled */); However, my real plan is to add userspace address space manipulation to the host, so that UML can have one process per virtual processor, which switches address spaces during a context switch. That would eliminate the transfer of control between threads, plus whatever races that entails. Jeff _______________________________________________ User-mode-linux-devel mailing list Use...@li... http://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel |
From: Jeff D. <jd...@ka...> - 2001-05-24 14:53:53
|
r1s...@in... said: > My only concern was the "small" window that will be present during > context switch when we have two processes running simultaneously. If > the "previous" thread has all signals blocked when it is doing context > switch, then this window is probably OK. If you look at _switch_to, you'll see that all signals are either blocked or forwarded to the next process before the actual switch begins. Jeff |