pitfalls of using rdtsc and possible improvements of Trace::timestamp()

[atopia]

The discussion at atopia@272e77a#r151401339 has brought up some possible room for improvement regarding the Trace::timestamp() method and highlighted some pitfalls regarding the non-serializing nature of rdtsc that I want to outline here mostly for documentation:

• As previously established (cf. Wondering about Trace::timestamp() on x86_{32,64} #4243), rdtsc is non-serializing.
• Typical mitigations include using cpuid or lfence for serialization.
• cpuid has the downside of unconditionally causing VM exits when running virtualized on VMX (cf. Intel SDM September 2023 Vol. 3C 26.1.2 Instructions That Cause VM Exits Unconditionally) and SVM (cf. AMD64 Architecture Programmer’s Manual November 2021 Volume 2 15.9
  Instruction Intercepts). Given the unreliable nature of TSC based measurements when running virtualized (last but not least because the rdtsc instruction will itself cause VM exits depending on hypervisor settings), this is probably of little practical concern.
• lfence is only dispatch serializing on AMD hardware when MSR C001_1029[1]=1 (see the previously mentioned https://hadibrais.wordpress.com/2018/05/14/the-significance-of-the-x86-lfence-instruction/ )
• For a more accurate measurement one could add an lfence instruction after rdtsc (see the previously mentioned https://sites.utexas.edu/jdm4372/2018/07/23/comments-on-timing-short-code-sections-on-intel-processors/ ) but from the discussion at https://stackoverflow.com/a/59766404 , this should usually not be a problem:

With respect to later instructions, rdtsc in the lfence/rdtsc sequence may be dispatched for execution simultaneously with later instructions. This behavior may not be desirable if you also want to precisely time these later instructions as well. This is generally not a problem because the reservation station scheduler prioritizes older uops for dispatching as long as there are no structural hazards.

Seeing that contrary to the Linux kernel (cf. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=be261ffce6f13229dad50f59c5e491f933d3167f ) we don't set lfence to be dispatch serializing on AMD across our supported kernels and the limited usefulness of rdtsc for measuring virtualized code execution, the current use of cpuid for serialization in Trace::timestamp() is probably fine. If at some point we need a more precise measurement, we could set the MSR on AMD and switch to a full lfence; rdtsc; lfence (or alternatively rdtscp; lfence) sequence for maximum reliability with minimal measurement overhead.