Messages in this thread | | | Subject | Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay? | From | Paolo Bonzini <> | Date | Mon, 13 Nov 2017 14:54:43 +0100 |
| |
On 28/10/2017 21:38, Andy Lutomirski wrote: > We currently do this on boot: > > write_rdtscp_aux((node << 12) | cpu); > > This *sucks*. It means that, to very quickly obtain the CPU number > using RDPID, an ALU op is needed. It also doesn't bloody work on > systems with more than 4096 CPUs. > > IMO it should be ((u64)node << 32) | cpu.
MSR_TSC_AUX is still documented as reserving bits 32-63 in the October 2017 SDM, and indeed on a Haswell you get a #GP if you write a nonzero value to it.
Has Intel quietly "unreserved" them on machines that have RDPID?
Thanks,
Paolo
> Then getting the CPU number is just: > > RDPID %rax > MOVL %eax, %eax > > I'm thinking about this because rseq users could avoid ever *loading* > the rseq cacheline if they used RDPID to get the CPU number, and it > would be nice to give them a sane way to do it. > > This won't break any existing RDPID users if we do it quickly because > there aren't any (the CPUs aren't available). I would be a bit > surprised if anyone uses RDTSCP for this because it's absurdly slow. > > We can change this without affecting the LSL hack, and I think there > are user programs that do the LSL hack. > > --Andy >
| |