On Wed, Jan 10, 2018 at 06:59:54AM -0800, Dave Hansen wrote: > On 01/10/2018 06:10 AM, Andrea Arcangeli wrote: > > Tim and Dave please comment too, Tim you originally wrote that code > > that leaves IBRS always on and never toggles it in the kernel entry > > point so you must know full well if Arjan is correct that you must > > toggle IBRS every time you enter kernel and in turn ibrs_enabled 2 > > isn't valid mode. > > Hi Andrea, > > The "writing IBRS=1 acts as a barrier when it is already IBRS=1" > behavior is something which I misunderstood in the past. Thanks, Arjan, > for clearing it up.
"writing IBRS=1 acts as a barrier when it is already IBRS=1" would have been much clearer wording frankly. IBPB is IBP "Barrier", but also IBRS is a barrier, no problem :). So we'll add a dummy IBRS write to SPEC_CTRL in kernel entry and vmexit so that it is compliant with all released microcodes that may require it, also when ibrs_enabled is 2. Can you confirm? Can you also tell if IBRS must be written as a barrier to SPEC_CTRL in return to userland (kernel exit) when ibrs_enabled 2? Generally we wouldn't run a barrier there with ibrs_enabled 2, but absolutely nothing is intuitive here so I need to ask explicitly.
