Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp1881159ima; Sat, 2 Feb 2019 09:18:20 -0800 (PST) X-Google-Smtp-Source: AHgI3Ia54J4a0TKZdsd/Eqb5A/D8Fw+cSNqT/Bkox8gCZdawXzAIyZb0YSeBg5blrWKvdPleVkog X-Received: by 2002:a63:d413:: with SMTP id a19mr339427pgh.199.1549127900610; Sat, 02 Feb 2019 09:18:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549127900; cv=none; d=google.com; s=arc-20160816; b=e+uiye8R77nHxYaoaB8hvJsjEWtymBmtN/mG4RE4fn6e+QZDxK7LJW//jr3wh+mBUN 3vcTXPJUfNBl0SkM0nL4zmOqCFDX/dSvMDw3RWmVqWk6UzVMPrGDhBwb/BvY+kh+Lkoi L3T0qtifT0MqN6L3ENBiVP+fkkmSN8BzWTfOHkpzGs5bzQzJM9BGlqoCwCLtdHEfxKfb lDwIw6FH58UCQMoh7+j9ewktQBsV0E0hBHX4B3cSeYf5Nx8WAjPHyCI4BmglQ846ZDt3 xtuNWwBoqEW5AwRQhtJcenrKgdsYkPj3BAaTiGMDPv9iXth2xkVNfQrm3vI8K55SZMUK +KKw== 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; bh=riUnakO5RQTaLg1D2FDEUQ38/zozXJIkCQAIGgyM3k4=; b=cRE3BbXk9Pldi0H0Q364dsbu89PpnV4lroe6oWp0BkY9r5SD90oPoskDmm7Ij58I5I 0Qez7aNf35eYcCxHf/2/V5sWHi9c5JeH1x6BNfbDMR7+ghYWVLYdzM/Y20OI959PDmfH P25odiGR0ZbzCZPrXfvTtlKLtFBlwifSCR0Ln2O67g38EUEHw56ZFYanZ+UInk5U4lNR 7so3st9bFaHrW4J0nL+450chB615I7koB3nqnyHOMr//6YKGBky+exG6N5/TCcVMlyT0 U6U7GpXd9C1eEuEMyPM4CPARSi/48fopiCX4f9YCqAAySEd6Wm2uAFLNGURcIeFzBWRx H9gQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=sOCvd+cK; 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 f21si9543735pgv.111.2019.02.02.09.18.04; Sat, 02 Feb 2019 09:18:20 -0800 (PST) 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=sOCvd+cK; 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 S1726609AbfBBRRh (ORCPT + 99 others); Sat, 2 Feb 2019 12:17:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:54956 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725828AbfBBRRg (ORCPT ); Sat, 2 Feb 2019 12:17:36 -0500 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 9A00321736 for ; Sat, 2 Feb 2019 17:17:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549127855; bh=24a0LauQNznepneUW/7Bv/Md29M2ImLAc3+uQJbDo5M=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=sOCvd+cKddkbA1YOlmfHa12qphRCFfJcCDk4P/zS+HvDdiIsKErmFy3xJxYsqsSAa njZkiVS/Wv9EibeXzuvLFFPfyKIZHkGyW7j6xhTbIY7WPQjNpDUa+kesMaDja80A39 YajAHrbiUx3vO5j8SDtuPHzkQ+zH2ur5DThgy4TM= Received: by mail-wm1-f42.google.com with SMTP id g67so9252043wmd.2 for ; Sat, 02 Feb 2019 09:17:35 -0800 (PST) X-Gm-Message-State: AHQUAuaCjGtxm0TMvfuEFgHRLUFaZjY+UDfqBopyFYGd0BAFjbPlPxLe nT0K0cjZxw7zsZV5ZPOtek2TjzCMfIo80QadPL899g== X-Received: by 2002:a1c:b1d5:: with SMTP id a204mr7296202wmf.32.1549127854036; Sat, 02 Feb 2019 09:17:34 -0800 (PST) MIME-Version: 1.0 References: <20190201205319.15995-1-chang.seok.bae@intel.com> <20190201205319.15995-10-chang.seok.bae@intel.com> In-Reply-To: <20190201205319.15995-10-chang.seok.bae@intel.com> From: Andy Lutomirski Date: Sat, 2 Feb 2019 09:17:22 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 08/13] x86/fsgsbase/64: Introduce the FIND_PERCPU_BASE macro To: "Chang S. Bae" Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andi Kleen , Markus T Metzger , Ravi Shankar , LKML , Dave Hansen 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 Fri, Feb 1, 2019 at 12:55 PM Chang S. Bae wrote: > > GSBASE is used to find per-CPU data in the kernel. But when it is unknown, > the per-CPU base can be found from the per_cpu_offset table with a CPU NR. > The CPU NR is extracted from the limit field of the CPUNODE entry in GDT, > or by the RDPID instruction. > > Also, add the GAS-compatible RDPID macro. > > The new macro will be used on a following patch. > > Suggested-by: H. Peter Anvin > Signed-off-by: Chang S. Bae > Cc: Andy Lutomirski > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Dave Hansen > Cc: Andi Kleen > --- > arch/x86/include/asm/fsgsbase.h | 46 +++++++++++++++++++++++++++++++++ > arch/x86/include/asm/inst.h | 15 +++++++++++ > 2 files changed, 61 insertions(+) > > diff --git a/arch/x86/include/asm/fsgsbase.h b/arch/x86/include/asm/fsgsbase.h > index aefd53767a5d..eecca2250748 100644 > --- a/arch/x86/include/asm/fsgsbase.h > +++ b/arch/x86/include/asm/fsgsbase.h > @@ -78,6 +78,52 @@ extern void x86_gsbase_write_cpu_inactive(unsigned long gsbase); > > #endif /* CONFIG_X86_64 */ > > +#else /* __ASSEMBLY__ */ > + > +#ifdef CONFIG_X86_64 > + > +#include > + > +#if CONFIG_SMP ifdef? > + > +/* > + * CPU/node NR is loaded from the limit (size) field of a special segment > + * descriptor entry in GDT. > + */ > +.macro LOAD_CPU_AND_NODE_SEG_LIMIT reg:req > + movq $__CPUNODE_SEG, \reg > + lsl \reg, \reg > +.endm > + Please put the alternative in here instead of in FIND_PERCPU_BASE. > +/* > + * Fetch the per-CPU GSBASE value for this processor and put it in @reg. > + * We normally use %gs for accessing per-CPU data, but we are setting up > + * %gs here and obviously can not use %gs itself to access per-CPU data. > + */ > +.macro FIND_PERCPU_BASE reg:req > + /* > + * The CPU/node NR is initialized earlier, directly in cpu_init(). > + * The CPU NR is extracted from it. > + */ This comment is unnecessary. > + ALTERNATIVE \ > + "LOAD_CPU_AND_NODE_SEG_LIMIT \reg", \ > + "RDPID \reg", \ > + X86_FEATURE_RDPID > + andq $VDSO_CPUNODE_MASK, \reg > + movq __per_cpu_offset(, \reg, 8), \reg > +.endm > + > +#else > + > +.macro FIND_PERCPU_BASE reg:req > + /* Tracking the base offset value */ I don't understand this comment at all. Please just remove it.