Skip to content

Document the Cloud Agent host build - #195

Merged
aien-spark merged 6 commits into
mainfrom
cursor/cloud-agent-env-dee4
Oct 31, 2026
Merged

aien-spark merged 6 commits into
mainfrom
cursor/cloud-agent-env-dee4

Conversation

@drakestapleton

@drakestapleton drakestapleton commented Oct 30, 2026 •

Copy link
Copy Markdown
Contributor

Purpose and scope

Cloud Agent VMs are x86_64. CUDA++ host code uses the ARM dsb sy barrier, so the notes in AGENTS.md say how this VM builds and runs the host suite: aarch64 cc/gcc on /usr/local/bin, qemu-user for the binaries, pinned ../omega-mv and ../omega-bridge, and nvdisasm 13.0.85. They also say why /usr/local/bin/make sets CUDAPP_MEM_RESERVE_MIB=0 here, and that make doctor is expected to print NOT READY.

/usr/local/bin/make also registers qemu-user if the boot start hook did not. A fresh agent booted from the first draft build had no /tmp/cursor/start-user/ directory, and an aarch64 binary exited 126 (Exec format error) until binfmt was registered.

No product source, encoder, or runtime behavior changes.

Evidence on the exact commit

Host checks below ran on parent 78fea51 (these commits only add AGENTS.md). Machine: Linux x86_64, cross aarch64-linux-gnu-gcc 13.3.0, qemu-aarch64 8.2.2. uname -m in the shell is x86_64. Built binaries are aarch64 and run through qemu-user.

  • make test (host-only). Not one uninterrupted process. The first make test stopped at test-gpu-serving-alloc (exit 2): MemAvailable was under the default 4 GiB reserve, so the Qwen-shaped upload was refused. Targets before that stop had passed. With CUDAPP_MEM_RESERVE_MIB=0, that target and every later HOST_TESTS target were run again and make exited 0. That second run includes the 2^32 bf16 sweep, test-om-units, portable receipts, test-model-capacity, test-native-artifact, and zero-cuda-gate.
  • make test-native-artifact (host-only), inside the second run (native_artifact_manifest: 70 checks, 0 failed).
  • make zero-cuda-gate (ELF audit and negative control), inside the second run. ZERO_CUDA PASS for build/hello_gpu and build/gpu_matmul_api_test.
  • build/hello_gpu --sim (simulator only). PASS, 1048576 elements, 0 wrong. Machine-code sha256 9e28bd9c46f80584d77238a752e99cecddbc8d622ffbe320885ed2f499e1f075.
  • make doctor (diagnostic). NOT READY, exit 1: no NVIDIA module and no /dev/nvidia*. test-doctor reported doctor tests: 9 passed, 0 failed.
  • GB10 hardware tests, only if an authorized GPU window is available (otherwise NOT RUN). NOT RUN. This VM has no GB10.

python3 tools/figures/make_figures.py --check printed figures current: 10.

After removing the qemu binfmt entry, /tmp/aa-hello3 exited 126. make -f - then printed reserve=0, the interpreter was /usr/local/libexec/qemu-aarch64-sysroot, and the same binary exited 9.

Correctness, compatibility and provenance

  • Negative controls and affected contracts are documented. No contract change. The reserve note says not to copy CUDAPP_MEM_RESERVE_MIB=0 onto a Spark. The platform test still unsets the variable and checks the 4096 default.
  • API/ABI and Omega consumer effects are identified; source and runtime status claims are not overstated. None. Documentation only.
  • Third-party material, licensing, and public-history safety were checked for additions. No new third-party material in the tree. nvdisasm and the pinned omc stay outside the repository.
  • No secrets, personal machine paths, private addresses, other processes' logs, vendor binaries, or unauthorized generated artifacts were included.
  • Existing receipts remain immutable; new results have their own evidence folder. No receipt added.

Known limitations

make test was not a single process from the first target through the PASS line. The bf16 sweep under qemu is on the order of an hour. Chip tests were not run. A fresh agent from the first draft build did not run start; the make wrapper is the fallback that was checked locally.

Open in Web Open in Cursor 

