Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp85822ima; Thu, 25 Oct 2018 16:01:56 -0700 (PDT) X-Google-Smtp-Source: AJdET5cBS9oZplJTdeysjKAOmuNyKoCOWaKUwfAZlg0E4fH2ag9MPDiniyAV6/SQWKvQFoBvulUw X-Received: by 2002:a62:475c:: with SMTP id u89-v6mr1060525pfa.225.1540508516382; Thu, 25 Oct 2018 16:01:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540508516; cv=none; d=google.com; s=arc-20160816; b=0gqFX6ik5FieOrZV8tq8bUzkggUy61vjzvFGC5y9PKVGjmmY9yplrAeDOjGTe27vpO JfapnrzLJH1TRaJE6Sf33/YWPpLueiNNU1VjhdTFfta+5vEtWeS58Q22c6fioTG2HoyF MlBdsFfvScRmuHM5EoZ2krOnaY//35DAf9pu13sTLbfd23BOuLj5r3PiZWAwMSfosjM5 F3DXjEq6T8J9bP0FSF+gcFV6jKeLZ/Py8D7dB8DlW98SBUOUohRYOcFmNLajXO73KdAy mS9G0Nwtbj3zDo7taAAKvRIrn/j+00JhylgNZjjOv6V6SLKFZEn5v/qqFQTHbthWiRN6 LItQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Vbju2y1mUUQF9PxRUZtJ6/DjRPOAfsCCC9dyCa1cvWU=; b=KIIRVyxY62KxHXp96kJfI+QfQMeHL3+teCIil61ZIHN6H9nK7/9sd5Ri4fPFRO+KTD 24It8qIT7ANxYme17r4XZuNDg6uEm6wkOrvex9UowWuz/rW6qiQJCNkJwuZg2PLuF4kh 1qyVPlzmdp3I71v/CWClVX9AdDk7QOHJ1XW4JB9KC3A5XiaF0up3mZ0ni9cbRB6pkvIo hnT1y4rMqwBtS6axxqJM3kc69Ss4Xsp0319+30BBnX8seThmFbvZdZKecfFyOw9r/0A+ rNo/ITTwOkR9MuWTn21lnaUyDRHni0R90NMQnpaSR7phhQ+oqkZ2sBhqOISiw9KeliV2 J/8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=EVaQpTed; 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 p25-v6si9801365pli.239.2018.10.25.16.01.35; Thu, 25 Oct 2018 16:01:56 -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=EVaQpTed; 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 S1727607AbeJZHfX (ORCPT + 99 others); Fri, 26 Oct 2018 03:35:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:47266 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727179AbeJZHfX (ORCPT ); Fri, 26 Oct 2018 03:35:23 -0400 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 7E7452085A for ; Thu, 25 Oct 2018 23:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1540508448; bh=TSi/HvAB3IHeN7eIzpproCcQ9Us3ENvQqFJb5ze9KLs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EVaQpTedSKJAKgwJzRAL+xEsXrVWTRILju0um6+62WxSwbtNQ1KOCWlnclyDZf0S0 j9fSmL6YK+YEvboM5eaUiuv9hRHL2a5cjU02nVflFbm3YpsXomQykBrfmIQ7CxKanf 4gaRTL/vc+mB/3sshIjrbAh1T2aNdLiYV2aNzMGk= Received: by mail-wr1-f44.google.com with SMTP id n5-v6so7167469wrw.12 for ; Thu, 25 Oct 2018 16:00:48 -0700 (PDT) X-Gm-Message-State: AGRZ1gIwyWAcstWP1orFZdGp09g6zdhuXih067Pdz2RJBVkft6yXGdbs HueetWtN2Nsj2IK/I3XlX4NQoc841S/ElZESokOljg== X-Received: by 2002:adf:82c9:: with SMTP id 67-v6mr3460785wrc.131.1540508446827; Thu, 25 Oct 2018 16:00:46 -0700 (PDT) MIME-Version: 1.0 References: <20181023184234.14025-1-chang.seok.bae@intel.com> <20181023184234.14025-5-chang.seok.bae@intel.com> <1EE75BE7-12C6-4BD9-9D31-E9C396D2015B@intel.com> In-Reply-To: <1EE75BE7-12C6-4BD9-9D31-E9C396D2015B@intel.com> From: Andy Lutomirski Date: Thu, 25 Oct 2018 16:00:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v3 04/12] x86/fsgsbase/64: Enable FSGSBASE instructions in the helper functions To: "Bae, Chang Seok" Cc: Andrew Lutomirski , Boris Ostrovsky , Juergen Gross , xen-devel , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Andi Kleen , Dave Hansen , "Metzger, Markus T" , "Ravi V. Shankar" , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 25, 2018 at 12:32 AM Bae, Chang Seok wrote: > > > > On Oct 24, 2018, at 12:16, Andy Lutomirski wrote: > > > > On Tue, Oct 23, 2018 at 11:43 AM Chang S. Bae wrote: > >> void x86_fsbase_write_cpu(unsigned long fsbase) > >> { > >> - /* > >> - * Set the selector to 0 as a notion, that the segment base is > >> - * overwritten, which will be checked for skipping the segment= load > >> - * during context switch. > >> - */ > >> - loadseg(FS, 0); > >> - wrmsrl(MSR_FS_BASE, fsbase); > >> + if (static_cpu_has(X86_FEATURE_FSGSBASE)) { > >> + wrfsbase(fsbase); > >> + } else { > >> + /* > >> + * Set the selector to 0 as a notion, that the segment= base is > >> + * overwritten, which will be checked for skipping the= segment load > >> + * during context switch. > >> + */ > >> + loadseg(FS, 0); > >> + wrmsrl(MSR_FS_BASE, fsbase); > >> + } > >> } > >> > >> void x86_gsbase_write_cpu_inactive(unsigned long gsbase) > >> { > >> - /* Set the selector to 0 for the same reason as %fs above. */ > >> - loadseg(GS, 0); > >> - wrmsrl(MSR_KERNEL_GS_BASE, gsbase); > >> + if (static_cpu_has(X86_FEATURE_FSGSBASE)) { > >> + wr_inactive_gsbase(gsbase); > >> + } else { > >> + /* Set the selector to 0 for the same reason as %fs ab= ove. */ > >> + loadseg(GS, 0); > >> + wrmsrl(MSR_KERNEL_GS_BASE, gsbase); > > > > I still don't get what this code is trying to do. See other email. I > > think it will straight up crash the kernel on some CPUs, since writing > > 0 to %%gs will zero out the *active* base on some CPUs. > > > > On those CPUs, how the old do_arch_prctl_64() worked? > loadseg(GS, 0) eventually hits the native_load_gs_index entry, where actu= al > mov =E2=80=A6, %gs is wrapped by two SWAPGSes. So, it won=E2=80=99t cause= the side effect > of overwriting the *active* base, I think. > > > I think that, if you really want some fancy optimization for the > > non-FSGSBASE case, you need to pull that out into the callers of these > > helpers. > I was thinking of loadsegment, not loadseg. Sorry!