RE: [PATCH V2] x86/speculation: Support Enhanced IBRS on future CPUs

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, 31 Jul 2018, Prakhya, Sai Praneeth wrote:

> > The feature strings are automatically generated from the define. The comment
> > can be used to supress them by an empty "" string or to modify them by a
> > "override" string at the beginning of the comment.
> 
> I overlooked "override" part. Sorry! about that.

Nothing to be sorry about. I just knew it because I stumbled over it my
self quite some time ago.

> > > > > +	/* Ensure SPEC_CTRL_IBRS is set after VMEXIT from a guest */
> > > > > +	x86_spec_ctrl_base |= SPEC_CTRL_IBRS;
> > > >
> > > > And what exactly writes the MSR?
> > > >
> > >
> > > While booting, x86_spec_ctrl_setup_ap() does that and after VMEXIT
> > > x86_spec_ctrl_restore_host().
> > >
> > > As x86_spec_ctrl_setup_ap() does wrmsrl(MSR_IA32_SPEC_CTRL,
> > > x86_spec_ctrl_base), I thought writing here would be redundant.
> > 
> > x86_spec_ctrl_setup_ap() is only called on the AP but not on the BP. So the boot
> > processor will not have it set, unless something else writes the MSR. So you
> > really want to have an explicit write there.
> 
> Yes, that makes sense.
> But on the machine, I see IBRS bit set on all cores. As you said, someone else might 
> be writing the MSR. I will try to find that out and will update the patch accordingly.
> 
> I initially suspected it to be __ssb_select_mitigation() as I have 
> "spec_store_bypass_disable=on" in the kernel command line, but turns out it's not so.
> I will update you more on this.

There are lots of places like the firmware mitigation stuff and other
things which write that MSR. And because the bit is set in
x86_spec_ctrl_base it will be on at some point and stay so.

Writing it explicitely at the point where it is set makes it independent of
other mechanisms which touch that MSR and Just Works.

Thanks,

	tglx