Re: [RFC PATCH 0/6] Xenomai: Real-time Exception Handling

[Philippe Gerum <rpm@xenomai.org>]

Hi Richard,

Richard Weinberger <richard@sigma-star.at> writes:

> On Dienstag, 8. April 2025 19:32 Jan Kiszka wrote:
>> > real-time.  A notable example is a page fault, determining whether
>> > SIGSEGV is appropriate requires deep traversal into the memory
>> > management code.
>> 
>> ...on arm and arm64. It worked fairly well for x86. This is indeed a
>> very prominent exception that people may expect behind this feature. And
>> it is also a use case we have with our (x86-only) deployment.
>
> True that.
> I think the set of supported exceptions should be architecture specific
> anyways. And we need to state that it is best effort.
>
>> 
>> > 
>> > Patches 1, 2, 3, and 4 implement the Xenomai-side changes for this
>> > feature.  Dovetail will receive a separate patch set. Patches 5 and 6
>> > introduce tests.
>> > 
>> > It is important to note that this is not a fully-fledged signal
>> > implementation.  The only supported use case is delivering exceptions
>> > as signals to the affected thread.
>> > There is no support for sending signals or handling block/ignore masks.
>> > The only user visible API so far is cobalt_rt_signal().
>> > It takes a signal number (SIGILL or SIGFPE so far) and a handler
>> > function with the signature fn(int, siginfo_t *, void *).
>> 
>> Did you intentionally left out the oldact parameter of sigaction?
>
> Not really. Adding this should be trivial.
> Maybe my subconsciousness tried to make it less look like POSIX
> real time signals. ;-)
>
>> 
>> > 
>> > TODO:
>> > - Better naming, IMHO "signal" is the wrong term and will confuse users.
>> >   Especially since POSIX real-time signals are something different.
>> >   Maybe "umex" for "user mode exception handling"?
>> 
>> Just "exception" might be enough and clearer. OTOH, we are reusing a lot
>> of sigaction and siginfo...
>
> That's the problem. It kinda looks like signals but isn't.
>

Indeed. This rather looks like the handling side of the full exception
offloading path to me. That was the point of introducing the
mark_cond_trap_{entry, exit}() helpers. As you already know, when
notified of a trap, the companion core may decide _not_ to downgrade the
caller in-band, causing the regular low-level exception handlers to
assume that no more fix up is required.

>> 
>> > - Document new APIs
>> > - Improve tests
>> > - Carefully select more exceptions
>> 
>> Yeah, that is the challenge.
>> 
>> And:
>> 
>>  - align with EVL / Xenomai 4 to ensure compatible features
>
> Agreed.
> The dovetail side is rather small. We could also integrate the signal frame
> helper functions into Xenomai.
>

I may be stating the obvious, but with hindsight, there is a basic
trade-off we have to do for fully offloading the exception handling over
the oob stage, based on the past experience with dealing with the
arch-specific code in Xenomai 3 + I-pipe:

- the more we ask the companion core (i.e. cobalt / evl) to implement
  processor and/or standard abi-specific bits, the more we risk nasty
  bugs over time. Typically, maintaining a duplicate fpu and context
  switching code into the cobalt core during the I-pipe years has been
  an excruciating nightmare, compared to the current state with Dovetail
  which oob-enables the upstream code instead, presenting a complete
  task switching service to the core. This can be extended to
  implementing any duplicate/simplified version of an upstream routine
  on the regular kernel side for oob-specific use (for that reason, I'm
  not fond of the idea of copy&pasting in part the sigframe setup
  code). IOW, a plain and obvious conflict with some upstream change in
  a well-thought section of code shared between in-band and oob contexts
  is usually way safer than an oob-specific code mimicking (portions of)
  the in-band implementation living in parallel, since critical changes
  in the latter might go unnoticed.

- but, introducing oob-awareness in some in-band code is obviously more
  prone to merge conflicts, which might be another form of nightmare
  when the latter is a moving target on the upstream side, when it comes
  to tracking the kernel development tip.

To best decide, I agree with Jan that first and foremost, we need to
agree on an explicit feature set regarding exception offload to the
companion core including arch-specific issues/restrictions if any, so
that we may evolve the Dovetail implementation in the right direction in
this area. IIRC, we started a discussion on this list a couple of years
ago about this, for x86 at least.

-- 
Philippe.