Re: [PATCH 1/8] x86/spec-ctrl: Fix confusion between SPEC_CTRL_EXIT_TO_XEN{,_IST}

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/09/2023 7:56 am, Jan Beulich wrote:
> On 13.09.2023 22:27, Andrew Cooper wrote:
>> c/s 3fffaf9c13e9 ("x86/entry: Avoid using alternatives in NMI/#MC paths")
>> dropped the only user, leaving behind the (incorrect) implication that Xen 
>> had
>> split exit paths.
>>
>> Delete the unused SPEC_CTRL_EXIT_TO_XEN and rename SPEC_CTRL_EXIT_TO_XEN_IST
>> to SPEC_CTRL_EXIT_TO_XEN for consistency.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> albeit ...
>
>> @@ -256,11 +255,6 @@
>>      ALTERNATIVE "", __stringify(DO_SPEC_CTRL_ENTRY maybexen=1),         \
>>          X86_FEATURE_SC_MSR_PV
>>  
>> -/* Use when exiting to Xen context. */
>> -#define SPEC_CTRL_EXIT_TO_XEN                                           \
>> -    ALTERNATIVE "",                                                     \
>> -        DO_SPEC_CTRL_EXIT_TO_XEN, X86_FEATURE_SC_MSR_PV
>> -
>>  /* Use when exiting to PV guest context. */
>>  #define SPEC_CTRL_EXIT_TO_PV                                            \
>>      ALTERNATIVE "",                                                     \
>> @@ -328,7 +322,7 @@ UNLIKELY_DISPATCH_LABEL(\@_serialise):
>>  .endm
>>  
>>  /* Use when exiting to Xen in IST context. */
>> -.macro SPEC_CTRL_EXIT_TO_XEN_IST
>> +.macro SPEC_CTRL_EXIT_TO_XEN
> ... with the comment her updated (either by dropping "in IST" or by
> explicitly mentioning both cases).

The comment is rewritten from scratch in patch 4.  I'm not moving that
rewrite to here, and the comment isn't technically wrong to begin with,
but I suppose I can drop the IST part.  Just means more churn.

~Andrew