svn commit: r328625 - in head/sys: amd64/amd64 amd64/ia32 amd64/include dev/cpuctl i386/i386 x86/include x86/x86

[Steven Hartland]

Pretty sure I’ve seen that too

On Wed, 31 Jan 2018 at 18:05, Rodney W. Grimes <
freebsd at pdx.rh.cn85.dnsmgr.net> wrote:

> > On Wed, Jan 31, 2018 at 02:56:24PM +0000, Bjoern A. Zeeb wrote:
> > > On 31 Jan 2018, at 14:36, Konstantin Belousov wrote:
> > >
> > > > Author: kib
> > > > Date: Wed Jan 31 14:36:27 2018
> > > > New Revision: 328625
> > > > URL: https://svnweb.freebsd.org/changeset/base/328625
> > > >
> > > > Log:
> > > >   IBRS support, AKA Spectre hardware mitigation.
> > >
> > > >   For existing processors, you need a microcode update which adds
> IBRS
> > > >   CPU features, and to manually enable it by setting the
> > > > tunable/sysctl
> > > >   hw.ibrs_disable to 0.  Current status can be checked in sysctl
> > > >   hw.ibrs_active.  The mitigation might be inactive if the CPU
> feature
> > >
> > > Can you change the tunable/sysctl to hw.ibrs_enable[d] (and toggle the
> > > default setting along).
> > This is done consistently with the hw.clflush_disable.
> > Anyway, the intent is that the knob will be used for disabling,
> > since defaults are going to be changed in the near future.
>
> I thought we had something some place that said negative assertions
> should be avoided if possible.
>
> > > I find it highly confusing to have two different sysctls ???disable???
> > > and ???active??? and a lot
> > > of people (and cultures) have trouble with the double negative.
> > > Also the ???enable[d]??? variant seems to be pre-dominant in the
> kernel.
> > >
> > > Also can we spell IBRS in the sysctl description as ???Indirect Branch
> > > Restricted Speculation (IBRS)????
> > Will do in half a hour.
>
>
> --
> Rod Grimes
> rgrimes at freebsd.org
>
>