Re: [Xen-devel] [PATCH] x86: issue branch prediction barrier when switching 64-bit guest to kernel mode

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.02.18 at 18:11, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/02/18 15:39, Jan Beulich wrote:
>> Since both kernel and user mode run in ring 3, they run in the same
>> "predictor mode". While the kernel could take care of this itself, doing
>> so would be yet another item distinguishing PV from native. Additionally
>> we're in a much better position to issue the barrier command, and we can
>> save a #GP (for privileged instruction emulation) this way.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> (In microcode at least) IBPB is crippling in terms of performance hit,
> and a retpolined kernel doesn't need the BTB to be flushed on entry.
> 
> An opt-in VMASSIST might be useful for PV guests running on Skylake+
> hardware, but we certainly shouldn't issue the barrier blindly.

Considering your first statement, how would this be of any use on
Skylake+? With retpolines and RSB stuffing making the barrier
unnecessary I don't see any value in such a VMASSIST. The main
idea (which I agree was going too far) was anyway to do something
for the guest without extra guest side changes.

> Alternatively/additionally, a hypercall_iret flag indicating "I'm return
> to a new logical context" would probably also be useful, to avoid a
> trap&emulate in the context switch path.

Hmm, for 64-bit guests this would be possible, as we have a flags
field. For 32-bit guests the only option I see would be a new
flavor of HYPERVISOR_iret. And I dislike the idea of doing the same
thing in completely different ways (not the least because it'll make
using it in guest kernels less easy).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel