Re: [PATCH 3/3] x86/entry: Use PUSH_AND_CLEAR_GPRS and drop SAVE_ALL

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 07/07/2026 8:16 am, Jan Beulich wrote:
> On 06.07.2026 17:34, Andrew Cooper wrote:
>> PUSH_AND_CLEAR_GPRS is shorter than SAVE_ALL in terms of emitted code.
> Could patch 1 perhaps also gain this sentence?

Done.

>
>> lstar_enter() and cstar_enter() do not need CLD.  The SYSCALL instruction
>> sanitises flags based on MSR_SYSCALL_MASK.  For all other cases, place the 
>> CLD
>> instruction next to STAC/CLAC so the flag handling is together.
> And really the earlier the better. Relevant perhaps for early_page_fault(),
> which has no CLAC.
>
>> Get rid of the compat=1 special case for PV32.  It's not obviously a win, and
>> PV32 is getting increasingly rare these days.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

>
>> Bloat-o-meter reports:
>>   add/remove: 0/0 grow/shrink: 0/12 up/down: 0/-518 (-518)
>>   Function                                     old     new   delta
>>   symbols_names                             135277  135276      -1
>>   symbols_offsets                            53664   53660      -4
> Interesting. Likely an artifact of padding going away between two functions.
> Which likely would change again if the SLS patches would finally land
> ("x86: guard against straight-line speculation past JMP or RET in assembly
> files" here in particular).
>
> Btw, as it occurs to me while mentioning SLS: Judging from the patches I
> have, IRET looks to be immune, albeit I can't find any statement in the doc.
> What about ERET{S,U}, uses of which we've gained only relatively recently?
I think the bit you want is in SDM Vol2.  For ERETS:

"Instruction ordering. Instructions following execution of ERETS may be
fetched from memory before earlier instructions complete execution, but
they will not execute (even speculatively) until all instructions prior
to ERETS have completed execution (the later instructions may execute
before data stored by the earlier instructions have become globally
visible)."

and says the same for ERETU.  Sadly, "following" is ambiguous in the
context of SLS, but an ERETS-to-self could end up legitimately executing
the next sequential instruction.  Either way, the "not execute even
speculatively" is the property wanted.
IRET notes that it's architecturally serialising, which is a much
stronger guarantee.

~Andrew