From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 05 Mar 2019 18:43:04 -0000 Received: from mx1.redhat.com ([209.132.183.28]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h1F1q-0004tQ-Jt for speck@linutronix.de; Tue, 05 Mar 2019 19:43:03 +0100 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6B37D3082B6B for ; Tue, 5 Mar 2019 18:42:55 +0000 (UTC) Received: from sky.random (ovpn-121-1.rdu2.redhat.com [10.10.121.1]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4A0A0600D7 for ; Tue, 5 Mar 2019 18:42:55 +0000 (UTC) Date: Tue, 5 Mar 2019 13:42:54 -0500 From: Andrea Arcangeli Subject: [MODERATED] Re: [patch V6 10/14] MDS basics 10 Message-ID: <20190305184254.GH31083@redhat.com> References: <20190301214738.281554861@linutronix.de> <20190301214848.075448450@linutronix.de> MIME-Version: 1.0 In-Reply-To: <20190301214848.075448450@linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: Hi Thomas, On Fri, Mar 01, 2019 at 10:47:48PM +0100, speck for Thomas Gleixner wrote: > +/* Update the static key controlling the MDS CPU buffer clear in idle */ > +static void update_mds_branch_idle(void) > +{ > + /* > + * Enable the idle clearing on CPUs which are affected only by > + * MDBDS and not any other MDS variant. The other variants cannot > + * be mitigated when SMT is enabled, so clearing the buffers on > + * idle would be a window dressing exercise. > + */ > + if (!boot_cpu_has(X86_BUG_MSBDS_ONLY)) > + return; > + > + if (sched_smt_active()) > + static_branch_enable(&mds_idle_clear); Do you think it's worth also clearing MSR_MISC_FEATURES_ENABLES_RING3MWAIT_BIT by setting ring3mwait_disabled when sched_smt_active() is true above? I don't expect anybody will pass manually ring3mwait=disable to the kernel on XEON_PHI_KNL/XEON_PHI_KNM. I'm not aware of any app using the user mwait, which also makes this not a big deal.. but it goes both ways, it's also not a big deal for userland to turn it off when we report SMT is enabled and safe in sysfs. Thanks, Andrea