Re: [uml-devel] [Patch 1/1] uml: fix uml-use-sysemu-for-tt.patch

[Blaisorblade <blaisorblade_spam@yahoo.it>]

On Monday 15 November 2004 20:04, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Friday 12 November 2004 15:10, Bodo Stroesser wrote:
> >>From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
> >>
> >>The patch needs some small corrections:
> >>1) local_using_sysemu must be sampled *before* the next
> >>    ptrace(PTRACE_SYSEMU/SYSCALL) and must stay the same until
> >> do_syscall() has been done. Currently it is sampled before do_syscall()
> >> and is used after this for ptrace(PTRACE_SYSEMU/SYSCALL). Even if no
> >> problem is visible to the UML user, a single syscall could be executed
> >> on the host when switching on sysemu. The result of this then is
> >> overwritten by the syscall execution in UML.

> >>    Since the first event the tracer has to handle is not a syscall, it's
> >>    enough to initialize local_using_sysemu to 0;

> > Sorry, what happens if the first signal it gets is a SIGTRAP, and so
> > local_using_sysemu is not yet set? If this is impossible, please add a
> > comment in the code for this. However, it seems that it can get to the
> > SIGTRAP case with tracing == 1. When beginning the procedure, it is 0,
> > but it can be changed with the value from is_tracing(task). I've not
> > checked if that is zeroed on process creation (i.e. by do_fork() calling
> > copy_thread()), but just note that in the code.

> OK: Let's summarize:
> 1) tracer() is started exactly once.
> 2) The first this it does, is starting the first ptraced-process via
> clone(). 3) Then it waits until the new process stops.
> 4) Since the process will run start_kernel() in kernel space, it is resumed
>     with PTRACE_CONT.
> Thus, before having any syscall interception, the process has to stop
> itself with a SIGUSR1, giving the tracer an OP_TRACE_OP request. After this
> local_using_sysemu will be set and the process will be resumed with
> PTRACE_SYSCALL or PTRACE_SYSEMU.

> >>2) Even if the host never *does* a syscall in SYSEMU, we have to write
> >> the syscall number with -1, to not have the host doing syscall
> >> restarting. This would happen only with an invalid syscall number equal
> >> to one of the -ERESTART values.
> >>
> >>
> >>    But to be perfect ...

> > Yes, but shouldn't this be handled on the host? Restarting a syscall
> > which has never been done does not seem something that SYSEMU should
> > allow... I don't want anybody to need going through the code and checking
> > that this is safe.

> Yes. It should. So I exactly added this to the "advanced sysemu". But
> despite this UML should work on an older sysemu host, too. So I add this
> now, and with the SYSEMU_SINGLESTEP-patches a skip of writing -1 is
> inserted, if the new sysemu is in use.
Hmm - not yet had time to get near that (I'm busy), however if 
SYSEMU_SINGLESTEP fixes this API inconsistency, the old SYSEMU API will 
probably not be accepted by mainline developers, not it should be sent by us 
- remember that we want to try merging SYSEMU sooner than SKAS4.

No single UML (except some ones using the sysemu incremental version, which we 
don't want to support) is unable to run without SYSEMU, so dropping that 
support should be ok.

Also, this new mode must wait for now - get some time to test it, I'll do the 
same when I've time. Currently I have too few time.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel