Add: adopt #2185's kernel entry hardening on the integration line

[YunjiQin]

Summary

D15 took only the test hardening from #2185's refreshed head and deferred the
rest as accompanying a signature change; D16 has since adopted that signature
independently. What is left is no longer a signature question, and one part of
it closes a real leak.

The leak. ChipWorker::kernel_init dropped the device context on any
refused init, on the stated ground that a refused kernel init "has adopted
nothing — it took no ACL state and bound no thread". That is false here:
init_kernel_context acquires the context claim, then
kernel_exec_state_.initialize creates two streams and five events, and the
four steps after it — ensure_binaries_loaded, ensure_aicpu_init_launched,
prepare_launch_shape, prepare_aicpu_affinity — each return a failure without
unwinding them; only the claim has a rollback guard. A refusal from any of them
therefore reached ChipWorker with live resources, where
destroy_device_context refuses the context and returns void, and the
DlHandleGuard then dlcloses the library whose release routines are the only
way back to them.

What this adopts

• ChipWorkerError carries a PTO_RUNTIME_ERR_* code, and
  UnsupportedRuntimeOperation derives from it. The nanobind layer registers
  both with translators that copy the code onto the Python exception, and
  exports the codes as module attributes. The registered
  UnsupportedRuntimeOperation also subclasses NotImplementedError, so
  device_memory_info's ad-hoc conversion is deleted rather than duplicated —
  existing except NotImplementedError callers are unaffected.
• A refused kernel init calls finalize_device first. When that fails the
  handle, the bindings and the library all stay, device_teardown_owed_ is
  recorded, and no later init runs until a finalize() succeeds.
  INVALID_ARGUMENT and UNSUPPORTED skip the teardown: the entry returns them
  before taking anything.
• kernel_mode_supported() answers instead of throwing — false whenever no
  runtime is bound, which initialized() already distinguishes from a bound
  runtime without kernel support.
• A failed finalize() on a kernel context raises and is retriable. The
  Python wrapper's registries already documented that behaviour for a raising
  finalize that could not yet happen.
• Kernel callables get their own registry. _callable_registry keys are
  program slots that init() replays into register_callable and that
  _allocate_slot_locked reads as occupancy; a runtime-minted kernel id has
  neither meaning.
• Sixteen Python cases in tests/ut/py/test_chip_worker.py, plus the C++
  and Python entry-test updates.

Kept against #2185

Four places where this line is right and #2185's head is an artifact of its own
stub platform:

• the D14 item 6 capability gate stays, so the adopted fake runtimes declare
  kernel support to reach the entry behind it;
• a program-mode teardown status is reported on stderr rather than dropped —
  the runner gives up its device either way, so there is nothing to retry, but
  the status is the only evidence;
• kernel_init succeeding is the a2a3 case, so the hardware test keeps the
  live-context scenario;
• the Python twin keeps loading host_build_graph for a genuine UNSUPPORTED.

Decisions are D20 in the integration log.

Testing

Ran twice — once on 29a1cd40, then again after rebasing onto 4a5f28c9
(which carries the merged #2245 and #2242).

• Native builds: a2a3, a5, a2a3sim, a5sim, nanobind extension — all succeeded
• C++ unit tests, no hardware — 166/166 passed
• C++ unit tests with SIMPLER_ENABLE_HARDWARE_TESTS=ON — the two added no-hardware targets passed
• a2a3 hardware, test_kernel_mode_entry with a CTest resource spec — passed
• Python unit tests, tests/ut -m "not requires_hardware" — 2448 passed (baseline + the 16 new cases)
• Python hardware unit tests, tests/ut -m requires_hardware --platform a2a3 — 21/21 scheduled cases passed
• a2a3sim scenes — 82 passed, 8 skipped (baseline exact)
• pre-commit hooks on changed files — passed

Hardware work passed the architecture precheck and acquired devices through
task-submit --device auto. Not re-run: the a2a3 onboard scene phases, the SDMA
phase, a5sim scenes, and tests/ut/py/test_kernel_mode_c_api.py — the change is
confined to the ChipWorker entry layer, its bindings and its tests, and does
not reach the platform entries those suites exercise.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: e3b53e7c-f278-48e2-bb83-9f0b36e3df8a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}