Add: kernel callable registration and generation guards

[YunjiQin]

Each successful kernel prepare_callable call uploads and registers a new callable and returns a fresh context-local SimplerCallableHandle {callable_id, generation}, even when both the content and input pointer match an earlier call. The caller owns handle reuse and content deduplication; simpler does not search existing content or return a previous handle.

Registrations occupy independent device addresses and consume independent slots and bytes in a 64-slot, 512 MiB resident arena. The 65th registration is rejected even for identical content. Capacity failures preserve existing handles, and launch rejects missing or stale handles. There is no eviction or slot reuse. The runtime registration bridge consumes only the current pending upload, never an old hash-matched image.

A separate simpler_aicpu_kernel_exec entry validates the current device residency before entering the payload consumer. Production-entry UT covers stale snapshots after a slot generation change.

Dependencies and scope

• Depends on Add: persistent kernel-context execution resources (K2) #2176 (K2), which depends on Add: kernel-mode C ABI skeleton and wire headers (K1) #2064 (K1). This draft retains the tested K2 base 48b120b1; dependency commits are separate from the K10a commit.
• K10a-only diff: review the independent commit.
• K2's asynchronous preparation changes are outside this PR; existing preparation synchronization is unchanged.
• Program-mode registration retains its existing behavior.
• Host binder and runtime-specific payload execution remain unconnected. The production payload consumer returns UnsupportedPayload, and kernel support remains disabled. Device-entry validation is covered by CPU UT; real-device ACLGraph replay and its CANN error propagation are not yet validated.
• Chinese call-chain documentation: docs/zh-cn/kernel-callable-residency.md.

Validation

• All pre-commit checks pass.
• Seven relevant C++ test targets pass. Repeated identical content produces distinct IDs and device addresses, counts toward both limits, and cannot be admitted when full.
• Callable-cache tests pass ASan/UBSan; dispatch tests also passed ASan/UBSan.
• Python/C ABI/callable-identity regression: 114 passed, 36 skipped.
• A3 onboard kernel C ABI tests: 28 passed, 16 deselected. Both runtimes register identical content 64 times, return IDs 0–63, and report 64 dlopens before rejecting another registration.
• All eight runtime build combinations succeed. The AICPU entry is exported for both architectures, backends, and runtimes.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.}

[nalinaly]

请调整 callable 驻留容量及 device 内存分配方式：8192 项规格，参考 CANN 的 2 MiB 分块按需增长。具体意见见行内评论。

[nalinaly]

建议将 kernel 模式的驻留 callable 容量规格调整为 8192，并将条目规格与 device 内存预分配解耦。

当前实现存在两个问题：第 65 个不同 callable 会在仍有可用 device 内存时被拒绝；第一个很小的 callable 也会触发约 512 MiB 的 arena 分配。仅把 64 调大、继续保留这个 arena 模型，不能满足大量 kernel 按需注册的场景。

建议本 PR 按以下规格修改：

1. 最多支持 8192 个不同的驻留 callable。 需要同步处理 Host cache/resolve、runner、A2A3/A5 AICPU 注册表和 Device dispatch 的相关边界，不能只修改 cache 一处；8192 是条目容量规格，不代表预分配 8192 套 device 执行资源。
2. Device 内存按实际驻留需求申请。 可参考 CANN runtime 的 2 MiB 分块池：小镜像在已有块内子分配，空间不足才追加新块；超过单块大小的镜像按实际大小加必要对齐独立分配。2 MiB 是共享分配块的粒度，不是每个 callable 至少占 2 MiB。取消固定 512 MiB 首次预留，按需增长。
3. 驻留代码缓存的 device 总容量上限暂定为 2 GiB。 这是容量上限，不是首次预分配量；仍按上述方式按需申请。达到 8192 项或 2 GiB 容量上限时返回明确的容量错误，不影响已经成功驻留的条目。
4. 扩容只追加，不迁移已发布的代码和 descriptor。 保持已有地址及 handle 有效；新增分配、上传和注册仍放在 capture 外的 prepare，launch/replay 不承担扩容工作。

Host 内存目前不是本条 review 的关注点，现有 Host 镜像保留方式可以不改。

参考 CANN 官方源码：BinaryLoad 按实际加载大小分配、2 MiB 单池定义、池不足时追加新池。