Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay?

[Paolo Bonzini]

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
>