Re: [PATCH 1/3] KVM: x86: use native MSR ops for SPEC_CTRL

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Feb 23, 2018 at 06:35:30PM +0100, Paolo Bonzini wrote:
> On 23/02/2018 18:22, Konrad Rzeszutek Wilk wrote:
> > 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.
> 
> Actually it is faster---that's why I made the change in the first place,
> though later I noticed
> 
> > 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.
> 
> Ok, I wasn't sure about PVH (which runs in ring 0 afair).

Right. PVH is HVM without any emulated devices or BIOSes or such.

In the context of the paravirt ops, Xen PVH == Xen HVM.

Xen PV (and lguests) are the only ones that patch the the
	callq	*0xffffblah

to
	callq	0xffff800

While everyone else does the wrmsr.
> 
> Paolo