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

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