Resolve host-orchestrator tensor access through a host view

[ChaoWao]

Summary

host_build_graph runs the orchestrator on the host, where Tensor::buffer.addr is a device address. get_tensor_data / set_tensor_data dereferenced it directly, which is only valid because a2a3 maps device buffers into the host address space and returns an identity VA. That made a platform capability an unstated precondition of the runtime.

Staging now registers a host view per tensor and the orchestrator resolves addresses through it:

Platform reports	Host view	Write path
a host map (a2a3 SVM, sim)	the device buffer itself	in place, as before
no host map	the staging copy	mirror + copy_to_device push-back
nothing covers the address	fatal	fatal

• Fail closed. A nullptr from register_device_memory_to_host previously passed the staging check, and the orchestrator then dereferenced a raw device address — a segfault or silent corruption instead of a failed prepare. An address in no registered region is now a fatal that names the tensor kinds with no host view (runtime-created, child memory).
• A non-identity host VA is now usable rather than a hard prepare failure, since nothing assumes buffer.addr is the host address.
• The AICPU build is unchanged. The read/write pair carries weak+hidden fallbacks in the runtime translation unit that dereference the address directly, so the AICPU build — which compiles this path but never runs an orchestrator — links without the host .cpp. This is the same idiom pto_orchestrator.cpp already uses for the dep_gen and scope-stats hooks. Verified by objdump: the host .so carries the registry body, the AICPU .so carries the two-line memcpy.

Registrations are valid only for the orchestration window — between staging and the first dispatched task, so a mirror cannot be stale. host_tensor_access_reset bounds it at both ends.

New files: runtime/host_tensor_access.h, host/host_tensor_access.cpp, tests/ut/cpp/a2a3/test_hbg_tensor_access.cpp.

Why

This is a prerequisite for giving a5 the host-orchestrated host_build_graph: a5 has no host-map path, so DeviceRunnerBase::register_device_memory_to_host returns nullptr there and the current code would fault inside the orchestrator. It also closes the latent failure on a2a3 should halHostRegister ever fail at runtime.

Note that a per-access rtMemcpy is deliberately not how the no-host-map case is served — that was the earlier host_d2h_read hook, and paged_attention re-reads block_table inside its q_loop, so its large cases issue on the order of 10^4–10^5 element reads.

Testing

The mirror path has no reachable call site on a2a3, so it was exercised two ways: the new unit tests, and a temporary experiment forcing DeviceRunner::register_device_memory_to_host to return nullptr, under which paged_attention (control-tensor reads) and available_aicore_counts (writes with push-back) both pass on hardware. That experiment is not part of this branch.

• a2a3 onboard sweep (tests/st/a2a3 + examples/a2a3, both runtimes, -m "not sdma") — 51 passed
• — of which host_build_graph — 21 passed, 1 skipped
• a2a3sim host_build_graph — 17 passed, 4 skipped
• cpput — 75 passed (10 new test_hbg_tensor_access cases, the only place the mirror path runs in CI)
• ut-py — 1034 passed, 9 skipped
• pre-commit — clang-format / clang-tidy / cpplint / check-headers all pass

All suites re-run after rebasing onto #1587.

[coderabbitai]

Warning

Review limit reached

@ChaoWao, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 27 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 08b41b0c-1a6f-4096-9c7a-bd1ad771a36a

📥 Commits

Reviewing files that changed from the base of the PR and between 2a650f2 and c74a8d5.

📒 Files selected for processing (6)

• src/a2a3/runtime/host_build_graph/host/host_tensor_access.cpp
• src/a2a3/runtime/host_build_graph/host/runtime_maker.cpp
• src/a2a3/runtime/host_build_graph/runtime/host_tensor_access.h
• src/a2a3/runtime/host_build_graph/runtime/orchestrator_core/pto_runtime2.cpp
• tests/ut/cpp/CMakeLists.txt
• tests/ut/cpp/a2a3/test_hbg_tensor_access.cpp

---

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