[PATCH RFC] arm64: vdso: Use __arch_counter_get_cntvct()

[Breno Leitao]

Hello Marc,

On Thu, Apr 03, 2025 at 06:59:44PM +0100, Marc Zyngier wrote:
> On Thu, 03 Apr 2025 13:14:49 +0100,
> Breno Leitao <leitao at debian.org> wrote:
> > 
> > Since you created *all* this noise regarding instruction ordering, can
> > I pick your brain in the same topic? :-P
> > 
> > If my machine has Speculation Barrier (sb)[1] support, is it a good
> > replacement for `isb` ? Do you happen to know?
> 
> Probably not. SB prevent speculation past it, while ISB is here to
> enforce ordering. We're pretty happy to let the CPU speculate the
> counter, as long as it does it the order we have defined.

I understand `isb` kills any speculation very badly today, given it
flushes the pipeline completely. That might be reason that replacing
`isb` by `sb` makes the operation 20%.

iThis is what the `isb` manual[1] says:

 > An ISB flushes the pipeline and ensures that the effects of any
 > completed context-changing operation before the ISB are visible to
 > any instruction after the ISB

[1] https://developer.arm.com/documentation/100941/0101/Barriers

> On some implementation, this can be have a similar effect (drain the
> fetch queue, restart). But the intent clearly isn't the same, and some
> implementations may do things differently.

Let me back-up to `isb` purpose in such case (before reading CNTVCT_EL0).

>From my understand, it severs two propositions:

1) Make sure that the code after the `mrs CNTVCT_EL0` is not executed
   out-of-order before the read
 
2) Code that comes before the the CNTVCT_EL0 read retires before the
   read.

If I understand what `sb` does, it only protects against 1) but not 2).
Is this the right way to understand it?

Thanks for you time,
--breno