On Thu, Oct 24, 2024 at 6:11 AM Vadim Fedorenko
<vadim.fedorenko@xxxxxxxxx> wrote:
>
> > static inline u64 __arch_get_hw_counter(s32 clock_mode,
> > const struct vdso_data *vd)
> > {
> > if (likely(clock_mode == VDSO_CLOCKMODE_TSC))
> > return (u64)rdtsc_ordered() & S64_MAX;
> >
> > - & is missing
>
> & S64_MAX is only needed to early detect possible wrap-around of
> timecounter in case of vDSO call for CLOCK_MONOTONIC_RAW/CLOCK_COARSE
> which adds namespace time offset. TSC is reset during CPU reset and will
> not overflow within 10 years according to "Intel 64 and IA-32
> Architecture Software Developer's Manual,Vol 3B", so it doesn't really
> matter if we mask the highest bit or not while accessing raw cycles
> counter.
>
> > - rdtsc vs rdtscp
>
> rdtscp provides additional 32 bit of "signature value" atomically with
> TSC value in ECX. This value is not really usable outside of domain
> which set it previously while initialization. The kernel stores encoded
> cpuid into IA32_TSC_AUX to provide it back to user-space application,
> but at the same time ignores its value during read. The combination of
> lfence and rdtsc will give us the same result (ordered read of TSC value
> independent on the core) without trashing ECX value.
That makes sense.
One more thing:
> __bpf_kfunc int bpf_get_hw_counter(void)
it should be returning u64
> >> + insn->imm = 0;
> >> + insn->code = BPF_JMP | BPF_CALL;
> >> + insn->src_reg = BPF_PSEUDO_KFUNC_CALL;
> >> + insn->dst_reg = 1; /* Implement enum for inlined fast calls */
> >
> > Yes. Pls do it cleanly from the start.
> >
> > Why rewrite though?
> > Can JIT match the addr of bpf_get_hw_counter ?
> > And no need to rewrite call insn ?
>
> I was thinking about this way, just wasn't able to find easy examples of
> matching function addresses in jit. I'll try to make it but it may add
> some extra functions to the jit.
func = (u8 *) __bpf_call_base + imm32;
if (func == &bpf_get_hw_counter)
