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 ; 23 Feb 2019 07:42:35 -0000 Received: from p5492e0d8.dip0.t-ipconnect.de ([84.146.224.216] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gxRxC-0004HY-91 for speck@linutronix.de; Sat, 23 Feb 2019 08:42:34 +0100 Date: Sat, 23 Feb 2019 08:42:33 +0100 (CET) From: Thomas Gleixner Subject: Re: [patch V4 02/11] x86/speculation/mds: Add basic bug infrastructure for MDS In-Reply-To: Message-ID: References: <20190222222418.405369026@linutronix.de> <20190222224149.264062978@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, 22 Feb 2019, speck for Linus Torvalds wrote: > On Fri, Feb 22, 2019 at 4:04 PM speck for Thomas Gleixner > wrote: > > > > +static const __initconst struct x86_cpu_id cpu_no_mds[] = { > > + /* in addition to cpu_no_speculation */ > > + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_GOLDMONT }, > ... > > That comment was what made me go look: we already have *four* of these > tables in this file, and this is now the fifth. > > And that may be ok. Maybe we do want separate tables for separate > quirks, even if there are patterns there. > > But I at least wanted to bring it up: maybe it would be more legible > to have one table of CPU quirks, and have that table say "this CPU has > / doesn't have this quirk". > > Looking at the existing tables, there's often commonalities. And the > 'struct x86_cpu_id' does have that "driver_data" field that is meant > to be able to describe particular issues, and could contain flags for > "has bug X" or "doesn't have bug Y" quirks > > I dunno. I guess it depends on which way people prefer to thing about > things. Do you want to have a "I wan to see which CPU's have bug X", > or do you want to have a "I want to see what bugs CPU X has". > > Right now it's been driven by "quirk X" having a list of CPU's > associated with that quirk. And maybe that's the right thing to do. > > But looking at those tables, I do wonder if maybe we should have > instead a list of CPU's, and then associate the quirks with the CPU. Good point. Never thought about it. Should be trivial enough to do. Thanks, tglx