Messages in this thread | | | Date | Fri, 23 Feb 2018 12:22:20 -0500 | From | Konrad Rzeszutek Wilk <> | Subject | Re: [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 >
| |