Re: [PATCH 3/5] x86/ucode: Refine TLB flush fix for AMD Fam17h CPUs

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.10.2025 15:19, Andrew Cooper wrote:
> In the time since Xen discovered this, Linux stubled on it too and AMD
> produced a narrower fix, limited to Fam17h CPUs only.  To my knowledge,
> there's no erratum or other public statement from AMD on the matter.
> 
> Adjust Xen to match the narrower fix.
> 
> Link: https://lore.kernel.org/lkml/ZyulbYuvrkshfsd2@antipodes/T/#u
> Fixes: f19a199281a2 ("x86/AMD: flush TLB after ucode update")
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> There is a difference in memory clobber with the invlpg() wrapper.
> apply_microcode() specifically does not want a memory clobber, whereas
> flush_area_local() doesn't need it as far as I can tell (there's nothing
> unsafe to move across this instruction).

The memory access(es) it would not want moving across would be page table
writes. With link-time optimization, wouldn't it in principle be possible
for flush_area_local() to be inlined, and the invlpg() then be moved?
Potentially ahead of a PTE write, seeing that read_cr4() is merely a
simple memory only, and hence the compiler could utilize knowledge it has
to short-circuit that as well?

For the ucode case things can't move unduly due to both rdmsrl() and
invlpg() using "asm volatile()".

With the clobber re-added
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Otherwise I need to be further educated as to why omitting the clobber is
safe in all (present and future) cases.

Jan