[PATCH 1/9] KVM: nVMX: vmx_complete_nested_posted_interrupt() can't fail

From: David Hildenbrand vmx_complete_nested_posted_interrupt() can't fail, let's turn it into a void function. Signed-off-by: David Hildenbrand Signed-off-by: Paolo Bonzini (cherry picked from commit 6342c50ad12e8ce0736e722184a7dbdea4a3477f) Signed-off-by: David Woodhouse --- arch/x86/kvm

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

he bit in kvm_cpuid_7_0_edx_x86_features can be unconditional] Signed-off-by: KarimAllah Ahmed <karah...@amazon.de> Signed-off-by: David Woodhouse <d...@amazon.co.uk> Signed-off-by: Thomas Gleixner <t...@linutronix.de> Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> Review

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

in kvm_cpuid_7_0_edx_x86_features can be unconditional] Signed-off-by: KarimAllah Ahmed Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Reviewed-by: Paolo Bonzini Reviewed-by: Darren Kenny Reviewed-by: Jim Mattson Reviewed-by: Konrad Rzeszutek Wilk Cc: Andrea Arcangeli Cc: Andi Kleen Cc: Jun Nakajima Cc

[PATCH 5/9] KVM: VMX: make MSR bitmaps per-VCPU

picked from commit 904e14fb7cb96401a7dc803ca2863fd5ba32ffe6) Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kvm/vmx.c | 314 +++-- 1 file changed, 114 insertions(+), 200 deletions(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 8c562da..8570a

[PATCH 5/9] KVM: VMX: make MSR bitmaps per-VCPU

basis, whether to intercept the SPEC_CTRL and PRED_CMD MSRs. Cc: sta...@vger.kernel.org # prereq for Spectre mitigation Suggested-by: Jim Mattson Signed-off-by: Paolo Bonzini (cherry picked from commit 904e14fb7cb96401a7dc803ca2863fd5ba32ffe6) Signed-off-by: David Woodhouse --- arch/x86/kvm

[PATCH 9/9] KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL

if the guest actually used it. Signed-off-by: KarimAllah Ahmed <karah...@amazon.de> Signed-off-by: David Woodhouse <d...@amazon.co.uk> Signed-off-by: Thomas Gleixner <t...@linutronix.de> Reviewed-by: Darren Kenny <darren.ke...@oracle.com> Reviewed-by: Konrad Rzeszutek Wilk

[PATCH 9/9] KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL

Ahmed Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Reviewed-by: Darren Kenny Reviewed-by: Konrad Rzeszutek Wilk Cc: Andrea Arcangeli Cc: Andi Kleen Cc: Jun Nakajima Cc: k...@vger.kernel.org Cc: Dave Hansen Cc: Tim Chen Cc: Andy Lutomirski Cc: Asit Mallick Cc: Arjan Van

Re: [PATCH] mm: Always print RLIMIT_DATA warning

On Tue, 2018-02-06 at 20:27 +0300, Cyrill Gorcunov wrote: > On Tue, Feb 06, 2018 at 04:45:05PM +0000, David Woodhouse wrote: > > > > The documentation for ignore_rlimit_data says that it will print a warning > > at first misuse. Yet it doesn't seem to do that.

Re: [PATCH] mm: Always print RLIMIT_DATA warning

On Tue, 2018-02-06 at 20:27 +0300, Cyrill Gorcunov wrote: > On Tue, Feb 06, 2018 at 04:45:05PM +0000, David Woodhouse wrote: > > > > The documentation for ignore_rlimit_data says that it will print a warning > > at first misuse. Yet it doesn't seem to do that.

[PATCH 8/9] KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL

may require trapping all writes if we don't want to pass it through directly to the guest. [dwmw2: Clean up CPUID bits, save/restore manually, handle reset] Signed-off-by: KarimAllah Ahmed <karah...@amazon.de> Signed-off-by: David Woodhouse <d...@amazon.co.uk> Signed-off-by: Thomas Glei

[PATCH 8/9] KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL

it through directly to the guest. [dwmw2: Clean up CPUID bits, save/restore manually, handle reset] Signed-off-by: KarimAllah Ahmed Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner Reviewed-by: Darren Kenny Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Jim Mattson Cc: Andrea

[PATCH 3/9] KVM: nVMX: Eliminate vmcs02 pool

t; Signed-off-by: Radim Krčmář <rkrc...@redhat.com> (cherry picked from commit de3a0021a60635de96aa92713c1a31a96747d72c) Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kvm/vmx.c | 146 + 1 file changed, 23 insertions(+), 123

[PATCH 3/9] KVM: nVMX: Eliminate vmcs02 pool

-off-by: Jim Mattson Signed-off-by: Mark Kanda Reviewed-by: Ameya More Reviewed-by: David Hildenbrand Reviewed-by: Paolo Bonzini Signed-off-by: Radim Krčmář (cherry picked from commit de3a0021a60635de96aa92713c1a31a96747d72c) Signed-off-by: David Woodhouse --- arch/x86/kvm/vmx.c | 146

[STABLE 4.9.y PATCH 0/9] Backport of KVM Speculation Control support

I've put together a linux-4.9.y branch at http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9.y Most of it is fairly straightforward, apart from the IBPB on context switch for which Tim has already posted a candidate. I wanted some more review on my backports of the KVM

[STABLE 4.9.y PATCH 0/9] Backport of KVM Speculation Control support

I've put together a linux-4.9.y branch at http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9.y Most of it is fairly straightforward, apart from the IBPB on context switch for which Tim has already posted a candidate. I wanted some more review on my backports of the KVM

[PATCH] mm: Always print RLIMIT_DATA warning

The documentation for ignore_rlimit_data says that it will print a warning at first misuse. Yet it doesn't seem to do that. Fix the code to print the warning even when we allow the process to continue. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- We should probably also do what

[PATCH] mm: Always print RLIMIT_DATA warning

The documentation for ignore_rlimit_data says that it will print a warning at first misuse. Yet it doesn't seem to do that. Fix the code to print the warning even when we allow the process to continue. Signed-off-by: David Woodhouse --- We should probably also do what Linus suggested in https

Re: [PATCH 05/10] tools headers: Synchoronize x86 features UAPI headers

On Mon, 2018-02-05 at 16:56 -0300, Arnaldo Carvalho de Melo wrote: > > None will entail changes in the tools/perf/, synchronizing to elliminate > these perf build warnings: > >   Warning: Kernel ABI header at > 'tools/arch/x86/include/asm/disabled-features.h' differs from latest version > at

Re: [PATCH 05/10] tools headers: Synchoronize x86 features UAPI headers

On Mon, 2018-02-05 at 16:56 -0300, Arnaldo Carvalho de Melo wrote: > > None will entail changes in the tools/perf/, synchronizing to elliminate > these perf build warnings: > >   Warning: Kernel ABI header at > 'tools/arch/x86/include/asm/disabled-features.h' differs from latest version > at

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-02-04 at 19:43 +0100, Thomas Gleixner wrote: > Yet another possibility is to avoid the function entry and accouting magic > and use the generic gcc return thunk: > > __x86_return_thunk: > call L2 > L1: > pause > lfence > jmp L1 > L2: > lea

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-02-04 at 19:43 +0100, Thomas Gleixner wrote: > Yet another possibility is to avoid the function entry and accouting magic > and use the generic gcc return thunk: > > __x86_return_thunk: > call L2 > L1: > pause > lfence > jmp L1 > L2: > lea

Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On Tue, 2018-01-30 at 14:39 -0800, tip-bot for Tim Chen wrote: > Thanks to the reviewers and Andy Lutomirski for the suggestion of > using ctx_id which got rid of the problem of mm pointer recycling. That one doesn't backport well to 4.9. Suggestions welcome. smime.p7s Description: S/MIME

Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On Tue, 2018-01-30 at 14:39 -0800, tip-bot for Tim Chen wrote: > Thanks to the reviewers and Andy Lutomirski for the suggestion of > using ctx_id which got rid of the problem of mm pointer recycling. That one doesn't backport well to 4.9. Suggestions welcome. smime.p7s Description: S/MIME

Re: [9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

On Mon, 2018-02-05 at 12:10 +0100, Ingo Molnar wrote: > > Can this branch still be rebased, to fix the SoB chain of: > >   de3a0021a606 ("KVM: nVMX: Eliminate vmcs02 pool") > > ? It can't. Linus pulled it already. smime.p7s Description: S/MIME cryptographic signature

Re: [9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

On Mon, 2018-02-05 at 12:10 +0100, Ingo Molnar wrote: > > Can this branch still be rebased, to fix the SoB chain of: > >   de3a0021a606 ("KVM: nVMX: Eliminate vmcs02 pool") > > ? It can't. Linus pulled it already. smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH] Fix typo IBRS_ATT, which should be IBRS_ALL

On Mon, 2018-02-05 at 11:00 +, Darren Kenny wrote: > On Fri, Feb 02, 2018 at 11:42:12PM +0000, David Woodhouse wrote: > > > > On Fri, 2018-02-02 at 19:12 +, Darren Kenny wrote: > > > > > > Fixes a typo in commit 117cc7a908c83697b0b737d15ae1eb5943afe35b &

Re: [PATCH] Fix typo IBRS_ATT, which should be IBRS_ALL

On Mon, 2018-02-05 at 11:00 +, Darren Kenny wrote: > On Fri, Feb 02, 2018 at 11:42:12PM +0000, David Woodhouse wrote: > > > > On Fri, 2018-02-02 at 19:12 +, Darren Kenny wrote: > > > > > > Fixes a typo in commit 117cc7a908c83697b0b737d15ae1eb5943afe35b &

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-02-04 at 19:43 +0100, Thomas Gleixner wrote: > > __x86_return_thunk would look like this: > > __x86_return_thunk: > testl   $0xf, PER_CPU_VAR(call_depth) > jnz 1f   > stuff_rsb >    1: > declPER_CPU_VAR(call_depth) > ret > > The

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

On Sun, 2018-02-04 at 19:43 +0100, Thomas Gleixner wrote: > > __x86_return_thunk would look like this: > > __x86_return_thunk: > testl   $0xf, PER_CPU_VAR(call_depth) > jnz 1f   > stuff_rsb >    1: > declPER_CPU_VAR(call_depth) > ret > > The

Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

On Fri, 2018-02-02 at 21:23 +, Alan Cox wrote: > In addition the problem with switch() is that gcc might decide in some > cases that the best way to implement your switch is an indirect call > from a lookup table. That's also true of the   if (ptr == usualfunction)      usualfunction();  

Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

On Fri, 2018-02-02 at 21:23 +, Alan Cox wrote: > In addition the problem with switch() is that gcc might decide in some > cases that the best way to implement your switch is an indirect call > from a lookup table. That's also true of the   if (ptr == usualfunction)      usualfunction();  

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote: > I just tested the 4.15 kernel and it is reporting that my old i486 > (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown, > Spectre V1, and Spectre V2. > > I find this to be _unlikely_. This should be fixed in Linus' tree

Re: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre_V2

On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote: > I just tested the 4.15 kernel and it is reporting that my old i486 > (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown, > Spectre V1, and Spectre V2. > > I find this to be _unlikely_. This should be fixed in Linus' tree

Re: [PATCH] Fix typo IBRS_ATT, which should be IBRS_ALL

ek Wilk <konrad.w...@oracle.com> Not strictly a typo; that was the original name for it. "IBRS all the time". But yes, it should be IBRS_ALL now. Acked-by: David Woodhouse <d...@amazon.co.uk> smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH] Fix typo IBRS_ATT, which should be IBRS_ALL

hat was the original name for it. "IBRS all the time". But yes, it should be IBRS_ALL now. Acked-by: David Woodhouse smime.p7s Description: S/MIME cryptographic signature

Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

On Fri, 2018-02-02 at 16:10 -0500, Paolo Bonzini wrote: > > > On 2. Feb 2018, at 15:59, David Woodhouse <d...@amazon.co.uk> wrote: > > > With retpoline, tight loops of "call this function for every XXX" are > > > very much pessimised by taking a predicti

Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

On Fri, 2018-02-02 at 16:10 -0500, Paolo Bonzini wrote: > > > On 2. Feb 2018, at 15:59, David Woodhouse wrote: > > > With retpoline, tight loops of "call this function for every XXX" are > > > very much pessimised by taking a prediction miss *every* time. >

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

On Fri, 2018-02-02 at 15:28 -0500, Konrad Rzeszutek Wilk wrote: > > >  > > No. The AMD feature bits give us more fine-grained support for exposing > > IBPB or IBRS alone, so we expose those bits on Intel too. > > But but.. that runs smack against the idea of exposing a platform that > is as

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

On Fri, 2018-02-02 at 15:28 -0500, Konrad Rzeszutek Wilk wrote: > > >  > > No. The AMD feature bits give us more fine-grained support for exposing > > IBPB or IBRS alone, so we expose those bits on Intel too. > > But but.. that runs smack against the idea of exposing a platform that > is as

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

On Fri, 2018-02-02 at 14:56 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 02, 2018 at 06:02:24PM +0000, David Woodhouse wrote: > > > > On Fri, 2018-02-02 at 12:49 -0500, Konrad Rzeszutek Wilk wrote: > > > > > > > > > > > @@ -625,7 +6

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

On Fri, 2018-02-02 at 14:56 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 02, 2018 at 06:02:24PM +0000, David Woodhouse wrote: > > > > On Fri, 2018-02-02 at 12:49 -0500, Konrad Rzeszutek Wilk wrote: > > > > > > > > > > > @@ -625,7 +6

Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

On Fri, 2018-02-02 at 11:10 -0800, Linus Torvalds wrote: > On Fri, Feb 2, 2018 at 10:50 AM, Linus Torvalds > wrote: > > > > > > Will it make for bigger code? Yes. But probably not really all *that* > > much bigger, because of how it also will allow the compiler to

Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

On Fri, 2018-02-02 at 11:10 -0800, Linus Torvalds wrote: > On Fri, Feb 2, 2018 at 10:50 AM, Linus Torvalds > wrote: > > > > > > Will it make for bigger code? Yes. But probably not really all *that* > > much bigger, because of how it also will allow the compiler to > > simplify some things. > >

Re: [PATCH v6 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Fri, 2018-02-02 at 12:53 -0500, Konrad Rzeszutek Wilk wrote: > .snip.. > > > > @@ -1913,6 +1914,29 @@ static void update_exception_bitmap(struct > > kvm_vcpu *vcpu) > >  } > >   > >  /* > > + * Check if MSR is intercepted for currently loaded MSR bitmap. > > + */ > > +static bool

Re: [PATCH v6 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Fri, 2018-02-02 at 12:53 -0500, Konrad Rzeszutek Wilk wrote: > .snip.. > > > > @@ -1913,6 +1914,29 @@ static void update_exception_bitmap(struct > > kvm_vcpu *vcpu) > >  } > >   > >  /* > > + * Check if MSR is intercepted for currently loaded MSR bitmap. > > + */ > > +static bool

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

On Fri, 2018-02-02 at 12:49 -0500, Konrad Rzeszutek Wilk wrote: > > @@ -625,7 +629,12 @@ static inline int __do_cpuid_ent(struct > > kvm_cpuid_entry2 *entry, u32 function, > > if (!g_phys_as) > > g_phys_as = phys_as; > > entry->eax =

Re: [PATCH v6 2/5] KVM: x86: Add IBPB support

On Fri, 2018-02-02 at 12:49 -0500, Konrad Rzeszutek Wilk wrote: > > @@ -625,7 +629,12 @@ static inline int __do_cpuid_ent(struct > > kvm_cpuid_entry2 *entry, u32 function, > > if (!g_phys_as) > > g_phys_as = phys_as; > > entry->eax =

[PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

and let's see how that works out... Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- Not sure I like this. Better suggestions welcomed... In the general case, we have a few things we can do with the calls that retpoline turns into bottlenecks. This is one of them. Another option, i

[PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

and let's see how that works out... Signed-off-by: David Woodhouse --- Not sure I like this. Better suggestions welcomed... In the general case, we have a few things we can do with the calls that retpoline turns into bottlenecks. This is one of them. Another option, if there are just one or t

[tip:x86/pti] x86/retpoline: Avoid retpolines for built-in __init functions

Commit-ID: 66f793099a636862a71c59d4a6ba91387b155e0c Gitweb: https://git.kernel.org/tip/66f793099a636862a71c59d4a6ba91387b155e0c Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Thu, 1 Feb 2018 11:27:20 + Committer: Thomas Gleixner <t...@linutronix.de> CommitDate

[tip:x86/pti] x86/retpoline: Avoid retpolines for built-in __init functions

Commit-ID: 66f793099a636862a71c59d4a6ba91387b155e0c Gitweb: https://git.kernel.org/tip/66f793099a636862a71c59d4a6ba91387b155e0c Author: David Woodhouse AuthorDate: Thu, 1 Feb 2018 11:27:20 + Committer: Thomas Gleixner CommitDate: Fri, 2 Feb 2018 12:28:27 +0100 x86/retpoline: Avoid

Re: [PATCH v6 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

im.c.c...@linux.intel.com> > Cc: Thomas Gleixner <t...@linutronix.de> > Cc: Dan Williams <dan.j.willi...@intel.com> > Cc: Jun Nakajima <jun.nakaj...@intel.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: David Woodhouse <d...@amazon.co.uk>

Re: [PATCH v6 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

di Kleen > Cc: Andrea Arcangeli > Cc: Linus Torvalds > Cc: Tim Chen > Cc: Thomas Gleixner > Cc: Dan Williams > Cc: Jun Nakajima > Cc: Paolo Bonzini > Cc: David Woodhouse > Cc: Greg KH > Cc: Andy Lutomirski > Cc: Ashok Raj > Signed-off-by: Karim

Re: [PATCH 0/7] objtool: retpoline validation

On Thu, 2018-02-01 at 16:40 +0100, Peter Zijlstra wrote: > On Thu, Feb 01, 2018 at 03:32:11PM +0000, David Woodhouse wrote: > > > > On Thu, 2018-02-01 at 09:28 -0600, Josh Poimboeuf wrote: > > > > > > On Thu, Feb 01, 2018 at 03:34

Re: [PATCH 0/7] objtool: retpoline validation

On Thu, 2018-02-01 at 16:40 +0100, Peter Zijlstra wrote: > On Thu, Feb 01, 2018 at 03:32:11PM +0000, David Woodhouse wrote: > > > > On Thu, 2018-02-01 at 09:28 -0600, Josh Poimboeuf wrote: > > > > > > On Thu, Feb 01, 2018 at 03:34

Re: [PATCH 0/7] objtool: retpoline validation

On Thu, 2018-02-01 at 09:28 -0600, Josh Poimboeuf wrote: > On Thu, Feb 01, 2018 at 03:34:21PM +0100, Peter Zijlstra wrote: > > > > There are the retpoline validation patches; they work with the > > __noretpoline > > thing from David. > Have you run this through 0-day bot yet?  A manual awk/sed

Re: [PATCH 0/7] objtool: retpoline validation

On Thu, 2018-02-01 at 09:28 -0600, Josh Poimboeuf wrote: > On Thu, Feb 01, 2018 at 03:34:21PM +0100, Peter Zijlstra wrote: > > > > There are the retpoline validation patches; they work with the > > __noretpoline > > thing from David. > Have you run this through 0-day bot yet?  A manual awk/sed

Re: [PATCH 4/7] x86,nospec: Annotate indirect calls/jumps

On Thu, 2018-02-01 at 15:34 +0100, Peter Zijlstra wrote: > >   * These are the bare retpoline primitives for indirect jmp and call. >   * Do not use these directly; they only exist to make the ALTERNATIVE >   * invocation below less ugly. > @@ -102,9 +114,9 @@ >  .macro JMP_NOSPEC reg:req >  

Re: [PATCH 4/7] x86,nospec: Annotate indirect calls/jumps

On Thu, 2018-02-01 at 15:34 +0100, Peter Zijlstra wrote: > >   * These are the bare retpoline primitives for indirect jmp and call. >   * Do not use these directly; they only exist to make the ALTERNATIVE >   * invocation below less ugly. > @@ -102,9 +114,9 @@ >  .macro JMP_NOSPEC reg:req >  

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 23:26 -0500, Konrad Rzeszutek Wilk wrote: > > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > > index 6a9f4ec..bfc80ff 100644 > > --- a/arch/x86/kvm/vmx.c > > +++ b/arch/x86/kvm/vmx.c > > @@ -594,6 +594,14 @@ struct vcpu_vmx { > >  #endif > >   > >   u64   

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 23:26 -0500, Konrad Rzeszutek Wilk wrote: > > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > > index 6a9f4ec..bfc80ff 100644 > > --- a/arch/x86/kvm/vmx.c > > +++ b/arch/x86/kvm/vmx.c > > @@ -594,6 +594,14 @@ struct vcpu_vmx { > >  #endif > >   > >   u64   

[PATCH 2/2] x86: Simplify spectre_v2 command line parsing

From: KarimAllah Ahmed <karah...@amazon.de> [dwmw2: Use ARRAY_SIZE] Signed-off-by: KarimAllah Ahmed <karah...@amazon.de> Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- arch/x86/kernel/cpu/bugs.c | 86 ++ 1 file changed, 56

[PATCH 2/2] x86: Simplify spectre_v2 command line parsing

From: KarimAllah Ahmed [dwmw2: Use ARRAY_SIZE] Signed-off-by: KarimAllah Ahmed Signed-off-by: David Woodhouse --- arch/x86/kernel/cpu/bugs.c | 86 ++ 1 file changed, 56 insertions(+), 30 deletions(-) diff --git a/arch/x86/kernel/cpu/bugs.c b/arch

[PATCH 0/2] Spectre v2 tweaks

A couple of things that have been lurking in the "shall we do this?" area of my git tree for a while, and I think we probably should... David Woodhouse (1): x86/retpoline: No retpolines for built-in __init functions KarimAllah Ahmed (1): x86: Simplify spectre_v2 command line pars

[PATCH 0/2] Spectre v2 tweaks

A couple of things that have been lurking in the "shall we do this?" area of my git tree for a while, and I think we probably should... David Woodhouse (1): x86/retpoline: No retpolines for built-in __init functions KarimAllah Ahmed (1): x86: Simplify spectre_v2 command line pars

[PATCH 1/2] x86/retpoline: No retpolines for built-in __init functions

There's no point in building init code with retpolines, since it runs before any potentially hostile userspace does. And before the retpoline is actually ALTERNATIVEd into place, for much of it. Signed-off-by: David Woodhouse <d...@amazon.co.uk> --- include/linux/init.h | 9 -

[PATCH 1/2] x86/retpoline: No retpolines for built-in __init functions

There's no point in building init code with retpolines, since it runs before any potentially hostile userspace does. And before the retpoline is actually ALTERNATIVEd into place, for much of it. Signed-off-by: David Woodhouse --- include/linux/init.h | 9 - 1 file changed, 8 insertions

Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On Wed, 2018-01-31 at 08:03 +0100, Dominik Brodowski wrote: > Whether a process needs protection by IBPB on context switches is a > different question to whether a process should be allowed to be dumped, > though the former may be a superset of the latter. Enable IBPB on all > context switches to

Re: [tip:x86/pti] x86/speculation: Use Indirect Branch Prediction Barrier in context switch

On Wed, 2018-01-31 at 08:03 +0100, Dominik Brodowski wrote: > Whether a process needs protection by IBPB on context switches is a > different question to whether a process should be allowed to be dumped, > though the former may be a superset of the latter. Enable IBPB on all > context switches to

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 14:06 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 1:59 PM, David Woodhouse <dw...@infradead.org> wrote: > > I'm actually working on IBRS_ALL at the moment. > > > > I was tempted to *not* let the guests turn it off. Expose SPEC_CTRL b

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 14:06 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 1:59 PM, David Woodhouse wrote: > > I'm actually working on IBRS_ALL at the moment. > > > > I was tempted to *not* let the guests turn it off. Expose SPEC_CTRL but > > just make it a

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 13:18 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 12:21 PM, David Woodhouse wrote: > > > > > Reading and writing this MSR is expensive. And if it's yielded to the > > guest in the MSR bitmap, that means we have to save its value on vm

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 13:18 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 12:21 PM, David Woodhouse wrote: > > > > > Reading and writing this MSR is expensive. And if it's yielded to the > > guest in the MSR bitmap, that means we have to save its value on vm

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 13:53 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 1:42 PM, Paolo Bonzini wrote: > > > Can we just say it sucks to be L2 too? :)  Because in the end as long as > > no one ever writes to spec_ctrl, everybody is happy. > > Unfortunately, quite a

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 13:53 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 1:42 PM, Paolo Bonzini wrote: > > > Can we just say it sucks to be L2 too? :)  Because in the end as long as > > no one ever writes to spec_ctrl, everybody is happy. > > Unfortunately, quite a few OS vendors

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 12:18 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 12:01 PM, KarimAllah Ahmed wrote: > > > > > but save_spec_ctrl_on_exit is also set for L2 write. So once L2 writes > > to it, this condition will be true and then the bitmap will be updated. > So if L1 or any L2

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 12:18 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 12:01 PM, KarimAllah Ahmed wrote: > > > > > but save_spec_ctrl_on_exit is also set for L2 write. So once L2 writes > > to it, this condition will be true and then the bitmap will be updated. > So if L1 or any L2

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 11:53 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 11:37 AM, KarimAllah Ahmed wrote: > > > + > > +   if (to_vmx(vcpu)->save_spec_ctrl_on_exit) { > > +   nested_vmx_disable_intercept_for_msr( > > +   msr_bitmap_l1,

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On Wed, 2018-01-31 at 11:53 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 11:37 AM, KarimAllah Ahmed wrote: > > > + > > +   if (to_vmx(vcpu)->save_spec_ctrl_on_exit) { > > +   nested_vmx_disable_intercept_for_msr( > > +   msr_bitmap_l1,

Re: [PATCH v5 2/5] KVM: x86: Add IBPB support

On Wed, 2018-01-31 at 11:45 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 11:37 AM, KarimAllah Ahmed wrote: > > > +   nested_vmx_disable_intercept_for_msr(msr_bitmap_l1, msr_bitmap_l0, > > +    MSR_IA32_PRED_CMD, > > +   

Re: [PATCH v5 2/5] KVM: x86: Add IBPB support

On Wed, 2018-01-31 at 11:45 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 11:37 AM, KarimAllah Ahmed wrote: > > > +   nested_vmx_disable_intercept_for_msr(msr_bitmap_l1, msr_bitmap_l0, > > +    MSR_IA32_PRED_CMD, > > +   

Re: [PATCH 20/24] objtool: Another static block fail

On Wed, 2018-01-31 at 11:01 +0100, Peter Zijlstra wrote: > On Tue, Jan 30, 2018 at 09:12:21PM -0600, Josh Poimboeuf wrote: > >  > > Or, maybe we should just forget the whole thing and just stick with the > > dynamic IBRS checks with lfence.  Yes, it's less ideal for the kernel, > > but adding

Re: [PATCH 20/24] objtool: Another static block fail

On Wed, 2018-01-31 at 11:01 +0100, Peter Zijlstra wrote: > On Tue, Jan 30, 2018 at 09:12:21PM -0600, Josh Poimboeuf wrote: > >  > > Or, maybe we should just forget the whole thing and just stick with the > > dynamic IBRS checks with lfence.  Yes, it's less ideal for the kernel, > > but adding

Re: [PATCH v3 0/4] KVM: Expose speculation control feature to guests

On Tue, 2018-01-30 at 19:16 -0500, Paolo Bonzini wrote: > On 30/01/2018 18:48, Raj, Ashok wrote: > > > > > > > > Certainly not every vmexit!  But doing it on every userspace vmexit and > > > every sched_out would not be *that* bad. > > Right.. agreed. We discussed the different scenarios that

Re: [PATCH v3 0/4] KVM: Expose speculation control feature to guests

On Tue, 2018-01-30 at 19:16 -0500, Paolo Bonzini wrote: > On 30/01/2018 18:48, Raj, Ashok wrote: > > > > > > > > Certainly not every vmexit!  But doing it on every userspace vmexit and > > > every sched_out would not be *that* bad. > > Right.. agreed. We discussed the different scenarios that

Re: [9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

On Tue, 2018-01-30 at 18:11 -0500, Paolo Bonzini wrote: > Great, then the "per-VCPU MSR bitmaps" branch > (git://git.kernel.org/pub/scm/virt/kvm/kvm.git refs/heads/msr-bitmaps) > that I created last weekend can be pulled directly in tip/x86/pti. > > It cherry-picks directly to both 4.14 so it

Re: [9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

On Tue, 2018-01-30 at 18:11 -0500, Paolo Bonzini wrote: > Great, then the "per-VCPU MSR bitmaps" branch > (git://git.kernel.org/pub/scm/virt/kvm/kvm.git refs/heads/msr-bitmaps) > that I created last weekend can be pulled directly in tip/x86/pti. > > It cherry-picks directly to both 4.14 so it

[tip:x86/pti] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

Commit-ID: 7fcae1118f5fd44a862aa5c3525248e35ee67c3b Gitweb: https://git.kernel.org/tip/7fcae1118f5fd44a862aa5c3525248e35ee67c3b Author: David Woodhouse <d...@amazon.co.uk> AuthorDate: Tue, 30 Jan 2018 14:30:23 + Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:x86/pti] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

Commit-ID: 7fcae1118f5fd44a862aa5c3525248e35ee67c3b Gitweb: https://git.kernel.org/tip/7fcae1118f5fd44a862aa5c3525248e35ee67c3b Author: David Woodhouse AuthorDate: Tue, 30 Jan 2018 14:30:23 + Committer: Thomas Gleixner CommitDate: Tue, 30 Jan 2018 22:35:05 +0100 x86/cpuid: Fix up

Re: [PATCH v3 2/4] KVM: x86: Add IBPB support

On Tue, 2018-01-30 at 09:19 -0800, Jim Mattson wrote: > > Are you planning to allow L2 to write MSR_IA32_PRED_CMD without L0 > intercepting it, if the MSR write intercept is disabled in both the > vmcs01 MSR permission bitmap and the vmcs12 MSR permission bitmap? I don't see why we shouldn't.

Re: [PATCH v3 2/4] KVM: x86: Add IBPB support

On Tue, 2018-01-30 at 09:19 -0800, Jim Mattson wrote: > > Are you planning to allow L2 to write MSR_IA32_PRED_CMD without L0 > intercepting it, if the MSR write intercept is disabled in both the > vmcs01 MSR permission bitmap and the vmcs12 MSR permission bitmap? I don't see why we shouldn't.

Re: [9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

On Tue, 2018-01-30 at 08:57 -0800, Jim Mattson wrote: > It's really hard to tell which patches are being proposed for which > repositories, but assuming that everything else is correct, I don't > think your condition is adequate. What if the physical CPU and the > virtual CPU both have

Re: [9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

On Tue, 2018-01-30 at 08:57 -0800, Jim Mattson wrote: > It's really hard to tell which patches are being proposed for which > repositories, but assuming that everything else is correct, I don't > think your condition is adequate. What if the physical CPU and the > virtual CPU both have

Re: [PATCH v2 3/3] KVM: VMX: make MSR bitmaps per-VCPU

On Tue, 2018-01-30 at 17:23 +0100, Radim Krčmář wrote: > > The physical address of the nested msr_bitmap is never loaded into vmcs. > > The resolution you provided had extra hunk in prepare_vmcs02_full(): > > +   vmcs_write64(MSR_BITMAP, __pa(vmx->nested.vmcs02.msr_bitmap)); > > I have

Re: [PATCH v2 3/3] KVM: VMX: make MSR bitmaps per-VCPU

On Tue, 2018-01-30 at 17:23 +0100, Radim Krčmář wrote: > > The physical address of the nested msr_bitmap is never loaded into vmcs. > > The resolution you provided had extra hunk in prepare_vmcs02_full(): > > +   vmcs_write64(MSR_BITMAP, __pa(vmx->nested.vmcs02.msr_bitmap)); > > I have

Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

On Tue, 2018-01-30 at 14:54 +, Alan Cox wrote: > The only case I can think of where you'd get a non boot processor that > didn't have the same microcode loaded as the rest on entry to the OS would > be in a system where it was possibly to phyically hot plug processors > post boot. > > There

Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

On Tue, 2018-01-30 at 14:54 +, Alan Cox wrote: > The only case I can think of where you'd get a non boot processor that > didn't have the same microcode loaded as the rest on entry to the OS would > be in a system where it was possibly to phyically hot plug processors > post boot. > > There

Re: [PATCH v3 2/4] KVM: x86: Add IBPB support

On Tue, 2018-01-30 at 08:22 -0600, Tom Lendacky wrote: > > @@ -918,6 +919,9 @@ static void svm_vcpu_init_msrpm(u32 *msrpm) > >   > >   set_msr_interception(msrpm, direct_access_msrs[i].index, 1, 1); > >   } > > + > > + if (boot_cpu_has(X86_FEATURE_IBPB)) > > +

Re: [PATCH v3 2/4] KVM: x86: Add IBPB support

On Tue, 2018-01-30 at 08:22 -0600, Tom Lendacky wrote: > > @@ -918,6 +919,9 @@ static void svm_vcpu_init_msrpm(u32 *msrpm) > >   > >   set_msr_interception(msrpm, direct_access_msrs[i].index, 1, 1); > >   } > > + > > + if (boot_cpu_has(X86_FEATURE_IBPB)) > > +

[PATCH v2] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

ing the offending CPU online. So ensure that the appropriate feature bits are set within get_cpu_cap() regardless of how many extra times it's called. Signed-off-by: David Woodhouse <d...@amazon.co.uk> Fixes: 2961298e ("x86/cpufeatures: Clean up Spectre v2 related CPUID flags") --- So...

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