On Thu, Feb 09, 2006 at 05:08:59PM -0500, Young Koh wrote:
> I have a question about system call implementation in tt mode. it
> seems that an invoked system call will be executed in tracee's
> context. (the tracer sends SIGUSR2 to the tracee and tracee executes
> the system call in usr2_handler) h
Hi,
I have a question about system call implementation in tt mode. it
seems that an invoked system call will be executed in tracee's
context. (the tracer sends SIGUSR2 to the tracee and tracee executes
the system call in usr2_handler) however, 'current' macro, which is
used to find the current tas
On Wed, May 18, 2005 at 04:57:47PM +0200, Blaisorblade wrote:
> In this case, instead, for SKAS mode, we must switch the registers manually,
> since we have collapsed everything in one host process. For TT and SKAS0
> mode, instead, it's not needed, right Jeff and Bodo?
Correct.
Jeff
On Wed, May 18, 2005 at 09:24:07AM -0400, Young Koh wrote:
> Thanks for the replies. let me understand them. In a SKAS mode UML
> kernel, the pseudo code of a system call invocation would be like the
> following.
>
> wait4(); // wait until a user process raises a syscall
> save_registers(); // cop
On Wednesday 18 May 2005 17:20, Bodo Stroesser wrote:
> Jeff Dike wrote:
> > On Wed, May 18, 2005 at 11:47:23AM +0200, Bodo Stroesser wrote:
> >>I also thought about not saving FP-regs on each kernel entry. But if you
> >> do this optimization, you need to save / restore FP-regs on switch_to.
> >>
Blaisorblade wrote:
On Wednesday 18 May 2005 15:24, Young Koh wrote:
Yeah, this is reasonable. You have to be careful that you save and
restore any registers that might be used by one of the stubs, but they
don't use FP.
I also thought about not saving FP-regs on each kernel entry. But if you
do t
Jeff Dike wrote:
On Wed, May 18, 2005 at 11:47:23AM +0200, Bodo Stroesser wrote:
I also thought about not saving FP-regs on each kernel entry. But if you do
this optimization, you need to save / restore FP-regs on switch_to. Also you
need to get the FP-regs when setting up a signal-handler stackfra
On Wednesday 18 May 2005 15:24, Young Koh wrote:
> > > Yeah, this is reasonable. You have to be careful that you save and
> > > restore any registers that might be used by one of the stubs, but they
> > > don't use FP.
> >
> > I also thought about not saving FP-regs on each kernel entry. But if yo
On Wed, May 18, 2005 at 11:47:23AM +0200, Bodo Stroesser wrote:
> I also thought about not saving FP-regs on each kernel entry. But if you do
> this optimization, you need to save / restore FP-regs on switch_to. Also you
> need to get the FP-regs when setting up a signal-handler stackframe. And
>
> > Yeah, this is reasonable. You have to be careful that you save and restore
> > any registers that might be used by one of the stubs, but they don't use
> > FP.
> I also thought about not saving FP-regs on each kernel entry. But if you do
> this optimization, you need to save / restore FP-regs
Jeff Dike wrote:
On Tue, May 17, 2005 at 01:56:55PM -0400, Young Koh wrote:
the tracer (UML kernel) saves and restores the tracee's registers
using ptrace() in order to get syscall paramaters and save the return
value. while doing this, the tracer would need to care about only six
registers(eax, eb
On Tue, May 17, 2005 at 01:56:55PM -0400, Young Koh wrote:
> the tracer (UML kernel) saves and restores the tracee's registers
> using ptrace() in order to get syscall paramaters and save the return
> value. while doing this, the tracer would need to care about only six
> registers(eax, ebx, ecx, e
Well, i got another question/suggestion.
the tracer (UML kernel) saves and restores the tracee's registers
using ptrace() in order to get syscall paramaters and save the return
value. while doing this, the tracer would need to care about only six
registers(eax, ebx, ecx, edx, esi, and edi) used f
On Mon, May 16, 2005 at 02:52:37PM -0400, Young Koh wrote:
> Suppose the tracee attmpts to invoke a host system call. then, it will
> be intercepted by the tracer as in TT mode. (In TT mode, the tracer
> turns off tracing and sends SIGUSR2 to the tracee, and then, the
> signal handler in the tracee
On Tuesday 17 May 2005 02:09, Young Koh wrote:
> Ok, now i'm getting close. Thanks a lot!!!
> but i have two more :)
>
> 1) in SKAS mode, the tracer (UML kernel) will execute a system call
> for the tracee (the user process). But what if the system call blocks?
> then, the tracer, the UML kernel, w
Ok, now i'm getting close. Thanks a lot!!!
but i have two more :)
1) in SKAS mode, the tracer (UML kernel) will execute a system call
for the tracee (the user process). But what if the system call blocks?
then, the tracer, the UML kernel, will be blocked, too, right? it
means the whole UML system
On Monday 16 May 2005 20:52, Young Koh wrote:
> Hi, Thanks for the reply. Let me have one following question.
>
> As my understand, in SKAS mode, tracer and tracee are different host
> processes, and they have UML kernel code and application code
> respectively. (in TT mode, tracee has both kernel
Hi, Thanks for the reply. Let me have one following question.
As my understand, in SKAS mode, tracer and tracee are different host
processes, and they have UML kernel code and application code
respectively. (in TT mode, tracee has both kernel and application
code)
Suppose the tracee attmpts to i
On Monday 16 May 2005 16:08, Young Koh wrote:
> Hi,
>
> Could you explain what happens in SKAS mode, then? How a UML kenel in
> SKAS mode handles the UML system calls differently from one in TT
> mode? i tried to understand from the code, but i had hard time to
> understand.
The usage of PTRACE_SYS
Hi,
Could you explain what happens in SKAS mode, then? How a UML kenel in
SKAS mode handles the UML system calls differently from one in TT
mode? i tried to understand from the code, but i had hard time to
understand.
Thank you very much!
On 1/28/05, Blaisorblade <[EMAIL PROTECTED]> wrote:
> On
20 matches
Mail list logo
