Re: [PATCH 03/10] x86,mm: add INVLPGB support code

[Rik van Riel <riel@surriel.com>]

On Sun, 2024-12-22 at 12:05 +0100, Peter Zijlstra wrote:
> On Sat, Dec 21, 2024 at 11:06:35PM -0500, Rik van Riel wrote:
> 
> > +static inline void __invlpgb(unsigned long asid, unsigned long
> > pcid, unsigned long addr,
> > +			    int extra_count, bool pmd_stride,
> > unsigned long flags)
> > +{
> > +	u64 rax = addr | flags;
> > +	u32 ecx = (pmd_stride << 31) | extra_count;
> > +	u32 edx = (pcid << 16) | asid;
> > +
> > +	/*
> > +	 * The memory clobber is because the whole point is to
> > invalidate
> > +	 * stale TLB entries and, especially if we're flushing
> > global
> > +	 * mappings, we don't want the compiler to reorder any
> > subsequent
> > +	 * memory accesses before the TLB flush.
> > +	 */
> > +	asm volatile("invlpgb" : : "a" (rax), "c" (ecx), "d"
> > (edx));
> 
> What memory clobber? Is "memory" gone missing?

I'm not even sure where that comment came from any more.

We do not need any barriers here, because one of the
big points of INVLPGB is that the flush is kicked off
asynchronously, and flushes may end up being done out
of order, many can be pending simultaneously, etc.

The sync point is the TLBSYNC instruction.

I removed that comment.

-- 
All Rights Reversed.