lkml.org 
[lkml]   [2018]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] KVM: x86: use native MSR ops for SPEC_CTRL
On Fri, Feb 23, 2018 at 10:37:49AM +0100, Paolo Bonzini wrote:
> On 22/02/2018 18:07, Konrad Rzeszutek Wilk wrote:
> >> Having a paravirt indirect call in the IBRS restore path is not a
> >> good idea, since we are trying to protect from speculative execution
> >> of bogus indirect branch targets. It is also slower, so use
> >> native_wrmsrl on the vmentry path too.
> > But it gets replaced during patching. As in once the machine boots
> > the assembler changes from:
> >
> > callq *0xfffflbah
> >
> > to
> > wrmsr
> >
> > ? I don't think you need this patch.
>
> Why not be explicit? According to the spec, PRED_CMD and SPEC_CTRL

Explicit is fine.

But I would recommend you change the commit message to say so, and
perhaps remove 'It is also slower' - as that is incorrect.

> should be passed down to the guest without interception so it's safe to
> do this. On the other hand, especially with nested virtualization, I
> don't think you can absolutely guarantee that the paravirt call will be
> patched to rdmsr/wrmsr.

<scratches his head> If it is detected to be Xen PV, then yes
it will be a call to a function. But that won't help as Xen PV runs in
ring 3, so it has a whole bunch of other issues.

If it detects it as KVM or Xen HVM guest it will patch it with the default
- which is normal MSRs. Ditto for HyperV.

But <shrugs> no biggie - explicit is fine, just nagging on the commit
message could use a bit of expansion.

> Paolo
>

\
 
 \ /
  Last update: 2018-02-23 18:23    [W:1.042 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site