On Fri, Oct 18, 2002 at 11:49:59PM -0500, Jeff Dike wrote:
> ak@muc.de said:
> > Guess you'll have some problems then with UML on x86-64, which always
> > uses vgettimeofday. But it's only used for gettimeofday() currently,
> > perhaps it's  not that bad when the UML child runs with the host's
> > time.
> 
> It's not horrible, but it's still broken.  There are people who depend
> on UML being able to keep its own time separately from the host.
> 
> > I guess it would be possible to add some support for UML to map own
> > code over the vsyscall reserved locations. UML would need to use the
> > syscalls then. But it'll be likely ugly. 
> 
> Yeah, it would be.
> 
> My preferred solution would be for libc to ask the kernel where the vsyscall
> area is.  That's reasonably clean and virtualizable.  Andrea doesn't like it
> because it adds a few instructions to the vsyscall address calculation.

yes, my preferred solution is still a runtime /proc entry that turns off
vsyscalls completely by root so you could trap gettimeofday/time via the
usual ptrace. That would be zero cost. Of course this would be needed
only for the special users needing a revirtualized time. I tend to think
most people don't need a revirtualized time in uml, the exceptions can
run slower [not slower than x86 of course except for an additional
call/ret pair that won't matter compared to the ptrace overhread of
every syscall]. I mean, I would prefer to optimize for the people who
needs fast performance, if you can deal with the ptrace overhead at
every sysenter/sysret most probably you don't need the vsyscalls in the
first place.

My argument is that whatever solution to this problem has a penalty of
some kind, and I prefer to keep the penalty on the side of the most
unlikely case, and as far as I can tell it's the case of people needing
uml running with revirtualized real time. certainly I want to make it
possible, but I don't care to optimize for it, I want it (not the
others) to pay for the additional feature it needs.

If the global sysctl is unacceptable, the next fallback would be to have
a per-task information that defaults to vsyscall to execute the syscall,
a check in switch_to could replace the fixmap entry with the one of the
other vsyscall. That would be an additional single unlikely branch in
switch_to unless I'm overlooking something and I could live with it
despite it's not an absolute zero cost. That should be still *much*
better than glibc asking to kernel the address of the vsyscalls using a
syscall after execve and using pointer to functions later at runtime to
invoke the vsyscalls, I don't really like that solution.

So I would go with:

1) global sysctl to turn off vgettimeofday/vtime
2) if 1) is unacceptable then per-task turnoff of vsyscalls would be the
   next viable solution

Comments?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/