Re: Direct rdtsc call side-effect

[Thomas Gleixner]

On Thu, Jun 01 2023 at 13:45, Muhammad Usama Anjum wrote:
> As more and more things are being added to Wine, Windows application can be
> run pretty easily on Linux. But this rdtsc is a big hurdle. What are your
> thoughts on solving this problem?

Who would have thought that rdtsc() in applications can be a problem.
Interfaces to query time exist for a reason and it's documented by
Microsoft:

https://learn.microsoft.com/en-us/windows/win32/dxtecharts/game-timing-and-multicore-processors

But sure, reading documentation is overrated...

> We are thinking of saving and restoring the timestamp counter at suspend
> and resume time respectively. In theory it can work on Intel because of
> TSC_ADJUST register. But it'll never work on AMD until:
> * AMD supports the same kind of adjust register. (AMD has said that the
> adjust register cannot be implemented in their firmware. They'll have to
> add it to their hardware.)
> * by manual synchronization in kernel (I know you don't like this idea. But
> there is something Windows is doing to save/restore and sync the TSC)

Synchronizing TSC by writing the TSC MSR is fragile as hell. This has
been tried so often and never reliably passed all synchronization tests
on a wide range of systems.

It kinda works on single socket, but not on larger systems.

We spent an insane amount of time to make timekeeping correct and I'm
not interested at all to deal with the fallout of such a mechanim.

I could be persuaded to make this work when TSC_ADJUST is available, but
that's it.

But even that might turn out to be just a solution for the moment
because there is a plan on the way that TSC grows an irreversible lock
bit, which prevents everything including SMM from fiddling with it,
which in turn spares the TSC_ADJUST sanity checks post boot.

Thanks,

        tglx