[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALCETrXam5bAUY6EGQEMqXnLHUcGJy1CBvGvQasDR_haXP3YyA@mail.gmail.com>
Date: Mon, 13 Nov 2017 10:06:47 -0800
From: Andy Lutomirski <luto@...nel.org>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>, X86 ML <x86@...nel.org>,
Borislav Petkov <bp@...en8.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-abi@...r.kernel.org
Subject: Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay?
On Mon, Nov 13, 2017 at 5:54 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> 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?
>
Dunno. I don't have such a machine.
But this is a genuine problem on machines with >4096 CPUs.
Powered by blists - more mailing lists