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 <[email protected]> > --- > CC: Jan Beulich <[email protected]> > CC: Roger Pau Monné <[email protected]> > > 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 <[email protected]> Otherwise I need to be further educated as to why omitting the clobber is safe in all (present and future) cases. Jan
