Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3324199pxj; Tue, 11 May 2021 01:41:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyk6WMAfllgECL//+fKwqyuAnpgoZTjQiru8SyecSawSsXEEZDOM5jKdN9/CG10bzBmR+F7 X-Received: by 2002:a02:37c9:: with SMTP id r192mr25202404jar.88.1620722494001; Tue, 11 May 2021 01:41:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620722493; cv=none; d=google.com; s=arc-20160816; b=viJoG5apfrN9wEisTQ+m1FKUb4aJBanP+3CAEwq3mFfjveXaEtxAntsI5UANy6bbIP vW3bV2ENlgblasxKzQf/ZoDf5/QLXkTVxOo98ejY0RMBVhEebWExxeGmnrhlz/y9Kopa CveQMDxEFg6pVFuTdT0YNKWFn17IdXTu53yt8gChNlhAoUj48EgpaTg8VRrRyBHwlRRZ aShQ+6CwKn+VaR7t7bjME2ZPBJA+mPHSKC+s7f7ER42STQDXqIS/LMnO9uCc4yfDPr9H 38vl9Bw90NlGKTsPKsLhzcxzcoGzG+ORvCsM52mUp1xJdoea0wB2szCSjOK06R/FRzuK I/Ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=YW4M4L/7AHlbX388X4aHywuWSD5VXnrjQHVqx3UIEg8=; b=KtLeLLNsinFYVxOn+cR29eZUiOEJNUD06TG2Njg28KpGjrrs3BScUOwPrPjNMA73K0 l6LSdw4bi7/DWZeiGg+3YBrX8numyNkWMFB0eIPIgQpeMR7FASSh1SrrCy+EaF3Vhdxf /3Z7cBbDWk5nW7tcGCN6CN/Kt/Pdf3o3bgyfLKV2+/GADLgipHpHtQALYX2SNt7H0kfb BLmiBhLbnJlbEzXOC0ztvuCLkIyI6h1I+sOeFCTKIYHpW/mrlxd0iPNP5a+4jb+GvyPg PFkW1lz2vr+NjXd2Q4Ubrn8GldL0jBV54kKt6OfJjQnBIDni051ZNmse4DEDcSgSntzQ RhPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=XSrEV44E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h21si18045957jav.99.2021.05.11.01.41.21; Tue, 11 May 2021 01:41:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=XSrEV44E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230427AbhEKIkm (ORCPT + 99 others); Tue, 11 May 2021 04:40:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229995AbhEKIkh (ORCPT ); Tue, 11 May 2021 04:40:37 -0400 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4E9EC061574 for ; Tue, 11 May 2021 01:39:30 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id a10-20020a05600c068ab029014dcda1971aso723013wmn.3 for ; Tue, 11 May 2021 01:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YW4M4L/7AHlbX388X4aHywuWSD5VXnrjQHVqx3UIEg8=; b=XSrEV44EGgV+69Znk/NICoQRS+BUTAcAlvvz58OmkeAD4uThmdRUd9ya+4m5DJYRTv BQM1Izx2bf9xG3clqERbzYn/MOVhBs7o5G3ASaOoUrsKvxQ1tjAZHVd33WTd3N8skpzi QQ8YBYb9faOVcW4Gdvs2SVcfiTIHWT88eABjjsTmCGk4j6VQIs8Wq1/qPHmDKKyHSY0A 0BXD5kbGLdoHqTjOl8ZYZce7jueVqhDOMdXjxN0v7WxiyUweaPwPqFCrhV4753JgyA1j vQ+4t55UjBctsMrilbmmx1ae1uBIxrrypZC9yVkoRUO4Q1t67qXxKJuTRicpAe62br6S j/Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YW4M4L/7AHlbX388X4aHywuWSD5VXnrjQHVqx3UIEg8=; b=k0Wfu+kAaIFW2gi3TkhXtkxbq2kp1NEpzjbTNmTefAuJ3l22e732rt2Dh9FOvg4MAs 3p1HqHGyi/9/3U60cI/14VmLslNLibDGzg0Oq2tFKrUMNgGWFC/ExUgpnH2D/diGTnCa 9E5jiI8ewnibkJPH/hbRFJyIY6oeguv6xYl9rL5zYtUKxfE13PHkOz7D8zIzRoxLmdn4 aNBrFQEc/IjmCj/aTGuxbQrZLPnjfMXez8UvfBNapyT892zZSpsSyM8MiYjlcmOZhNYp 1lH8SzTMeiOi+CeICf/fiiilIoVR/a1O1e2rsHHc/h5+9xJAmJRAsHWN0AWd+haJvdlr k2ww== X-Gm-Message-State: AOAM532EM2Y1wos2jsLVbJ+dCqtURmF+v/jK9GJPsCzu1exYNUDd1ukk SVezSXfYP8NVSrdGoRH0jgaAo6rnLUDW/yX1Yu2NHw== X-Received: by 2002:a1c:2704:: with SMTP id n4mr1089154wmn.147.1620722369062; Tue, 11 May 2021 01:39:29 -0700 (PDT) MIME-Version: 1.0 References: <20210429084410.783998-1-amistry@google.com> <20210429184101.RFC.v2.1.Iadd904c1764f3bfe260db30fe41bdb9b8f98533d@changeid> <878s4wdwyy.ffs@nanos.tec.linutronix.de> In-Reply-To: <878s4wdwyy.ffs@nanos.tec.linutronix.de> From: "Anand K. Mistry" Date: Tue, 11 May 2021 18:39:15 +1000 Message-ID: Subject: Re: [RFC PATCH v2 1/2] x86/speculation: Allow per-process control of when to issue IBPB To: Thomas Gleixner Cc: x86@kernel.org, Joel Fernandes , Anthony Steinhauser , Borislav Petkov , Andy Lutomirski , Ben Segall , Catalin Marinas , "Chang S. Bae" , Daniel Bristot de Oliveira , Dave Hansen , Dietmar Eggemann , Fenghua Yu , Gabriel Krisman Bertazi , "H. Peter Anvin" , Ingo Molnar , Jay Lang , Jens Axboe , Juri Lelli , Kees Cook , Lai Jiangshan , Mel Gorman , Mike Rapoport , Oleg Nesterov , Peter Collingbourne , Peter Zijlstra , Steven Rostedt , Tony Luck , Vincent Guittot , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 3 May 2021 at 18:48, Thomas Gleixner wrote: > > Anand, > > On Thu, Apr 29 2021 at 18:44, Anand K. Mistry wrote: > > > > -static inline unsigned long mm_mangle_tif_spec_ib(struct task_struct *next) > > +static inline unsigned long mm_mangle_tif_spec_ib_on_leave( > > + struct task_struct *next) > > { > > unsigned long next_tif = task_thread_info(next)->flags; > > - unsigned long ibpb = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_IBPB; > > + unsigned long spec_disabled = > > + (next_tif >> TIF_SPEC_IB) & ~(next_tif >> TIF_NO_IBPB_LEAVE); > > + unsigned long ibpb = spec_disabled & LAST_USER_MM_IBPB; > > > > return (unsigned long)next->mm | ibpb; > > } > > > > +static inline bool ibpb_on_entry(struct task_struct *next) > > +{ > > + unsigned long next_tif = task_thread_info(next)->flags; > > + unsigned long spec_disabled = > > + (next_tif >> TIF_SPEC_IB) & ~(next_tif >> TIF_NO_IBPB_ENTRY); > > + return spec_disabled & 1; > > +} > > Why exactly do we need _three_ TIF bits and this non-intuitive inverted > logic? The inverted logic is to avoid any side effects of flag bits defaulting to 0, which should keep the existing behaviour of doing an IBPB on both entry and exit. > > The existing mode is: Issue IBPB when scheduling in and when scheduling out. > > Ergo the obvious approach for making it more finegrained is to split the > existing TIF_SPEC_IB into TIF_SPEC_IB_IN and TIF_SPEC_IB_OUT and have > the existing mode both bits set. Agreed. The problem is the existing bit doesn't just control IBPB behaviour. It also controls STIBP, which you can kinda control separately on the command line when booting with the spectre_v2_user flag. The code, however, uses the same flag for both (see arch/x86/include/asm/spec-ctrl.h). Maybe this is another cleanup I should do prior to this change? Separating IBPB and STIBP flags in the implementation. > > Thanks, > > tglx > >