Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1103933imm; Wed, 6 Jun 2018 10:27:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLHtc8VJApX9/R/MRTiQGbC2/uC5WGywCFo05sABet+CUR2csPa5JYtz8rg9OgISDZE0NmS X-Received: by 2002:a63:84c6:: with SMTP id k189-v6mr3370290pgd.49.1528306072436; Wed, 06 Jun 2018 10:27:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528306072; cv=none; d=google.com; s=arc-20160816; b=rPjLa1/LgGCvMkNhXPuCkVJFZxjP+UjZgU9EB0ymG//6NNi1xvA00xIZ032S1Ooo23 ll2iSv5iGgBEOmzZk0JgPXBY7qCbwsmSeEO2zh2878TN/n1b1dLS2TYOhMD+SsxznTAs PWCpmj2Uq+C7swPTNinc/+s7Jqi2d8wvmAvC/t1JmXrRfRLDQBMY8/q5gZvQszYdHWMF 7GhuplqRvCX0NRCWwtPw2InxdfyaIrNbmLtbxBb7ilGkkPYV0fpgYynvPgW9ya6wmH7o rW6z90coQc/0X41KDQT1HxbvT4Sn6BASNMNODbmSmT0hK0kqEsZAMawBJFzsFSG4nNe6 IxIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=Gb59ZgfAdsLswQAj3Y4FXgGj5lfJsrTaZRD/huLdE5E=; b=gR8lpP0Ig7+VMP8prQuctLyjfWV6Ucjpv7UAhGq6Jbrkd0xj7LD1MciqwxMUfcpzcW u5Ijc32RMjhzwIYKAR89EMg1xHOToqOGMxM4JclVlpRgfqLDkgAcUX5mi/xC32+6KLYA 2CNsYBXJU3qpq4a65pS9PsaFUg3VXHR9wTLhdvEcUhHPyB3OxWtVmopAKEfEjlDSBaay DUWGyAVpwWDydKSdAoRIR7vJH1m5W4fVFkmmolTjMXTybspBVhq/zltXFvHtrcfhh2F3 e3GZH3jXcOX8lfYBwfx0HMDSe0ajcRB1tak2giNDl3uYyhnuxCLWrSmnDFGvNnZBIpIR xb6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=JePnL6Fj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d90-v6si52515520pld.92.2018.06.06.10.27.36; Wed, 06 Jun 2018 10:27:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=JePnL6Fj; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933709AbeFFRZa (ORCPT + 99 others); Wed, 6 Jun 2018 13:25:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:53100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933527AbeFFRZ3 (ORCPT ); Wed, 6 Jun 2018 13:25:29 -0400 Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CDBB42088F for ; Wed, 6 Jun 2018 17:25:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1528305929; bh=Car7aZSe45cg9+lXAnaq1Bi1GKoTaEC4Dr00Un6Fam8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=JePnL6FjCQEfLt702mFt5TS6bympyf0SwIZ5UA9KT+U6xDuZT3gYoDVgNgXulgjEa mJ5rqr1b/DoUHr9RpWk2xTHXDUWEXY4UBN0TrhXj1EMa/ZOEnAoZFVsvtouND2TDm4 Dih5/L6g+rgpNYTjiD61Z5DG7fEV/jb+pRvML89Q= Received: by mail-wr0-f182.google.com with SMTP id d8-v6so7152634wro.4 for ; Wed, 06 Jun 2018 10:25:28 -0700 (PDT) X-Gm-Message-State: APt69E0YuFZt3q0zZwDNYN5YhI4YI+HNbr/xMXRVwdXTlRkF8wJnFRvz vhjhLybK7Tsy3vizgadbhkB/rNl4IO/+egUB4XnYBQ== X-Received: by 2002:adf:fe4c:: with SMTP id m12-v6mr2946306wrs.171.1528305927376; Wed, 06 Jun 2018 10:25:27 -0700 (PDT) MIME-Version: 1.0 References: <1528302199-29619-1-git-send-email-chang.seok.bae@intel.com> <1528302199-29619-9-git-send-email-chang.seok.bae@intel.com> In-Reply-To: <1528302199-29619-9-git-send-email-chang.seok.bae@intel.com> From: Andy Lutomirski Date: Wed, 6 Jun 2018 10:25:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 8/8] x86/vdso: Move out the CPU number store To: "Bae, Chang Seok" Cc: Andrew Lutomirski , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Andi Kleen , Dave Hansen , "Metzger, Markus T" , "Ravi V. Shankar" , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae wrote: > > The CPU (and node) number will be written, as early enough, > to the segment limit of per CPU data and TSC_AUX MSR entry. > The information has been retrieved by vgetcpu in user space > and will be also loaded from the paranoid entry, when > FSGSBASE enabled. So, it is moved out from vDSO to the CPU > initialization path where IST setup is serialized. > Please split this into two patches. One patch should do the cleanups and one patch should move the code. > diff --git a/arch/x86/entry/vdso/vgetcpu.c b/arch/x86/entry/vdso/vgetcpu.c > index 8ec3d1f..3284069 100644 > --- a/arch/x86/entry/vdso/vgetcpu.c > +++ b/arch/x86/entry/vdso/vgetcpu.c > @@ -18,9 +18,9 @@ __vdso_getcpu(unsigned *cpu, unsigned *node, struct getcpu_cache *unused) > p = __getcpu(); > > if (cpu) > - *cpu = p & VGETCPU_CPU_MASK; > + *cpu = lsl_tscp_to_cpu(p); > if (node) > - *node = p >> 12; > + *node = lsl_tscp_to_node(p); > return 0; This goes in the cleanup patch. > +/* Bit size and mask of CPU number stored in the per CPU data (and TSC_AUX) */ > +#define LSL_TSCP_CPU_SIZE 12 > +#define LSL_TSCP_CPU_MASK 0xfff > + > +#ifndef __ASSEMBLY__ > + > +/* Helper functions to store/load CPU and node numbers */ > + > +static inline unsigned long make_lsl_tscp(int cpu, unsigned long node) > +{ > + return ((node << LSL_TSCP_CPU_SIZE) | cpu); > +} > + > +static inline unsigned int lsl_tscp_to_cpu(unsigned long x) > +{ > + return (x & LSL_TSCP_CPU_MASK); > +} > + > +static inline unsigned int lsl_tscp_to_node(unsigned long x) > +{ > + return (x >> LSL_TSCP_CPU_SIZE); > +} As do these. But maybe they should be #ifdef CONFIG_X86_64 to make it clear that they are not presently supported on 32-bit systems. (Unless I'm wrong and they are supported.) > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 38276f5..c7b54f0 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -1665,6 +1665,11 @@ void cpu_init(void) > > wrmsrl(MSR_FS_BASE, 0); > wrmsrl(MSR_KERNEL_GS_BASE, 0); > +#ifdef CONFIG_NUMA > + write_rdtscp_aux(make_lsl_tscp(cpu, early_cpu_to_node(cpu))); > +#else > + write_rdtscp_aux(make_lsl_tscp(cpu, 0)); > +#endif Why the ifdef? early_cpu_to_node() should return 0 if !CONFIG_NUMA. > +static inline void setup_cpu_number_segment(int cpu) > +{ > +#ifdef CONFIG_NUMA > + unsigned long node = early_cpu_to_node(cpu); > +#else > + unsigned long node = 0; > +#endif This duplicates half the rdtscp_aux code. How about making this one function setup_cpu_number() that does all of it? > + struct desc_struct d = GDT_ENTRY_INIT(0x40f5, 0x0, > + make_lsl_tscp(cpu, node)); Please get rid of the GDT_ENTRY_INIT stuff and just fill out all the fields, just like it is in the code that you're moving. No one enjoys decoding hex segment descriptors. (Well, Linus and hpa probably *love* doing it just to show off.)