> To add a bit more to this, Intel just updated their
> IA32_ARCH_CAPABILITIES_MSR
> to have a new bit to sample to figure out whether you need IBRS or not
> during runtime.
actually we updated the document when you need RSB stuffing.
based on the request of various folks here on LKML.
On Tue, Feb 20, 2018 at 03:46:57PM +0100, Paolo Bonzini wrote:
> On 20/02/2018 15:08, Van De Ven, Arjan wrote:
> For bonus points: What should happen to a VM that is live migrated
> from one hypervisor to another, and the hypervisors have different
> IBRS support?
> >>>
> >>> Doctor
On 20/02/2018 15:59, Van De Ven, Arjan wrote:
>
>>> I meant software wise. You're not going to live migrate from xen to
>>> kvm or backwards. or between very radically different versions of the
>>> kvm stack.
>>
>> Forwards migration to a radically newer version certainly happens. So
>> when the
> > I meant software wise. You're not going to live migrate from xen to
> > kvm or backwards. or between very radically different versions of the
> > kvm stack.
>
> Forwards migration to a radically newer version certainly happens. So
> when the source hypervisor was too old to tell the VM about
On 20/02/2018 15:08, Van De Ven, Arjan wrote:
For bonus points: What should happen to a VM that is live migrated
from one hypervisor to another, and the hypervisors have different
IBRS support?
>>>
>>> Doctor Doctor it hurts when I do this
>>>
>>> Migration tends to only work be
> >> For bonus points: What should happen to a VM that is live migrated
> >> from one hypervisor to another, and the hypervisors have different
> >> IBRS support?
> >
> > Doctor Doctor it hurts when I do this
> >
> > Migration tends to only work between HV's that are relatively
> > homogeneous
On 20/02/2018 01:00, Van De Ven, Arjan wrote:
>>> the guest is not the problem; guests obviously will already honor
>>> if Enhanced IBRS is enumerated. The problem is mixed migration
>>> pools where the hypervisor
>>> may need to decide to not pass this enumeration through to the
>>> guest.
>> For
On Mon, 19 Feb 2018, Linus Torvalds wrote:
> On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox wrote:
> >
> > In theory there's nothing stopping a guest getting a 'you are about to
> > gain/lose IBRS' message or having a new 'CPU' hotplugged and the old one
> > removed.
>
> I'm not convinced we handle th
> > On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox
> wrote:
> > >
> > > In theory there's nothing stopping a guest getting a 'you are about to
> > > gain/lose IBRS' message or having a new 'CPU' hotplugged and the old one
> > > removed.
> >
> > I'm not convinced we handle the case of hotplug CPU's with
On Mon, 19 Feb 2018 16:43:50 -0800
Linus Torvalds wrote:
> On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox wrote:
> >
> > In theory there's nothing stopping a guest getting a 'you are about to
> > gain/lose IBRS' message or having a new 'CPU' hotplugged and the old one
> > removed.
>
> I'm not conv
On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox wrote:
>
> In theory there's nothing stopping a guest getting a 'you are about to
> gain/lose IBRS' message or having a new 'CPU' hotplugged and the old one
> removed.
I'm not convinced we handle the case of hotplug CPU's with different
CPU models correct
On Tue, 20 Feb 2018 00:00:23 +
"Van De Ven, Arjan" wrote:
> > On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:
> >
> > > the guest is not the problem; guests obviously will already honor if
> > > Enhanced
> > > IBRS is enumerated. The problem is mixed migration pools where th
> On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:
>
> > the guest is not the problem; guests obviously will already honor if
> > Enhanced
> > IBRS is enumerated. The problem is mixed migration pools where the
> hypervisor
> > may need to decide to not pass this enumeration through
On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:
> the guest is not the problem; guests obviously will already honor if Enhanced
> IBRS is enumerated. The problem is mixed migration pools where the hypervisor
> may need to decide to not pass this enumeration through to the guest.
For
>
> >>> Even if the guest doesn't have/support IBRS_ALL, and is frobbing the
> >>> (now emulated) MSR on every kernel entry/exit, that's *still* going to
> >>> be a metric shitload faster than what it *thought* it was doing.
>
> Is there any indication/log to the admin that VM doesn't know about
On 02/16/2018 07:10 AM, David Woodhouse wrote:
> On Fri, 2018-02-16 at 12:04 +0100, Paolo Bonzini wrote:
>> On 16/02/2018 11:21, David Woodhouse wrote:
>>> Even if the guest doesn't have/support IBRS_ALL, and is frobbing the
>>> (now emulated) MSR on every kernel entry/exit, that's *still* going t
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 affect migration?
> Because even
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 affect migration?
Because even if the host has IBRS_ALL, as long as you want to migrate to
a system
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:
> > > >
> > > > >
> > > > > >
> > > > > > - if the VM has IBRS_AL
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:
> - 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)
>
>>
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)
> > > >
> > > > - if the VM doesn't have IBRS_ALL, do
On Tue 2018-02-13 09:02:25, Paolo Bonzini wrote:
> On 12/02/2018 16:27, David Woodhouse wrote:
> > The original IBRS hack in microcode is horribly slow. For the next
> > generation of CPUs, as a stopgap until we get a proper fix, Intel
> > promise an "Enhanced IBRS" which will be fast.
> >
> > The
On 13/02/2018 11:53, David Woodhouse 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 shoe-horn
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 sho
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)
>>>
>>> - if the VM doesn't have IBRS_ALL, do as we are doing now, independent
>>> of what the host spectre_v2_ibrs_all(
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't have IBRS_ALL, do as we are doing now, indep
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 is
On 13/02/2018 09:15, David Woodhouse wrote:
>>>
>>> - if (!data)
>>> + if (!data && !spectre_v2_ibrs_all())
>>> break;
>> This should check the value of IBRS_ALL in the VM, not in the host.
> No, it's host we want. If IBRS_ALL is set in the host, we set the
On Tue, 2018-02-13 at 09:02 +0100, Paolo Bonzini wrote:
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -3419,13 +3419,14 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu,
> > struct msr_data *msr_info)
> >
> > vmx->spec_ctrl = data;
> >
> > - if (!data)
On Tue, 2018-02-13 at 08:47 +0100, Ingo Molnar wrote:
> * David Woodhouse wrote:
>
> >
> > +extern enum spectre_v2_mitigation spectre_v2_enabled;
>
> This needs to be exported if the KVM module wants to use it.
>
> >
> > +static inline bool spectre_v2_ibrs_all(void)
> > +{
> > + return spect
On 12/02/2018 16:27, David Woodhouse wrote:
> The original IBRS hack in microcode is horribly slow. For the next
> generation of CPUs, as a stopgap until we get a proper fix, Intel
> promise an "Enhanced IBRS" which will be fast.
>
> The assumption is that predictions in the BTB/RSB will be tagged
* David Woodhouse wrote:
> +extern enum spectre_v2_mitigation spectre_v2_enabled;
This needs to be exported if the KVM module wants to use it.
> +static inline bool spectre_v2_ibrs_all(void)
> +{
> + return spectre_v2_enabled == SPECTRE_V2_IBRS_ALL;
> +}
> + if (vmx->spec_ctrl && !spe
The original IBRS hack in microcode is horribly slow. For the next
generation of CPUs, as a stopgap until we get a proper fix, Intel
promise an "Enhanced IBRS" which will be fast.
The assumption is that predictions in the BTB/RSB will be tagged with
the VMX mode and ring that they were learned in,
33 matches
Mail list logo