The VM is x86_64, the sources need an aarch64 compiler and qemu-user, and MemAvailable under-reports, so the notes say where the pinned omc, bridge, and nvdisasm sit and why make sets CUDAPP_MEM_RESERVE_MIB=0.

Co-authored-by: Drake Stapleton <[email protected]>

@drakestapleton drakestapleton left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review of #195 at ef64e43. Classification: needs-changes (wording only; correct for main today, wrong once #192 lands).

1. Docs only: yes. One file is changed: AGENTS.md (+16/-0), a new "Cursor Cloud specific instructions" section added after L92. There are no build files, scripts, CI or code changes. The /usr/local/bin/make wrapper and the cross cc/gcc live on the VM image, outside the repo.

2. Overlap with #192 (6235ac1).

  • File: #192 also edits AGENTS.md, but only the hunk at L37-55. #195 appends after L92, so I expect no textual conflict. Neither PR changes the Makefile in a way that touches the other.
  • Reserve text: consistent. Both keep the 4096 default and use CUDAPP_MEM_RESERVE_MIB=0 only on this VM, and #195 adds "Do not copy that 0 onto a Spark". No contradiction.
  • Contradictions after #192 merges:
    • "/usr/bin/gcc cannot build them (CUDApp#15)": #192 makes x86-64 a supported portable host build.
    • "CC defaults to cc": true on main (CC ?= gcc at Makefile L17 does not override make's built-in). On x86-64, #192 sets CC := gcc.
  • Hazard: on this VM, /usr/local/bin/gcc is the aarch64 cross compiler, so after #192 a plain make on the Cloud VM still cross-builds aarch64 under qemu instead of exercising #192's x86-64 portable path. The section should say which suite the VM actually runs, or point CC at /usr/bin/gcc for the x86-64 portable check.
  • #192's x86-64 evidence used make CC=gcc. Which gcc that resolved to should be stated if it came from a VM with this image.

3. Overlap with #194 (458a448) and issue #193. No shared files. #194 adds test-gpu-imadhi-rc and test-dagsim to HOST_TESTS; #195 does not list targets, so it stays valid. #193 is an issue and nothing in #195 touches it.

4. Overlap with EL1 el/dra23-canonical-provenance. The branch is not visible (compare main...branch returns 404). The board's declared files are tools/canonical_provenance.om, tests/provenance/, evidence/CUDAPP-DRA23-PROVENANCE/ and a Makefile test-provenance target. None of these is AGENTS.md, so there is no overlap.

5. Build steps against the repo.

  • These match at head ef64e43 (same Makefile as main 78fea51):
    • OMEGA_MV ?= ../omega-mv, OMEGA_OMC ?= $(OMEGA_MV)/seed/out/omc and OMEGA_BRIDGE_DIR ?= ../omega-bridge (mk/om-encoder.mk L18-21).
    • om/omega-bridge.lock = 0c4cb9ff980af278890b231b994eaede4dc7621c, which matches the text.
    • The make test, test-gpu-serving-alloc, doctor, hello-gpu and zero-cuda-gate targets and the PASS-line wording match AGENTS.md L37+.
  • Not cross-checked against a repo pin: omega-mv e5b32567, the omc sha256 2c824805… and nvdisasm 13.0.85. Please cite where each is pinned (lock file or CI step), or label it as this VM's observed value.
  • At #192: the CC and gcc statements become wrong (see 2).

6. Hardware. GB10 is NOT_RUN, and the PR says so. Nothing ran on the Spark. make doctor NOT READY and hello_gpu --sim are host/simulator results only.

CI at ef64e43:

  • drift fails, and docs-only cannot cause that. This is consistent with the upstream drift already failing on main 78fea51.
  • host-tests and Analyze (c-cpp) were still running when I checked.
  • All other checks pass, and CodeQL is neutral.

Merge order: #194 → #192 (rebased; HOST_TESTS conflict) → #195, rebased last with the gcc/CC lines updated for #192's x86-64 behaviour.

— Grokbot

A fresh agent from the draft build had no /tmp/cursor/start-user directory, so aarch64 binaries failed with Exec format error until binfmt was registered. The first make now does that registration.

Co-authored-by: Drake Stapleton <[email protected]>
@aien-spark
aien-spark merged commit 9b3e44e into main Oct 31, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants