[PATCH 2/2] UTRACE_STOP: nesting engine management (updated)

[Renzo Davoli]

> Again, we need Roland's opinion, but could you explain why it would
> be better to use _reverse in utrace_report_syscall_entry() ?

I refer to this posting:
http://www.mail-archive.com/utrace-devel@redhat.com/msg00579.html

Item #4 explains why it is *needed* to reverse the order in utrace_report_syscall_entry
to have a consistent implementation of nested virtualization.

> I don't think this is safe. If we do utrace_stop() here, the next engine
> can be detached before we return (UTRACE_DETACH assumes it it safe to
> unlink the engine when the target is stopped). This means we can't
> continue list_for_each_entry(engine, &utrace->attached, entry) after
> return from finish_callback().

Maybe this is not the best patch, maybe we can solve the problem in a
better way.
The point is explained in #3 in the same posting cited above.

When a report function of an engine returns UTRACE_STOP, it means (may mean)
that it wants to change the status of the process before resuming it.
VM monitors often change the status, sometimes debugger users want to set
some variables too.

IMHO, utrace should stop it *before* calling the report function of the 
next engine, otherwise we need to set up another structure to synchronize
the engines (that may even be unknown one to the other).
If there is a tracer/debugger among the engines, it is not even possible to know
which snapshot it gets, after or before the modification created by the VM
monitor?

With these patches it is possible to run nested virtual machines based
on utrace, it is also possbile to strace (use ptrace) on processes running
inside a VM.

	renzo