Re: [PATCH v2 0/3] rv: per-edge dwell-time statistics for per-cpu monitors

[Gabriele Monaco <gmonaco@redhat.com>]

On Wed, 2026-10-14 at 21:27 +0200, Tobias Schaffner wrote:
> Nothing generates NMIs. But from the linux kernel's point of view any
> activity of the companion core is NMI-like, since disabling interrupts
> from the linux kernel does not stop it from running.
> 
> Our co-kernel keeps control of the real interrupt mask, so Linux cannot
> delay it. Most of the time what Linux disables and enables is a virtual
> mask instead of the real one.
> 
> Tracing already works inside EVL, thanks to a downstream patch [1]. It
> is mainly fixing all the points that rely on interrupt masking by
> calling the correct wrappers.
> 
> I would expect that we have to do similar for BPF. Some of the checks
> already exist to cope with NMIs and we would just have to make it
> recognize our stage too.
> 
> [1] 
> https://gitlab.com/Xenomai/linux-dovetail/-/commit/2fc39d2bb5d9ca1c0e898794fc0297eb04cf67d9
> 

Nice, thanks for sharing. Yeah you probably need to do similar things here and
there for BPF too, but perhaps some things (e.g. tracepoints) would be reused.

> You are clearly much more into the topic than I am. I will have to take
> a closer look to better understand the BPF data structures and,
> especially, their locking mechanisms before I can answer this.
> 
> My use case is, so far, not that strict. It is more that the bigger the
> tool gets, the harder it becomes to argue that it does not change the
> behavior of the system under test. If the tool remains simple in the end
> and I can describe its behavior as deterministic, there will be no issue.

...

> It sounds to me that you think about moving the complete RV system to
> BPF. Is this correct? In the end I will try to follow if you decide to
> go down the BPF route. Possibly after some delay but nevertheless.

Frankly, I wanted to keep both representations and I'm designing the BPF series
to share code and keep both in-kernel and BPF maintainable.

But this was mainly under the assumption that some use-cases would still require
in-kernel and/or BPF wouldn't be able to do everything we need with the same
quality/speed/determinism.

Now, I'm still assessing it but it seems BPF is good enough, at least for the
use-cases I tested, this assessment is going to take time as well.

For the time being in-kernel is surely going to stay and I'd really value
external opinion bringing other points on why it should not go away. I know the
industrial/automotive use-cases are the strictest and if BPF doesn't fit there,
I wouldn't drop in-kernel support.

So now it's the time to line out and validate all requirements.

> Should I wait with proposing a v3 of this patch set until you made a
> final decision or do you want to merge this in the current RV system no
> matter how this develops?

The good thing about your series is that you're using very few dependencies,
just like DA monitors. This makes it straightforward to use your header directly
in BPF with minimal modifications.
I'd say, continue your work towards a v3 and in the meanwhile I'll try and see
how to align your changes to be easily usable in BPF.

Realistically, DA monitor support won't reach upstream before the end of the
year and after that I'd need to do the same work for LTL and HA. That's going to
be more complex.
Only then, if everything is really smooth, we're going to think if it makes
sense to migrate existing monitors and deprecate in-kernel ones.

In my opinion, your contribution stays relevant either way.

Thanks,
Gabriele