From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 15 Apr 2020 22:21:52 -0000 Received: from mga17.intel.com ([192.55.52.151]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jOqPl-0002hU-Ch for speck@linutronix.de; Thu, 16 Apr 2020 00:21:50 +0200 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id 202AE6363 for ; Wed, 15 Apr 2020 22:21:44 +0000 (UTC) Date: Wed, 15 Apr 2020 15:21:44 -0700 From: mark gross Subject: [MODERATED] Re: [PATCH 3/4] V7 more sampling fun 3 Message-ID: <20200415222144.GB100223@mtg-dev.jf.intel.com> Reply-To: mgross@linux.intel.com References: <20200414200544.zqhguchba3m2jhr6@treble> <20200414215924.GE29751@mtg-dev.jf.intel.com> <873694oqgv.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 In-Reply-To: <873694oqgv.fsf@nanos.tec.linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Apr 15, 2020 at 02:58:40PM +0200, speck for Thomas Gleixner wrote: > Mark, > > speck for mark gross writes: > > On Tue, Apr 14, 2020 at 03:05:44PM -0500, speck for Josh Poimboeuf wrote: > >> On Thu, Jan 16, 2020 at 02:16:07PM -0800, speck for mark gross wrote: > >> > +static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { > >> > + VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0, 0xA), SRBDS), > >> > + VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0xB, 0xC), SRBDS_IF_TSX), > >> > + VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0, 0xB), SRBDS), > >> > + VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0xC, 0xD), SRBDS_IF_TSX), > >> > >> Another readability tweak: "0x0" helps with vertical alignment: > >> > >> VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0x0, 0xA), SRBDS), > >> VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0xB, 0xC), SRBDS_IF_TSX), > >> VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0x0, 0xB), SRBDS), > >> VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0xC, 0xD), SRBDS_IF_TSX), > > > > FWIW the white paper no longer calls out individual steppings as vulnerable > > only if TSX so I'm losing the SRBDS_IF_TSX stuff. > > So we lose the complete TSX conditionals or do they now apply to all > NO_MDS CPUs? we apply the TSX test to all MDS_NO CPU's. FWIW I greatly appreciate your efforts in cleaning up the x86 macros that we needed in earlier versions of the white paper. The white paper splits out different steppings to differentiate older parts that were affected by MDS from the newer versions that had MDS_NO (and so had the option of mitigating SRBDS by turning off TSX). But, recently it changed such that stepping isn't needed to determine vulnerability. Depending on how people want to list things we can split out the MDS_NO CPU's or collapse them and not depend on the stepping. i.e. use X86_STEPPINGS_ALL or just use the legacy interfaces that don't know about stepping. Which is what I'm planning to do as it will make back porting easier. sorry, --mark