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 ; 26 Feb 2020 22:13:59 -0000 Received: from mga12.intel.com ([192.55.52.136]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j74wI-0007Oo-8Y for speck@linutronix.de; Wed, 26 Feb 2020 23:13:58 +0100 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id A62116361 for ; Wed, 26 Feb 2020 22:13:54 +0000 (UTC) Date: Wed, 26 Feb 2020 14:13:55 -0800 From: mark gross Subject: [MODERATED] Re: [PATCH v2 1/2] v2: more sampling fun 1 Message-ID: <20200226221355.GC116192@mtg-dev.jf.intel.com> Reply-To: mgross@linux.intel.com References: <20200226110737.GB17448@zn.tnic> <20200226171103.GA114268@mtg-dev.jf.intel.com> <20200226175950.GD17448@zn.tnic> <87h7zdi58e.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 In-Reply-To: <87h7zdi58e.fsf@nanos.tec.linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Feb 26, 2020 at 07:16:33PM +0100, speck for Thomas Gleixner wrote: > speck for Borislav Petkov writes: > > On Wed, Feb 26, 2020 at 09:11:03AM -0800, speck for mark gross wrote: > >> Yeah, Andi pointed it out to me on an internal review. I don't know what tool > >> is using it. > > > > Then how do you write a patch and state in the commit message that > > something is an ABI without knowing what the situation actually is?! > > > >> FWIW doing it this way made a cleaner patch without touching a dozen other > >> files using that structure. I'd rather stay with the way it is but, if you > >> feel strongly I can do a version of what I had before only adding the new > >> members to the end. Please let me know. > > > > Looking at that table again - cpu_vuln_whitelist - that is a > > *whitelist*. See how all the bits start with "NO_"? Except maybe > > MSBDS_ONLY. > > Well, that was a decision to not have NO_MSDALL and NO_MDSSOMETHING as > it made some of logic in the code simpler. > > > What you're doing is, you're misusing it to match models and steppings > > to set SRBDS* bug flags. > > > > What you should actually be doing is setting those bug flags in > > early_init_intel() where you can go wild with the steppings checking and > > then you won't need to touch x86_cpu_id at all. > > Either that or add a new cpu_vuln_shitlist beside the whitelist and > stick the new stuff into that. It kinda makes sense to keep all this > vulnerability nonsense in one place. I'm ok with either way. is there a consensus for making annother cpu_vuln_list? --mark