From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752829AbdKMNzE (ORCPT ); Mon, 13 Nov 2017 08:55:04 -0500 Received: from mail-lf0-f49.google.com ([209.85.215.49]:50410 "EHLO mail-lf0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752743AbdKMNy5 (ORCPT ); Mon, 13 Nov 2017 08:54:57 -0500 X-Google-Smtp-Source: AGs4zMat+4ToA3e3l2FWgFXCXNlBIfQxa4uXr28us9ZfrrkCuBYR3N8xJFxtTGPYDUtov1/FLeqq1w== Subject: Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay? To: Andy Lutomirski , Linus Torvalds , Peter Zijlstra , X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , linux-abi@vger.kernel.org References: From: Paolo Bonzini Message-ID: <814b0b22-ab9a-cb2b-b968-03e584700794@redhat.com> Date: Mon, 13 Nov 2017 14:54:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >