All of lore.kernel.org
 help / color / mirror / Atom feed
From: Young Koh <young.koh@gmail.com>
To: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
Cc: Jeff Dike <jdike@addtoit.com>,
	Blaisorblade <blaisorblade@yahoo.it>,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] Explaination of system call function flow in TT mode
Date: Wed, 18 May 2005 09:24:07 -0400	[thread overview]
Message-ID: <3524bf1f050518062432e093d6@mail.gmail.com> (raw)
In-Reply-To: <428B0F2B.3060503@fujitsu-siemens.com>

> > 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 on switch_to. Also you
> need to get the FP-regs when setting up a signal-handler stackframe. And they
> have to be restored on sys_(rt_)sigreturn from the values found in the
> stackframe.
 
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(); // copy the user process' registers to UML kernel space
execute_syscall(); // execute the syscall in UML kernel context
restore_registers(); // copy the user registers back to the user process

but, during execute_syscall(), even if its stubs use all the registers
and/or it happens to invoke switch_to(), it will happen all in the UML
kernel's context. that means the user process's context will be
protected by host kernel's context switching mechanism. doesn't it?
because the host kernel will automatically save/restore a process'
registers when the process is stopped and resumed, all we care about
in the above routine should be to get system call parameters from the
tracee and save the return value to it. shouldn't it? (again, only for
SKAS)

Thanks a lot!



> As s390 can give me regs and FP-regs in one single ptrace call, I decided to
> not do this optimization. Maybe for i386 and x86_64 it would be worth the cost.
> 
>        Bodo
> >
> >                               Jeff
>


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id\x16344&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2005-05-18 13:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <003e01c503b3$f3e46cb0$ac655e0a@sha.st.com>
2005-01-28 19:10 ` [uml-devel] Explaination of system call function flow in TT mode Blaisorblade
2005-02-02 15:29   ` [uml-devel] " Alex LIU
2005-02-03 19:38     ` Blaisorblade
2005-05-16 14:08   ` [uml-devel] " Young Koh
2005-05-16 17:08     ` Blaisorblade
2005-05-16 18:52       ` Young Koh
2005-05-16 20:52         ` Jeff Dike
2005-05-16 21:24         ` Blaisorblade
2005-05-17  0:09           ` Young Koh
2005-05-17  0:17             ` Blaisorblade
2005-05-17 17:56               ` Young Koh
2005-05-17 22:00                 ` Jeff Dike
2005-05-18  9:47                   ` Bodo Stroesser
2005-05-18 13:24                     ` Young Koh [this message]
2005-05-18 14:57                       ` Blaisorblade
2005-05-18 15:09                         ` Jeff Dike
2005-05-18 15:26                         ` Bodo Stroesser
2005-05-18 15:03                       ` Jeff Dike
2005-05-18 13:33                     ` Jeff Dike
2005-05-18 15:20                       ` Bodo Stroesser
2005-05-18 15:28                         ` Blaisorblade
2006-02-09 22:08   ` Young Koh
2006-02-09 23:38     ` Jeff Dike

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3524bf1f050518062432e093d6@mail.gmail.com \
    --to=young.koh@gmail.com \
    --cc=blaisorblade@yahoo.it \
    --cc=bstroesser@fujitsu-siemens.com \
    --cc=jdike@addtoit.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.