On 17.03.2023 15:21, Andrew Cooper wrote:
> On 17/03/2023 1:56 pm, Juergen Gross wrote:
>> --- a/arch/x86/xen/enlighten_pv.c
>> +++ b/arch/x86/xen/enlighten_pv.c
>> @@ -1476,6 +1476,23 @@ static uint32_t __init xen_platform_pv(void)
>> return 0;
>> }
>>
>> +int __init xen_vm_assist_ibpb(bool enable)
>> +{
>> + /*
>> + * Note that the VM-assist is a disable, so a request to
>> enable IBPB
>> + * on our behalf needs to turn the functionality off (and vice
>> versa).
>> + */
>> + return HYPERVISOR_vm_assist(enable ? VMASST_CMD_disable
>> + : VMASST_CMD_enable,
>> + VMASST_TYPE_mode_switch_no_ibpb);
>> +}
>> +
>> +void __init xen_pv_fix_mitigations(void)
>> +{
>> + if (!xen_vm_assist_ibpb(true))
>> + setup_clear_cpu_cap(X86_FEATURE_ENTRY_IBPB);
>
> If nothing else, this needs a comment explaining what's going on.
>
> "Xen PV guest kernels run in ring3, so share the same prediction domain
> as userspace. Xen (since version $X) default to issuing an IBPB on
> guest user -> guest kernel transitions on behalf of the guest kernel.
> If Linux isn't depending on mode based prediction separation, turn this
> behaviour off".
I would have thought the comment in the public header - saying exactly
that - is sufficient.
> But this does open the next question. Yes, unilaterally turning turning
> this off restores the prior behaviour, but is this really the best thing
> to do ?
Unless this is purely a question on Jürgen's suggested version (in which
case I'd let him answer) - what alternative do you suggest, within the
present policy used in the kernel?
Jan
