Re: [PATCH v2 06/11] selftests: Fix arm64 IO barriers to match kernel

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, May 29, 2026 at 05:55:16PM +0100, David Laight wrote:
> On Fri, 29 May 2026 10:49:47 -0300
> Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> > On Thu, May 28, 2026 at 06:13:26PM +0000, David Matlack wrote:
> > 
> > > Let's put these in tools/arch/arm64/include/asm/io.h so that the tools
> > > headers are more aligned with the kernel headers, and so that the arm64
> > > io.h overrides are done in the same way as the x86 overrides in
> > > tools/arch/x86/include/asm/io.h.
> > > 
> > > Something like this (untested):  
> > 
> > Okay, the disassembly says it works:
> > 
> >     1db8:       ca080108        eor     x8, x8, x8
> >     1dbc:       b5000008        cbnz    x8, 1dbc <readl+0x58>
> >     1dc0:       f9000fe8        str     x8, [sp, #24]
> 
> That looks strange, I suspect the C didn't match any usual pattern.
> Normally 'tmp' would get thrown away and 'v' would get kept.
> But you seem to have discarded 'v' and written 'tmp' to stack.

Oh interesting the optimizer isn't turned on for selftest builds. So
the str is dutifully writing tmp to the stack. Another register has
the actual value.

> I'm probably being stupid again, but how does that work?
> The cpu can speculate straight through the control dependency into
> the following instructions.
> An 'eor x1, x8, x8' may not even have a data-dependency on x8.
> (Most x86 cpus just generate a zero for the equivalent instruction.)

I can't say, this is copied from the kernel and Will made it:

    arm64: io: Ensure calls to delay routines are ordered against prior readX()
    
    A relatively standard idiom for ensuring that a pair of MMIO writes to a
    device arrive at that device with a specified minimum delay between them
    is as follows:
    
            writel_relaxed(42, dev_base + CTL1);
            readl(dev_base + CTL1);
            udelay(10);
            writel_relaxed(42, dev_base + CTL2);
    
    the intention being that the read-back from the device will push the
    prior write to CTL1, and the udelay will hold up the write to CTL1 until
    at least 10us have elapsed.
    
    Unfortunately, on arm64 where the underlying delay loop is implemented
    as a read of the architected counter, the CPU does not guarantee
    ordering from the readl() to the delay loop and therefore the delay loop
    could in theory be speculated and not provide the desired interval
    between the two writes.
    
    Fix this in a similar manner to PowerPC by introducing a dummy control
    dependency on the output of readX() which, combined with the ISB in the
    read of the architected counter, guarantees that a subsequent delay loop
    can not be executed until the readX() has returned its result.
    
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Will Deacon <will.deacon@arm.com>

Jason