[MODERATED] Re: [PATCH v2 1/2] v2: more sampling fun 1

[mark gross <mgross@linux.intel.com>]

On Wed, Feb 26, 2020 at 07:16:33PM +0100, speck for Thomas Gleixner wrote:
> speck for Borislav Petkov <speck@linutronix.de> 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