Feat: AICPU launch via dispatcher upload + Mode A type 2

[puddingfjz]

Summary

Two-phase architecture for loading AICPU kernels on CANN 9.0+ without tar.gz / sudo pre-deployment, and without per-task indirection through the dispatcher SO.

Bootstrap (per-DeviceRunner, idempotent across instances in a process)

Host bundles dispatcher SO bytes + runtime SO bytes into a single rtAicpuKernelLaunchExWithArgs (kernel_type = KERNEL_TYPE_AICPU_KFC) targeting CANN's preinstalled libaicpu_extend_kernels.so. libaicpu_extend_kernels dlopens our dispatcher and invokes its Init; the dispatcher reads the runtime SO bytes from extended DeviceArgs (new inner_so_bin / inner_so_len fields at offsets 120/128, which libaicpu_extend_kernels ignores) and writes them to:

/usr/lib64/aicpu_kernels/0/aicpu_kernels_device/simpler_inner_<fp>.so

…using sched-thread (HwHiAiUser) write permission. The dispatcher SO itself never lands at preinstall.

The runtime SO basename embeds an FNV-1a content fingerprint, so two host processes uploading the same runtime SO produce the same file. Writes go via atomic tmp+rename — no truncation window visible to concurrent aicpu_scheduler readers. A process-level fingerprint cache in LoadAicpuOp skips redundant libaicpu_extend_kernels invocations within a single host process — each runtime is bootstrapped at most once per process.

Per-task launches (direct Mode A type 2, no dispatcher hop)

Host calls rtAicpuKernelLaunchExWithArgs with kernel_type = KERNEL_TYPE_AICPU, so_name = "simpler_inner_<fp>.so", kernel_name = "simpler_aicpu_init" / "simpler_aicpu_exec". The main aicpu_scheduler dlopens the preinstall file on first invocation and caches the handle; subsequent launches reuse it.

No JSON descriptors, no rtsBinaryLoadFromFile / rtsFuncGetByName lifecycle, no global op registry, no per-launch handle bookkeeping.

Cleanup

• Removes BUILD_WITH_NEW_CANN CMake option and all ifdef branches.
• Deletes the legacy AicpuLoader stub (src/{a2a3,a5}/platform/onboard/host/aicpu_loader.{cpp,h}) — its only role was the OFF-path fallback and nothing tested that path.
• Skips so_info_ allocation on the new path (the runtime SO no longer reads device_args.aicpu_so_bin / aicpu_so_len). Saves ~inner-SO-size device memory per DeviceRunner; previously this accumulated across many ChipWorker/DeviceRunner instances and triggered AICORE OOM in long test sessions.
• Widens the aicpu_op_timeout regression test to accept the new error code surfaced by Mode A type 2 (the dispatcher / main aicpu_scheduler path can race the STARS watchdog and return 507018/507000 before the AICore stream sync emits 507046).

Why this design (vs. earlier Mode B)

Earlier revisions of this PR routed per-task launches through Mode B (rtsBinaryLoadFromFile + rtsFuncGetByName + rtsLaunchCpuKernel). Making Mode B work across multi-process / multi-runtime / long-test scenarios required several global-state workarounds (per-process JSON paths, opType collision avoidance via fingerprint suffix, atomic rename on preinstall writes). With Mode A type 2:

• per-task call carries its own (so_name, kernel_name) — no shared state
• no JSON descriptor on disk
• no global op-type registry
• no binary_handle_ / rtFuncHandle lifecycle
• per-call overhead is two strncpy + the syscall (irrelevant for µs–ms kernels)

The dispatcher SO + Mode A KFC bootstrap is the only thing we keep from the previous approach — it remains the cleanest way to get our runtime SO into the preinstall path without sudo.

Testing

• a2a3 vector_example: 10/10 sequential PASS, 8/8 4-way concurrent PASS
• All BUILD_WITH_NEW_CANN grep results across src/ = 0
• Net ~250 LOC removed (deleted aicpu_loader, removed ifdef gates)
• Dispatcher SO: ~14.5 KB (unchanged from previous iteration)

Fixes #356.

[gemini-code-assist]

Code Review

This pull request introduces an AicpuLoader abstraction to support both legacy and new CANN 7.0+ interfaces for launching AICPU kernels across the a2a3 and a5 platforms. The implementation includes build system updates, runtime JSON descriptor generation, and integration into the DeviceRunner. Feedback focuses on improving build portability by avoiding hardcoded architecture paths and enhancing the robustness of manual JSON construction. Additionally, the removal of a default parameter in the a2a3 platform's header is identified as a breaking change that violates cross-platform consistency. Suggestions were also made to reduce coupling in the kernel name mapping.