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 >
