Re: [PATCH] ubi: Reject MLC NAND

On Wed, 2018-03-07 at 14:08 -0800, Steve deRosier wrote: > > To clarify one thing: the reason for this is MLC has actually never > been supported, nor worked properly. The fact that it kinda worked was > incidental and the cause of major problems for people due to that not > being clear. This

Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

On Wed, 2018-02-28 at 17:08 -0600, Bjorn Helgaas wrote: > > What's the bottom line?  Do we want this for sparc?  If so, do you > want to take it, Dave M, or would you like me to? I need to fix it first, and then the intention is for Dave to take it. There'll be a final patch to remove

Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

On Wed, 2018-02-28 at 17:08 -0600, Bjorn Helgaas wrote: > > What's the bottom line?  Do we want this for sparc?  If so, do you > want to take it, Dave M, or would you like me to? I need to fix it first, and then the intention is for Dave to take it. There'll be a final patch to remove

Re: [tip:x86/pti] objtool, retpolines: Integrate objtool with retpoline support more closely

On Wed, 2018-02-21 at 02:34 -0800, tip-bot for Peter Zijlstra wrote: > > --- a/Makefile > +++ b/Makefile > @@ -489,6 +489,11 @@ KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) >  KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) >  endif >   > +ifneq ($(call

Re: [tip:x86/pti] objtool, retpolines: Integrate objtool with retpoline support more closely

On Wed, 2018-02-21 at 02:34 -0800, tip-bot for Peter Zijlstra wrote: > > --- a/Makefile > +++ b/Makefile > @@ -489,6 +489,11 @@ KBUILD_CFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) >  KBUILD_AFLAGS += $(CLANG_TARGET) $(CLANG_GCC_TC) >  endif >   > +ifneq ($(call

Re: [PATCH v3 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-20 at 11:42 +0100, Thomas Gleixner wrote: > > > > However, Paolo is very insistent that taking the trap every time is > > > actually a lot *slower* than really frobbing IBRS on certain > > > microarchitectures, so my hand-waving "pfft, what did they expect?" is > > > not

Re: [PATCH v3 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-20 at 11:42 +0100, Thomas Gleixner wrote: > > > > However, Paolo is very insistent that taking the trap every time is > > > actually a lot *slower* than really frobbing IBRS on certain > > > microarchitectures, so my hand-waving "pfft, what did they expect?" is > > > not

[tip:x86/pti] x86/retpoline: Support retpoline builds with Clang

Commit-ID: 87358710c1fb4f1bf96bbe2349975ff9953fc9b2 Gitweb: https://git.kernel.org/tip/87358710c1fb4f1bf96bbe2349975ff9953fc9b2 Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Mon, 19 Feb 2018 10:50:57 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

[tip:x86/pti] x86/retpoline: Support retpoline builds with Clang

Commit-ID: 87358710c1fb4f1bf96bbe2349975ff9953fc9b2 Gitweb: https://git.kernel.org/tip/87358710c1fb4f1bf96bbe2349975ff9953fc9b2 Author: David Woodhouse AuthorDate: Mon, 19 Feb 2018 10:50:57 + Committer: Ingo Molnar CommitDate: Tue, 20 Feb 2018 11:17:58 +0100 x86/retpoline: Support

[tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

Commit-ID: dd84441a797150dcc49298ec95c459a8891d8bb1 Gitweb: https://git.kernel.org/tip/dd84441a797150dcc49298ec95c459a8891d8bb1 Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Mon, 19 Feb 2018 10:50:54 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

[tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

Commit-ID: dd84441a797150dcc49298ec95c459a8891d8bb1 Gitweb: https://git.kernel.org/tip/dd84441a797150dcc49298ec95c459a8891d8bb1 Author: David Woodhouse AuthorDate: Mon, 19 Feb 2018 10:50:54 + Committer: Ingo Molnar CommitDate: Tue, 20 Feb 2018 09:38:33 +0100 x86/speculation: Use

[tip:x86/pti] Revert "x86/retpoline: Simplify vmexit_fill_RSB()"

Commit-ID: d1c99108af3c5992640aa2afa7d2e88c3775c06e Gitweb: https://git.kernel.org/tip/d1c99108af3c5992640aa2afa7d2e88c3775c06e Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Mon, 19 Feb 2018 10:50:56 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

[tip:x86/pti] Revert "x86/retpoline: Simplify vmexit_fill_RSB()"

Commit-ID: d1c99108af3c5992640aa2afa7d2e88c3775c06e Gitweb: https://git.kernel.org/tip/d1c99108af3c5992640aa2afa7d2e88c3775c06e Author: David Woodhouse AuthorDate: Mon, 19 Feb 2018 10:50:56 + Committer: Ingo Molnar CommitDate: Tue, 20 Feb 2018 09:38:26 +0100 Revert "x86/retp

Re: [PATCH v3 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-20 at 09:31 +0100, Thomas Gleixner wrote: > > @@ -237,6 +239,16 @@ static void __init spectre_v2_select_mitigation(void) > >   > >   case SPECTRE_V2_CMD_FORCE: > >   case SPECTRE_V2_CMD_AUTO: > > + if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) { > > +

Re: [PATCH v3 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-20 at 09:31 +0100, Thomas Gleixner wrote: > > @@ -237,6 +239,16 @@ static void __init spectre_v2_select_mitigation(void) > >   > >   case SPECTRE_V2_CMD_FORCE: > >   case SPECTRE_V2_CMD_AUTO: > > + if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES)) { > > +

Re: [PATCH v3 4/4] x86/retpoline: Support retpoline build with Clang

On Tue, 2018-02-20 at 09:36 +0100, Thomas Gleixner wrote: > On Mon, 19 Feb 2018, David Woodhouse wrote: > > Reviewed-by: Thomas Gleixner <t...@linutronix.de> > > > > > +/* Clang doesn't have a way to turn it off per-function, yet. */ > > Is that going to

Re: [PATCH v3 4/4] x86/retpoline: Support retpoline build with Clang

On Tue, 2018-02-20 at 09:36 +0100, Thomas Gleixner wrote: > On Mon, 19 Feb 2018, David Woodhouse wrote: > > Reviewed-by: Thomas Gleixner > > > > > +/* Clang doesn't have a way to turn it off per-function, yet. */ > > Is that going to happen in the foreseabl

Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

On Mon, 2018-02-19 at 09:49 -0500, David Miller wrote: > From: David Woodhouse <d...@amazon.co.uk> > Date: Mon, 19 Feb 2018 13:04:12 + > > > > > Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for > > ARM64") added thi

Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

On Mon, 2018-02-19 at 09:49 -0500, David Miller wrote: > From: David Woodhouse > Date: Mon, 19 Feb 2018 13:04:12 + > > > > > Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for > > ARM64") added this generic function with

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

On Mon, 2018-02-19 at 14:10 +0100, Paolo Bonzini wrote: > > Hardware seems like a reasonable place to get the default value (cf. > > the VMX capability MSRs). > > There are some differences: > > - a zero value for ARCH_CAPABILITIES should be safe, while a zero value > for VMX capabilities

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

On Mon, 2018-02-19 at 14:10 +0100, Paolo Bonzini wrote: > > Hardware seems like a reasonable place to get the default value (cf. > > the VMX capability MSRs). > > There are some differences: > > - a zero value for ARCH_CAPABILITIES should be safe, while a zero value > for VMX capabilities

[PATCH] sparc: Use generic pci_mmap_resource_range()

Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Let's get on with that eradication... Signed-off-by: David Woodhouse <d...

[PATCH] sparc: Use generic pci_mmap_resource_range()

Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Let's get on with that eradication... Signed-off-by: David Woodhouse ---

[PATCH] xtensa: Use generic pci_mmap_resource_range()

Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Let's get on with that eradication... Signed-off-by: David Woodhouse <d...

[PATCH] xtensa: Use generic pci_mmap_resource_range()

Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Let's get on with that eradication... Signed-off-by: David Woodhouse --- a

[PATCH] microblaze: Use generic pci_mmap_resource_range()

Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Let's get on with that eradication... Signed-off-by: David Woodhouse <d...

[PATCH] microblaze: Use generic pci_mmap_resource_range()

Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Let's get on with that eradication... Signed-off-by: David Woodhouse

[PATCH] powerpc: Use generic pci_mmap_resource_range()

Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Let's get on with that eradication... Signed-off-by: David Woodhouse <d...

[PATCH] powerpc: Use generic pci_mmap_resource_range()

Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for ARM64") added this generic function with the intent of using it everywhere and ultimately killing the old arch-specific implementations. Let's get on with that eradication... Signed-off-by: David Woodhouse --- ar

[PATCH v3 0/4] Speculation control improvements

support for retpoline builds with clang. --- v2: Remember to export spectre_v2_enabled v3: No changes; just rebase to current tip/x86/pti and clarify the state of the discussion about SPEC_CTRL trapping for IBRS_ALL. David Woodhouse (4): x86/speculation: Use IBRS if available before calling

[PATCH v3 0/4] Speculation control improvements

support for retpoline builds with clang. --- v2: Remember to export spectre_v2_enabled v3: No changes; just rebase to current tip/x86/pti and clarify the state of the discussion about SPEC_CTRL trapping for IBRS_ALL. David Woodhouse (4): x86/speculation: Use IBRS if available before calling

[PATCH v3 4/4] x86/retpoline: Support retpoline build with Clang

Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/Makefile | 5 - include/linux/compiler-clang.h | 5 + include/linux/compiler-gcc.h | 4 include/linux/init.h | 8 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/ar

[PATCH v3 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

ably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse <d...@amazon.co.uk> Acked-by: Arjan van de Ven <arjan.van.de@intel.com> --- arch/x86/include/asm/nospec-branch.h | 9 - arch/x86/kernel/cpu/bugs.c | 17 +

[PATCH v3 4/4] x86/retpoline: Support retpoline build with Clang

Signed-off-by: David Woodhouse --- arch/x86/Makefile | 5 - include/linux/compiler-clang.h | 5 + include/linux/compiler-gcc.h | 4 include/linux/init.h | 8 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/arch/x86/Makefile b/arch

[PATCH v3 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

ably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse Acked-by: Arjan van de Ven --- arch/x86/include/asm/nospec-branch.h | 9 - arch/x86/kernel/cpu/bugs.c | 17 +++-- arch/x86/kvm/vmx.c

[PATCH v3 1/4] x86/speculation: Use IBRS if available before calling into firmware

and calling into firmware code, from an NMI handler. I don't want to touch that with a bargepole. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/efi.h

[PATCH v3 3/4] Revert "x86/retpoline: Simplify vmexit_fill_RSB()"

. It also changed the number of RSB stuffings we do on vmexit from 32, which was correct, to 16. Let's just stop with the bikeshedding; it didn't actually *fix* anything anyway. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/entry/entry_32.S | 3 +- arch/x86

[PATCH v3 1/4] x86/speculation: Use IBRS if available before calling into firmware

and calling into firmware code, from an NMI handler. I don't want to touch that with a bargepole. Signed-off-by: David Woodhouse --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/efi.h | 17 ++-- arch/x86

[PATCH v3 3/4] Revert "x86/retpoline: Simplify vmexit_fill_RSB()"

. It also changed the number of RSB stuffings we do on vmexit from 32, which was correct, to 16. Let's just stop with the bikeshedding; it didn't actually *fix* anything anyway. Signed-off-by: David Woodhouse --- arch/x86/entry/entry_32.S | 3 +- arch/x86/entry/entry_64.S

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

On Mon, 2018-02-19 at 10:39 +0100, Ingo Molnar wrote: > * David Woodhouse <dw...@infradead.org> wrote: > > > > > On Mon, 2018-02-19 at 10:20 +0100, Peter Zijlstra wrote: > > > > > > > > > I did not update or otherwise chang

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

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;

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

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 >

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

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 >

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

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

Re: [tip:x86/pti] x86/speculation: Use IBRS if available before calling into firmware

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

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

On Fri, 2018-02-16 at 08:29 -0800, Jim Mattson wrote: > On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote: > > > Uhm, taking contents from the hardware is wrong (guess why---live > > migration).  I'll send a revert of those two lines. > > Hardware seems like a

Re: [PATCH 7/9] KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES

On Fri, 2018-02-16 at 08:29 -0800, Jim Mattson wrote: > On Fri, Feb 16, 2018 at 6:18 AM, Paolo Bonzini wrote: > > > Uhm, taking contents from the hardware is wrong (guess why---live > > migration).  I'll send a revert of those two lines. > > Hardware seems like a reasonable place to get the

Re: [PATCH] drm: fix off-by-one in logger

On Fri, 2018-02-16 at 10:43 +0100, Norbert Manthey wrote: > The current implementation will leak a byte to the log via memmove. The > specified 27 bytes are off-by-one, as the payload is 25 bytes, and the > termination character is only one byte large. To avoid this, factor out > the error

Re: [PATCH] drm: fix off-by-one in logger

On Fri, 2018-02-16 at 10:43 +0100, Norbert Manthey wrote: > The current implementation will leak a byte to the log via memmove. The > specified 27 bytes are off-by-one, as the payload is 25 bytes, and the > termination character is only one byte large. To avoid this, factor out > the error

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Fri, 2018-02-16 at 12:04 +0100, Paolo Bonzini wrote: > On 16/02/2018 11:21, David Woodhouse wrote: > > > > Why? With IBRS_ALL the guest *never* gets to affect the actual hardware > > MSR, which is always on. The MSR is purely an emulated no-op. Why does > > that

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Fri, 2018-02-16 at 12:04 +0100, Paolo Bonzini wrote: > On 16/02/2018 11:21, David Woodhouse wrote: > > > > Why? With IBRS_ALL the guest *never* gets to affect the actual hardware > > MSR, which is always on. The MSR is purely an emulated no-op. Why does > > that

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Fri, 2018-02-16 at 11:08 +0100, Paolo Bonzini wrote: > On 16/02/2018 10:58, David Woodhouse wrote: > > > > On Tue, 2018-02-13 at 11:41 +0100, Paolo Bonzini wrote: > > > > > > > > On 13/02/2018 11:36, David Woodhouse wrote: > > > >

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Fri, 2018-02-16 at 11:08 +0100, Paolo Bonzini wrote: > On 16/02/2018 10:58, David Woodhouse wrote: > > > > On Tue, 2018-02-13 at 11:41 +0100, Paolo Bonzini wrote: > > > > > > > > On 13/02/2018 11:36, David Woodhouse wrote: > > > >

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 11:41 +0100, Paolo Bonzini wrote: > On 13/02/2018 11:36, David Woodhouse wrote: > > > > - if the VM has IBRS_ALL, pass through the MSR when it is zero and > > > > intercept writes when it is one (no writes should happen) > > > >   &g

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 11:41 +0100, Paolo Bonzini wrote: > On 13/02/2018 11:36, David Woodhouse wrote: > > > > - if the VM has IBRS_ALL, pass through the MSR when it is zero and > > > > intercept writes when it is one (no writes should happen) > > > >   &g

Re: Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()" crashes KVM guest

On Fri, 2018-02-16 at 00:12 +0100, Richard Weinberger wrote: > > [    2.791518] Code: 8b 45 00 49 8b 7d 08 49 83 c5 18 31 d2 31 f6 ff > d0 49 8b 45 00 48 85 c0 75 e9 eb b1 b9 49 00 00 00 b8 01 00 00 00 ba > 00 00 00 00 <0f> 30 e9 68 fd ff ff 9c 58 0f 1f 44 00 00 48 89 c5 fa > 66 0f 1f   23:   b9

Re: Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()" crashes KVM guest

On Fri, 2018-02-16 at 00:12 +0100, Richard Weinberger wrote: > > [    2.791518] Code: 8b 45 00 49 8b 7d 08 49 83 c5 18 31 d2 31 f6 ff > d0 49 8b 45 00 48 85 c0 75 e9 eb b1 b9 49 00 00 00 b8 01 00 00 00 ba > 00 00 00 00 <0f> 30 e9 68 fd ff ff 9c 58 0f 1f 44 00 00 48 89 c5 fa > 66 0f 1f   23:   b9

Re: [PATCH v2 1/4] x86/speculation: Use IBRS if available before calling into firmware

On Wed, 2018-02-14 at 16:46 -0800, Jim Mattson wrote: > On Wed, Feb 14, 2018 at 3:29 PM, David Woodhouse <d...@amazon.co.uk> wrote: > > > +#define alternative_msr_write(_msr, _val, _feature)    \ > > +  

Re: [PATCH v2 1/4] x86/speculation: Use IBRS if available before calling into firmware

On Wed, 2018-02-14 at 16:46 -0800, Jim Mattson wrote: > On Wed, Feb 14, 2018 at 3:29 PM, David Woodhouse wrote: > > > +#define alternative_msr_write(_msr, _val, _feature)    \ > > +   asm volatile(ALTERNATIVE("",    \ > > +   

[PATCH v2 3/4] Revert "x86/retpoline: Simplify vmexit_fill_RSB()"

. It also changed the number of RSB stuffings we do on vmexit from 32, which was correct, to 16. Let's just stop with the bikeshedding; it didn't actually *fix* anything anyway. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/entry/entry_32.S | 3 +- arch/x86

[PATCH v2 3/4] Revert "x86/retpoline: Simplify vmexit_fill_RSB()"

. It also changed the number of RSB stuffings we do on vmexit from 32, which was correct, to 16. Let's just stop with the bikeshedding; it didn't actually *fix* anything anyway. Signed-off-by: David Woodhouse --- arch/x86/entry/entry_32.S | 3 +- arch/x86/entry/entry_64.S

[PATCH v2 1/4] x86/speculation: Use IBRS if available before calling into firmware

and calling into firmware code, from an NMI handler. I don't want to touch that with a bargepole. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/efi.h

[PATCH v2 1/4] x86/speculation: Use IBRS if available before calling into firmware

and calling into firmware code, from an NMI handler. I don't want to touch that with a bargepole. Signed-off-by: David Woodhouse --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/efi.h | 17 ++-- arch/x86

[PATCH v2 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

ably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse <d...@amazon.co.uk> Acked-by: Arjan van de Ven <arjan.van.de@intel.com> --- arch/x86/include/asm/nospec-branch.h | 9 - arch/x86/kernel/cpu/bugs.c | 17 +

[PATCH v2 4/4] x86/retpoline: Support retpoline build with Clang

Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/Makefile | 5 - include/linux/compiler-clang.h | 5 + include/linux/compiler-gcc.h | 4 include/linux/init.h | 8 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/ar

[PATCH v2 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

ably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse Acked-by: Arjan van de Ven --- arch/x86/include/asm/nospec-branch.h | 9 - arch/x86/kernel/cpu/bugs.c | 17 +++-- arch/x86/kvm/vmx.c

[PATCH v2 4/4] x86/retpoline: Support retpoline build with Clang

Signed-off-by: David Woodhouse --- arch/x86/Makefile | 5 - include/linux/compiler-clang.h | 5 + include/linux/compiler-gcc.h | 4 include/linux/init.h | 8 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/arch/x86/Makefile b/arch

[PATCH v2 0/4] Speculation control improvements

to export spectre_v2_enabled David Woodhouse (4): x86/speculation: Use IBRS if available before calling into firmware x86/speculation: Support "Enhanced IBRS" on future CPUs Revert "x86/retpoline: Simplify vmexit_fill_RSB()" x86/retpoline: Support retpoline build w

[PATCH v2 0/4] Speculation control improvements

to export spectre_v2_enabled David Woodhouse (4): x86/speculation: Use IBRS if available before calling into firmware x86/speculation: Support "Enhanced IBRS" on future CPUs Revert "x86/retpoline: Simplify vmexit_fill_RSB()" x86/retpoline: Support retpoline build w

Re: [PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware

On Wed, 2018-02-14 at 10:36 -0600, Tom Lendacky wrote: > On 2/14/2018 10:11 AM, David Woodhouse wrote: > > > > > > > > On Wed, 2018-02-14 at 10:07 -0600, Tom Lendacky wrote: > > > > > > Shouldn't these writes to the MSR be just for the IBRS bi

Re: [PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware

On Wed, 2018-02-14 at 10:36 -0600, Tom Lendacky wrote: > On 2/14/2018 10:11 AM, David Woodhouse wrote: > > > > > > > > On Wed, 2018-02-14 at 10:07 -0600, Tom Lendacky wrote: > > > > > > Shouldn't these writes to the MSR be just for the IBRS bi

Re: [PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware

On Wed, 2018-02-14 at 10:07 -0600, Tom Lendacky wrote: > Shouldn't these writes to the MSR be just for the IBRS bit?  The spec > also defines the STIBP bit for this MSR, and if that bit had been set by > BIOS for example, these writes will clear it.  And who knows what future > bits may be

Re: [PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware

On Wed, 2018-02-14 at 10:07 -0600, Tom Lendacky wrote: > Shouldn't these writes to the MSR be just for the IBRS bit?  The spec > also defines the STIBP bit for this MSR, and if that bit had been set by > BIOS for example, these writes will clear it.  And who knows what future > bits may be

[PATCH 3/4] Revert "x86/retpoline: Simplify vmexit_fill_RSB()"

. It also changed the number of RSB stuffings we do on vmexit from 32, which was correct, to 16. Let's just stop with the bikeshedding; it didn't actually *fix* anything anyway. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/entry/entry_32.S | 3 +- arch/x86

[PATCH 3/4] Revert "x86/retpoline: Simplify vmexit_fill_RSB()"

. It also changed the number of RSB stuffings we do on vmexit from 32, which was correct, to 16. Let's just stop with the bikeshedding; it didn't actually *fix* anything anyway. Signed-off-by: David Woodhouse --- arch/x86/entry/entry_32.S | 3 +- arch/x86/entry/entry_64.S

[PATCH 4/4] x86/retpoline: Support retpoline build with Clang

Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/Makefile | 5 - include/linux/compiler-clang.h | 5 + include/linux/compiler-gcc.h | 4 include/linux/init.h | 8 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/ar

[PATCH 4/4] x86/retpoline: Support retpoline build with Clang

Signed-off-by: David Woodhouse --- arch/x86/Makefile | 5 - include/linux/compiler-clang.h | 5 + include/linux/compiler-gcc.h | 4 include/linux/init.h | 8 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/arch/x86/Makefile b/arch

[PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware

and calling into firmware code, from an NMI handler. I don't want to touch that with a bargepole. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/efi.h

[PATCH 1/4] x86/speculation: Use IBRS if available before calling into firmware

and calling into firmware code, from an NMI handler. I don't want to touch that with a bargepole. Signed-off-by: David Woodhouse --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/efi.h | 17 ++-- arch/x86

[PATCH 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

ably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse <d...@amazon.co.uk> Acked-by: Arjan van de Ven <arjan.van.de@intel.com> --- arch/x86/include/asm/nospec-branch.h | 9 - arch/x86/kernel/cpu/bugs.c | 16

[PATCH 2/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

ably going to be faster than they were expecting anyway, so they'll live. Signed-off-by: David Woodhouse Acked-by: Arjan van de Ven --- arch/x86/include/asm/nospec-branch.h | 9 - arch/x86/kernel/cpu/bugs.c | 16 ++-- arch/x86/kvm/vmx.c

[PATCH 0/4] Speculation control improvements

builds with clang now that clang is fixed. David Woodhouse (4): x86/speculation: Use IBRS if available before calling into firmware x86/speculation: Support "Enhanced IBRS" on future CPUs Revert "x86/retpoline: Simplify vmexit_fill_RSB()" x86/retpoline: Support retpol

[PATCH 0/4] Speculation control improvements

builds with clang now that clang is fixed. David Woodhouse (4): x86/speculation: Use IBRS if available before calling into firmware x86/speculation: Support "Enhanced IBRS" on future CPUs Revert "x86/retpoline: Simplify vmexit_fill_RSB()" x86/retpoline: Support retpol

Re: [PATCH v2] x86/retpoline: Add clang support

On Tue, 2018-02-13 at 18:18 -0800, Guenter Roeck wrote: > > > We're going to need the percpu.h fix too, and I'd also like to see the > > status of the i915 build failure you mentioned. Is there a bug filed > > for that already, and is it on the blocker list for 6.0? If not, why > > not? > >  >

Re: [PATCH v2] x86/retpoline: Add clang support

On Tue, 2018-02-13 at 18:18 -0800, Guenter Roeck wrote: > > > We're going to need the percpu.h fix too, and I'd also like to see the > > status of the i915 build failure you mentioned. Is there a bug filed > > for that already, and is it on the blocker list for 6.0? If not, why > > not? > >  >

Re: [PATCH v2] x86/retpoline: Add clang support

On Tue, 2018-02-13 at 15:41 -0800, Guenter Roeck wrote: > Hi David, > > On Wed, Feb 07, 2018 at 03:32:11PM -0800, Guenter Roeck wrote: > [ ... ] > > >  > > > See > > > http://git.infradead.org/users/dwmw2/linux-retpoline.git/commitdiff/82a1f41600 > > Any chance to see a patch with this change

Re: [PATCH v2] x86/retpoline: Add clang support

On Tue, 2018-02-13 at 15:41 -0800, Guenter Roeck wrote: > Hi David, > > On Wed, Feb 07, 2018 at 03:32:11PM -0800, Guenter Roeck wrote: > [ ... ] > > >  > > > See > > > http://git.infradead.org/users/dwmw2/linux-retpoline.git/commitdiff/82a1f41600 > > Any chance to see a patch with this change

Re: [PATCH 2/2] x86/retpoline: Fix return buffer filling

On Mon, 2018-02-12 at 16:04 -0800, Andi Kleen wrote: > From: Andi Kleen > > An earlier patch moved the RSB filling out of line, ending > it with a return. This results in the return buffer filling > only giving 15 instead of 16 usable returns because > the return from

Re: [PATCH 2/2] x86/retpoline: Fix return buffer filling

On Mon, 2018-02-12 at 16:04 -0800, Andi Kleen wrote: > From: Andi Kleen > > An earlier patch moved the RSB filling out of line, ending > it with a return. This results in the return buffer filling > only giving 15 instead of 16 usable returns because > the return from fill_rsb already uses one

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 11:41 +0100, Paolo Bonzini wrote: > You have my vote. :)  Really, IBRS_ALL makes no sense and it would be > nice to know _why_ Intel is pushing something that makes no sense. No, IBRS_ALL *does* make sense. It's not a complete fix, but it's as much of a fix as they should

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 11:41 +0100, Paolo Bonzini wrote: > You have my vote. :)  Really, IBRS_ALL makes no sense and it would be > nice to know _why_ Intel is pushing something that makes no sense. No, IBRS_ALL *does* make sense. It's not a complete fix, but it's as much of a fix as they should

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 10:21 +, David Woodhouse wrote: > > > So the right logic is: > >  > > - if the VM has IBRS_ALL, pass through the MSR when it is zero and > > intercept writes when it is one (no writes should happen) > >  > > - if the VM doesn'

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 10:21 +, David Woodhouse wrote: > > > So the right logic is: > >  > > - if the VM has IBRS_ALL, pass through the MSR when it is zero and > > intercept writes when it is one (no writes should happen) > >  > > - if the VM doesn'

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 10:58 +0100, Paolo Bonzini wrote: > > If spectre_v2_ibrs_all() is true then KVM should *never* actually pass > > through or touch the real MSR. > > That would be nice but unfortunately it's not possible. :( > > The VM might actually not have IBRS_ALL, as usual the reason

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On Tue, 2018-02-13 at 10:58 +0100, Paolo Bonzini wrote: > > If spectre_v2_ibrs_all() is true then KVM should *never* actually pass > > through or touch the real MSR. > > That would be nice but unfortunately it's not possible. :( > > The VM might actually not have IBRS_ALL, as usual the reason

[tip:x86/pti] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

Commit-ID: f208820a321f9b23d77d7eed89945d862d62a3ed Gitweb: https://git.kernel.org/tip/f208820a321f9b23d77d7eed89945d862d62a3ed Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Sat, 10 Feb 2018 23:39:23 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

[tip:x86/pti] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

Commit-ID: f208820a321f9b23d77d7eed89945d862d62a3ed Gitweb: https://git.kernel.org/tip/f208820a321f9b23d77d7eed89945d862d62a3ed Author: David Woodhouse AuthorDate: Sat, 10 Feb 2018 23:39:23 + Committer: Ingo Molnar CommitDate: Tue, 13 Feb 2018 08:59:00 +0100 Revert &quo

[tip:x86/pti] KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods

Commit-ID: 928a4c39484281f8ca366f53a1db79330d058401 Gitweb: https://git.kernel.org/tip/928a4c39484281f8ca366f53a1db79330d058401 Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Sat, 10 Feb 2018 23:39:24 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

[tip:x86/pti] KVM/x86: Reduce retpoline performance impact in slot_handle_level_range(), by always inlining iterator helper methods

Commit-ID: 928a4c39484281f8ca366f53a1db79330d058401 Gitweb: https://git.kernel.org/tip/928a4c39484281f8ca366f53a1db79330d058401 Author: David Woodhouse AuthorDate: Sat, 10 Feb 2018 23:39:24 + Committer: Ingo Molnar CommitDate: Tue, 13 Feb 2018 08:59:45 +0100 KVM/x86: Reduce

[tip:x86/pti] x86/speculation: Correct Speculation Control microcode blacklist again

Commit-ID: d37fc6d360a404b208547ba112e7dabb6533c7fc Gitweb: https://git.kernel.org/tip/d37fc6d360a404b208547ba112e7dabb6533c7fc Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Mon, 12 Feb 2018 15:27:34 + Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Tue,

<    1   2   3   4   5   6   7   8   9   10   >