On Tue, 2018-01-30 at 19:16 -0500, Paolo Bonzini wrote: > On 30/01/2018 18:48, Raj, Ashok wrote: > > > > > > > > Certainly not every vmexit! But doing it on every userspace vmexit and > > > every sched_out would not be *that* bad. > > Right.. agreed. We discussed the different scenarios that doing IBPB > > on VMexit would help, and decided its really not required on every exit. > > > > One obvious case is when there is a VMexit and return back to Qemu > > process (witout a real context switch) do we need that to be > > protected from any poisoned BTB from guest? > If the host is using retpolines, then some kind of barrier is needed. I > don't know if the full PRED_CMD barrier is needed, or two IBRS=1/IBRS=0 > writes back-to-back are enough. > > If the host is using IBRS, then writing IBRS=1 at vmexit has established > a barrier from the less privileged VMX guest environment. IBRS will protect qemu userspace only if you set it at some point before exiting the kernel. You don't want it set *in* the kernel, if we're using retpolines in the kernel, so you'd want to clear it again on the way back into the kernel. It's almost the opposite of what the IBRS patch set was doing to protect the kernel. Just use IBPB :)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
