On Fri, 2002-10-18 at 22:01, Andrea Arcangeli wrote:
> On Sat, Oct 19, 2002 at 06:45:56AM +0200, Andi Kleen wrote:
> > On Sat, Oct 19, 2002 at 06:10:19AM +0200, Andrea Arcangeli wrote:
> > > 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
> >
> > Ok, a sysctl that modifies a variable in the vsyscall page and is
> > tested by the code. That would be an option, I agree.
>
> the sysctl would replace the vsyscall fixmap fixmap entry for the
> current cpu enterely at switch_to time, I certainly don't want to add
> not necessary branches in the core vsyscall code. Doing it globally is
> zerocost but it would probably need privilegies as said, per-task could
> be more dynamic without privilegies and it would be an unlikely branch
> added in switch_to, still a very low cost so still acceptable.
>
> > For the locked TSC code we will need something like that anyways,
> > so that locked TSC can force a syscall.
>
> If we use a per-cpu TSC we don't need the syscall, the cpuid encoded in
> each 64bit variable will be enough (see my past email of yesterday
> evening, I realized a way to hanle per-cpu info with vsyscalls). the
> main problem is as usual that the TSC isn't a real time source, it
> changes frequency all the time, but as usual all the problems in the
> gettimeofday implementation have little to with the vsyscalls details,
> in particular now that I realized how to handle per-cpu data, they're
> generic issues that needs solving even if vsyscalls would redirect to
> the syscalls.
>
> The only thing we definitely can't do in the vsyscalls is to read the
> PIT because it's an old I/O mapped device, but who could ever live only
> with the PIT anyways these computing days? If you've only the PIT
> vsyscalls or not the gettimeofday functionality would suck.
>
> 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/