On 01/30/2018 04:16 PM, 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 doing IBPB
>> on VMexit would
On 01/30/2018 04:16 PM, 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 doing IBPB
>> on VMexit would
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
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
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 doing IBPB
> on VMexit would help, and decided its really not required on every
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 doing IBPB
> on VMexit would help, and decided its really not required on every
On Tue, Jan 30, 2018 at 06:36:20PM -0500, Paolo Bonzini wrote:
> On 30/01/2018 04:00, David Woodhouse wrote:
> > I believe Ashok sent you a change which made us do IBPB on *every*
> > vmexit; I don't think we need that. It's currently done in vcpu_load()
> > which means we'll definitely have done
On Tue, Jan 30, 2018 at 06:36:20PM -0500, Paolo Bonzini wrote:
> On 30/01/2018 04:00, David Woodhouse wrote:
> > I believe Ashok sent you a change which made us do IBPB on *every*
> > vmexit; I don't think we need that. It's currently done in vcpu_load()
> > which means we'll definitely have done
On 30/01/2018 04:00, David Woodhouse wrote:
> I believe Ashok sent you a change which made us do IBPB on *every*
> vmexit; I don't think we need that. It's currently done in vcpu_load()
> which means we'll definitely have done it between running one vCPU and
> the next, and when vCPUs are pinned
On 30/01/2018 04:00, David Woodhouse wrote:
> I believe Ashok sent you a change which made us do IBPB on *every*
> vmexit; I don't think we need that. It's currently done in vcpu_load()
> which means we'll definitely have done it between running one vCPU and
> the next, and when vCPUs are pinned
On 01/30/2018 10:00 AM, David Woodhouse wrote:
On Tue, 2018-01-30 at 01:10 +0100, KarimAllah Ahmed wrote:
Add direct access to speculation control MSRs for KVM guests. This allows the
guest to protect itself against Spectre V2 using IBRS+IBPB instead of a
retpoline+IBPB based approach.
It
On 01/30/2018 10:00 AM, David Woodhouse wrote:
On Tue, 2018-01-30 at 01:10 +0100, KarimAllah Ahmed wrote:
Add direct access to speculation control MSRs for KVM guests. This allows the
guest to protect itself against Spectre V2 using IBRS+IBPB instead of a
retpoline+IBPB based approach.
It
On Tue, 2018-01-30 at 01:10 +0100, KarimAllah Ahmed wrote:
> Add direct access to speculation control MSRs for KVM guests. This allows the
> guest to protect itself against Spectre V2 using IBRS+IBPB instead of a
> retpoline+IBPB based approach.
>
> It also exposes the ARCH_CAPABILITIES MSR
On Tue, 2018-01-30 at 01:10 +0100, KarimAllah Ahmed wrote:
> Add direct access to speculation control MSRs for KVM guests. This allows the
> guest to protect itself against Spectre V2 using IBRS+IBPB instead of a
> retpoline+IBPB based approach.
>
> It also exposes the ARCH_CAPABILITIES MSR
Add direct access to speculation control MSRs for KVM guests. This allows the
guest to protect itself against Spectre V2 using IBRS+IBPB instead of a
retpoline+IBPB based approach.
It also exposes the ARCH_CAPABILITIES MSR which is going to be used by future
Intel processors to indicate RDCL_NO
Add direct access to speculation control MSRs for KVM guests. This allows the
guest to protect itself against Spectre V2 using IBRS+IBPB instead of a
retpoline+IBPB based approach.
It also exposes the ARCH_CAPABILITIES MSR which is going to be used by future
Intel processors to indicate RDCL_NO
16 matches
Mail list logo
