feat: smp_call: added signaling call_req

This patch introduces `rt_smp_call_request` API to handle queued
requests across cores with user provided data buffer, which provides a
way to request IPI through a non-blocking pattern.

It also resolved several issues in the old implementation:
- Multiple requests from different cores can not be queued in the work
  object of the target core.
- Data racing on `rt_smp_work` of same core. If multiple requests came
  in turns, or if the call is used by the target cpu, while a new
  request is coming, the value will be overwrite.
- Memory vulnerability. The rt_smp_event is allocated on stack, though
  the caller may not wait until the call is done.
- API naming problem. Actually we don't provide a way to issue an IPI to
  ANY core in mask. What the API do is aligned to MANY pattern.
- FUNC_IPI registering to PIC.

Changes:
- Declared and configured the new `RT_SMP_CALL_IPI` to support
  functional IPIs for task requests across cores.
- Replaced the single `rt_smp_work` array with `call_req_cores` to
  manage per-core call requests safely.
- Added `_call_req_take` and `_call_req_release` functions for atomic
  handling of request lifetimes, preventing data race conditions.
- Replaced single event handling with a queue-based approach
  (`call_queue`) for efficient multi-request processing per core.
- Introduced `rt_smp_call_ipi_handler` to process queued requests,
  reducing IPI contention by only sending new requests when needed.
- Implemented `_smp_call_remote_request` to handle remote requests
  with specific flags, enabling more flexible core-to-core task
  signaling.
- Refined `rt_smp_call_req_init` to initialize and track requests
  with atomic usage flags, mitigating potential memory vulnerabilities.

Signed-off-by: Shell <[email protected]>

0 files changed, 0 insertions, 0 deletions