Version: 3.5.0 OS: Linux testcase: int main() { asm("rdtscp":::"eax", "edx", "ecx"); return 0; } Result: vex amd64->IR: unhandled instruction bytes: 0xF 0x1 0xF9 0xB8 0x0 0x0 Reproducible: Didn't try
What is rdtscp used for? And what CPU is this on?
It's like rdtsc, but it also returns the contents of the TSC_AUX MSR. An OS can decide to use this to encode the current CPU number, for example, so that an application can tell when it has been migrated between CPUs. If tsc values are not synchronized between cpus, then it may not be meaningful to compare a tsc value with one read previously on another cpu. This is not generally useful in usermode (using raw tsc in usermode is highly dubious), but it may appear as part of a system library which is doing the right thing (esp a kernel-supplied vdso or the like).
Created attachment 69198 [details] Implement RDTSCP for x86-64 Valgrind 3.7.0 crashes on x86-64 when it encouters the RDTSCP instruction. The attached patch (against 3.7.0) fixes the problem.
*** Bug 311933 has been marked as a duplicate of this bug. ***
*** Bug 313348 has been marked as a duplicate of this bug. ***
*** Bug 313354 has been marked as a duplicate of this bug. ***
We should fix this. It's been hanging around for ages. (In reply to comment #2) > It's like rdtsc, but it also returns the contents of the TSC_AUX MSR. An OS > can decide to use this to encode the current CPU number, for example, so > that an application can tell when it has been migrated between CPUs. If tsc > values are not synchronized between cpus, then it may not be meaningful to > compare a tsc value with one read previously on another cpu. The reason I haven't fixed it so far is because I've never been clear what TSC_AUX MSR value should be returned. But I guess this can't be simulatd, and so this insn should just be passed directly through to the host, and whatever that returns, be presented to the guest. Just as RDTSC is at the moment.
I guess also it'll need some capability bits checking, so that (1) we don't accept it on hosts that don't accept it, and (2) we don't get SIGILLd on the host when doing the helper function to extract the values from the host.
I think you should fix it, because more and more program will use rdtsc instead of rdtscp in muit-core platform. (In reply to comment #7) > We should fix this. It's been hanging around for ages. (In reply to > comment #2) > It's like rdtsc, but it also returns the contents of the > TSC_AUX MSR. An OS > can decide to use this to encode the current CPU > number, for example, so > that an application can tell when it has been > migrated between CPUs. If tsc > values are not synchronized between cpus, > then it may not be meaningful to > compare a tsc value with one read > previously on another cpu. The reason I haven't fixed it so far is because > I've never been clear what TSC_AUX MSR value should be returned. But I > guess this can't be simulatd, and so this insn should just be passed > directly through to the host, and whatever that returns, be presented to the > guest. Just as RDTSC is at the moment.
rdtscp returns the processor ID in ecx as well as the usual in eax:edx. On Linux this is just 0, 1, 2, or 3 for a 4 core box. The crucial importance of this is that the TSC may not be synced between cores so if your process is moved to a different core between calls to rdtsc, the results may be invalid. The new instruction allows the caller to detect this. The caller may of course fix the issue by setting affinity instead. Of course rdtscp also serializes the instruction stream, so there is no need for a prior cpuid.
(In reply to comment #8) > I guess also it'll need some capability bits checking, so that (1) we don't > accept it on hosts that don't accept it, and (2) we don't get SIGILLd on the > host when doing the helper function to extract the values from the host. It shouldn't matter so long as it gets delivered to the client with the right context. Even if you do cap checking, you need to generate a SIGILL anyway if the client executes it on a non-supported CPU.
> I guess also it'll need some capability bits checking, so that (1) we don't > accept it on hosts that don't accept it, and (2) we don't get SIGILLd on the > host when doing the helper function to extract the values from the host. If that is an issue, then you should also check prctl(PR_GET_TSC) as well because rdtsc[p] will fail with SIGSEGV if CR4.TSD is set. I dont see its any different in this respect to the old instruction?
Fixed, r2701, r13337.