On Mon, Feb 19, 2018 at 09:29:12AM +, David Woodhouse wrote:
> On Mon, 2018-02-19 at 10:20 +0100, Peter Zijlstra wrote:
> >
> > I did not update or otherwise change packages while I was bisecting; the
> > machine is:
> >
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model
On Mon, 2018-02-19 at 10:39 +0100, Ingo Molnar wrote:
> * David Woodhouse wrote:
>
> >
> > On Mon, 2018-02-19 at 10:20 +0100, Peter Zijlstra wrote:
> > >
> > >
> > > I did not update or otherwise change packages while I was bisecting; the
> > > machine is:
> > >
> > > vendor_id : Genu
* David Woodhouse wrote:
> On Mon, 2018-02-19 at 10:20 +0100, Peter Zijlstra wrote:
> >
> > I did not update or otherwise change packages while I was bisecting; the
> > machine is:
> >
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 62
> > model name : Int
* Peter Zijlstra wrote:
> On Sat, Feb 17, 2018 at 11:26:16AM +0100, Ingo Molnar wrote:
> > Note that PeterZ was struggling with intermittent boot hangs yesterday as
> > well,
> > which hangs came and went during severeal (fruitless) bisection attempts.
> > Then at
> > a certain point the han
On Mon, 2018-02-19 at 10:20 +0100, Peter Zijlstra wrote:
>
> I did not update or otherwise change packages while I was bisecting; the
> machine is:
>
> vendor_id : GenuineIntel
> cpu family : 6
> model : 62
> model name : Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
> stepp
On Sat, Feb 17, 2018 at 11:26:16AM +0100, Ingo Molnar wrote:
> Note that PeterZ was struggling with intermittent boot hangs yesterday as
> well,
> which hangs came and went during severeal (fruitless) bisection attempts.
> Then at
> a certain point the hangs went away altogether.
>
> The sympt
* Tim Chen wrote:
> On 02/16/2018 11:16 AM, David Woodhouse wrote:
> > On Fri, 2018-02-16 at 10:44 -0800, Tim Chen wrote:
> >>
> >> I encountered hang on a machine but not others when using the above
> >> macro. It is probably an alignment thing with ALTERNATIVE as the
> >> problem went
> >> aw
On 02/16/2018 11:16 AM, David Woodhouse wrote:
> On Fri, 2018-02-16 at 10:44 -0800, Tim Chen wrote:
>>
>> I encountered hang on a machine but not others when using the above
>> macro. It is probably an alignment thing with ALTERNATIVE as the
>> problem went
>> away after I made the change below:
>
On Fri, 2018-02-16 at 10:44 -0800, Tim Chen wrote:
>
> I encountered hang on a machine but not others when using the above
> macro. It is probably an alignment thing with ALTERNATIVE as the
> problem went
> away after I made the change below:
>
> Tim
>
> diff --git a/arch/x86/include/asm/nospec
On 02/11/2018 11:19 AM, tip-bot for David Woodhouse wrote:
\
> })
> diff --git a/arch/x86/include/asm/nospec-branch.h
> b/arch/x86/include/asm/nospec-branch.h
> index 300cc15..788c4da 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
On 02/14/2018 03:19 PM, Ingo Molnar wrote:
>
> * Tim Chen wrote:
>
>> On 02/14/2018 12:56 AM, Peter Zijlstra wrote:
>>
>>>
>>> At the very least this must disable and re-enable preemption, such that
>>> we guarantee we inc/dec the same counter. ISTR some firmware calls (EFI)
>>> actually are pre
* Tim Chen wrote:
> On 02/14/2018 12:56 AM, Peter Zijlstra wrote:
>
> >
> > At the very least this must disable and re-enable preemption, such that
> > we guarantee we inc/dec the same counter. ISTR some firmware calls (EFI)
> > actually are preemptible so that wouldn't work.
> >
> > Further,
On 02/14/2018 12:56 AM, Peter Zijlstra wrote:
>
> At the very least this must disable and re-enable preemption, such that
> we guarantee we inc/dec the same counter. ISTR some firmware calls (EFI)
> actually are preemptible so that wouldn't work.
>
> Further, consider:
>
> this_cpu_inc_re
On Wed, Feb 14, 2018 at 09:56:14AM +0100, Peter Zijlstra wrote:
> On Tue, Feb 13, 2018 at 05:49:47PM -0800, Tim Chen wrote:
>
> > static inline void firmware_restrict_branch_speculation_start(void)
> > {
> > + if (this_cpu_inc_return(spec_ctrl_ibrs_fw_depth) == 1)
> > + alternative_m
On Tue, Feb 13, 2018 at 05:49:47PM -0800, Tim Chen wrote:
> static inline void firmware_restrict_branch_speculation_start(void)
> {
> + if (this_cpu_inc_return(spec_ctrl_ibrs_fw_depth) == 1)
> + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
>
On 02/12/2018 11:55 PM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> On Mon, Feb 12, 2018 at 08:13:31AM -0800, Dave Hansen wrote:
>>> On 02/12/2018 02:22 AM, Ingo Molnar wrote:
> +static inline void firmware_restrict_branch_speculation_end(void)
> +{
> + alternative_msr_write(
* David Woodhouse wrote:
> On Mon, 2018-02-12 at 12:50 +0100, Peter Zijlstra wrote:
> > On Mon, Feb 12, 2018 at 11:22:11AM +0100, Ingo Molnar wrote:
> > > > +static inline void firmware_restrict_branch_speculation_start(void)
> > > > +{
> > > > + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_
* Peter Zijlstra wrote:
> On Mon, Feb 12, 2018 at 08:13:31AM -0800, Dave Hansen wrote:
> > On 02/12/2018 02:22 AM, Ingo Molnar wrote:
> > >> +static inline void firmware_restrict_branch_speculation_end(void)
> > >> +{
> > >> +alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
> > >> +
On Mon, Feb 12, 2018 at 08:13:31AM -0800, Dave Hansen wrote:
> On 02/12/2018 02:22 AM, Ingo Molnar wrote:
> >> +static inline void firmware_restrict_branch_speculation_end(void)
> >> +{
> >> + alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
> >> +X86_FEATURE_USE_IBRS_FW);
> >
On Mon, 2018-02-12 at 11:29 +0530, afzal mohammed wrote:
> Hi,
>
> On Sun, Feb 11, 2018 at 11:19:10AM -0800, tip-bot for David Woodhouse wrote:
>
> >
> > x86/speculation: Use IBRS if available before calling into firmware
> >
> > Retpoline means the kernel is safe because it has no indirect b
On 02/12/2018 02:22 AM, Ingo Molnar wrote:
>> +static inline void firmware_restrict_branch_speculation_end(void)
>> +{
>> +alternative_msr_write(MSR_IA32_SPEC_CTRL, 0,
>> + X86_FEATURE_USE_IBRS_FW);
> BTW., there's a detail that only occurred to me today, this
> enabli
On Mon, Feb 12, 2018 at 12:27:19PM +, David Woodhouse wrote:
> On Mon, 2018-02-12 at 12:50 +0100, Peter Zijlstra wrote:
> > Wait, we're doing firmware from NMI? That sounds like a _REALLY_ bad
> > idea.
>
> And spin_lock_irqsave() too. Which is probably why I missed the fact
> that this was b
On Mon, Feb 12, 2018 at 12:50:02PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 12, 2018 at 11:22:11AM +0100, Ingo Molnar wrote:
> > > +static inline void firmware_restrict_branch_speculation_start(void)
> > > +{
> > > + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
> > > +
On Mon, 2018-02-12 at 12:50 +0100, Peter Zijlstra wrote:
> On Mon, Feb 12, 2018 at 11:22:11AM +0100, Ingo Molnar wrote:
> > > +static inline void firmware_restrict_branch_speculation_start(void)
> > > +{
> > > + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
> > > +
On Mon, Feb 12, 2018 at 11:22:11AM +0100, Ingo Molnar wrote:
> > +static inline void firmware_restrict_branch_speculation_start(void)
> > +{
> > + alternative_msr_write(MSR_IA32_SPEC_CTRL, SPEC_CTRL_IBRS,
> > + X86_FEATURE_USE_IBRS_FW);
> > +}
> > +
> > +static inline void
* tip-bot for David Woodhouse wrote:
> Commit-ID: 670c3e8da87fa4046a55077b1409cf250865a203
> Gitweb:
> https://git.kernel.org/tip/670c3e8da87fa4046a55077b1409cf250865a203
> Author: David Woodhouse
> AuthorDate: Sun, 11 Feb 2018 15:19:19 +
> Committer: Ingo Molnar
> CommitDate: S
Hi,
On Sun, Feb 11, 2018 at 11:19:10AM -0800, tip-bot for David Woodhouse wrote:
> x86/speculation: Use IBRS if available before calling into firmware
>
> Retpoline means the kernel is safe because it has no indirect branches.
> But firmware isn't, so use IBRS for firmware calls if it's availabl
27 matches
Mail list logo