Mark Kettenis <mark.kette...@xs4all.nl> wrote:

> Before you go further down this path, please realize that "fixing" the
> TSC this way is racy in much the same ways as determining the skew is.
> If an SMM or a VM exit happens between reading the TSC and the actual
> write to the MSR, the new value of the TSC will be off by quite a bit.

It is probably possible to figure out circumstances where TSC modification
should not be attempted.

> IIRC, newer CPUs have an MSR that can apply a delta to the TSC, which
> circumvents that race.

Those newer cpus need the TSC repair.

Which means calculating the offsets, and programming them, which means using
some of the existing code.

The problem appears to be trying to use a single dumb method of modification,
when different cpus need different solutions.

> In the end I'm fairly skeptical about all the attempts to fix a
> fundamentally broken aspect of the architecture by throwing more and
> ever more complicated code at the problem.

That sentence doesn't help.  We have time moving backwards because of
processes hopping cpus.  THIS MUST BE SOLVED.  Other operating systems
have solved it best as they can -- what needs to understand is that
different generations of cpus need different solutions, and we need to
be looking at WHAT THEY DID, rather than writing code from scratch for
individual cpus and hoping it will work.  It won't work, we've been here
a few years, and it does not work.

Reply via email to