From: H. Peter Anvin on
On 05/18/2010 01:29 PM, Dan Magenheimer wrote:
>
> Yes, understood, a minor semantic issue. From a kernel perspective
> vsyscalls are kernelspace, so IIUC this is OK with tglx/etc.
>
> Since vsyscall shouldn't be using rdtsc when the kernel
> doesn't trust TSC, it doesn't matter if CR4.TSD is enabled when
> the kernel doesn't trust TSC.
>

That is correct.

> I'm still not sure if you are in favor of optionally emulating
> PL3 rdtsc instructions or not? I thought my proposal was
> just filling out some details of your proposal and suggesting
> a default.

I'm not in favor of emulating rdtsc instructions. I would consider
letting them SIGILL (actually SIGSEGV since RDTSC #GP in userspace) when
the TSC is unavailable, though.

It's not clear to me that it's possible, though, since that also affects
RDTSCP.

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dan Magenheimer on
> > I'm still not sure if you are in favor of optionally emulating
> > PL3 rdtsc instructions or not? I thought my proposal was
> > just filling out some details of your proposal and suggesting
> > a default.
>
> I'm not in favor of emulating rdtsc instructions. I would consider
> letting them SIGILL (actually SIGSEGV since RDTSC #GP in userspace)
>
> It's not clear to me that it's possible, though, since that also
> affects RDTSCP.

(All the variations are boggling so hard to discuss in
a linear email thread.)

IIUC, tglx/arjan consider RDTSC and RDTSCP to be in the same
category. RDTSCP simply eliminates one large class of TSC
problems, but not all the possible system TSC problems that
the kernel can (or can't) detect. So userspace (non-vsyscall)
shouldn't use either one

Further, this one redeeming feature of RDTSCP can be useless
and/or misleading in a virtual machine the way the kernel
sets up TSC_AUX.

> when the TSC is unavailable, though.

Do you mean "when the processor doesn't support a TSC instruction"
(very rare nowadays AFAIK) or "when the kernel determines that
TSC is not safe to use as a clocksource"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on
> I'm not in favor of emulating rdtsc instructions. I would consider
> letting them SIGILL (actually SIGSEGV since RDTSC #GP in userspace) when
> the TSC is unavailable, though.

I doubt we could ever do that, it would likely break just too much
code. Yes the code is already broken likely on some system, but there's
a big difference between wrong time and crash.

-Andi
--
ak(a)linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on
On Tue, 2010-05-18 at 23:13 +0200, Andi Kleen wrote:
> > I'm not in favor of emulating rdtsc instructions. I would consider
> > letting them SIGILL (actually SIGSEGV since RDTSC #GP in userspace) when
> > the TSC is unavailable, though.
>
> I doubt we could ever do that, it would likely break just too much
> code. Yes the code is already broken likely on some system, but there's

s/some/most/

> a big difference between wrong time and crash.

Maybe start with a patch that logs all users and start sending patches
to the respective projects to clean them up.

Once we get most of userspace running fine, we can switch it to
generating faults.

Of course closed source stuff will have to deal with it themselves, but
who cares about that anyway ;-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Brian Bloniarz on
Ingo Molnar wrote:
> The point is for the kernel to not be complicit in
> practices that are technically not reliable.

One usecase that hasn't been discussed is when userspace needs this info to
calibrate the TSC.

Take NTP as an example. It does a pretty good job of observing the drift in
gettimeofday() against a reference clock and correcting for it. This seems
to work well even when GTOD uses the TSC. But, it assumes that the drift
changes slowly.

That goes out the window on reboot, because the kernel only spends 25ms on
TSC<->PIT calibration and the value of tsc_khz can vary a lot from boot to
boot. Then NTP starts up and reads a drift value from /var/lib/ntp/ntp.drift
that it *thinks* is accurate. In our experience, it'll then spend up to 48
hours doing god knows what to the clock until it converges on the real
drift at the new tsc_khz. initscripts could correct for the kernel's
recalibration, but tsc_khz isn't exported.

So it's too bad that it can't be exported somehow. The TSC on our
machines has proven to be stable for all intents and purposes; I just
checked 25 of my machines, most have uptime of >200 days, all of them
still have current_clocksource=tsc. After NTP or PTPd has been running
for a while, things converge, but being unable to reboot is a headache.
Using the HPET for gettimeofday() would be impractical for performance
reasons.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/