[Bug] a2a3 DFX paired buffers fail with halHostRegister 65534 on 64 KiB-page hosts

[Mewtwo-Jieyu]

Platform

a2a3 (Ascend 910B/C hardware)

Runtime Variant

tensormap_and_ringbuffer

Description

On a Linux aarch64 host configured with 64 KiB base pages, a2a3 DFX collectors cannot create their paired device/host buffers.

The base vector example passes without DFX. With --enable-dep-gen, the first 1,280-byte DepGen shared buffer is allocated by:

rtMalloc(&ptr, size, RT_MEMORY_HBM, 0);

and then registered by:

halHostRegister(dev_ptr, size, DEV_SVM_MAP_HOST, device_id, host_ptr);

The Driver reports support_bar_mem=0 and support_bar_huge_mem=1. The ordinary-page registration is rejected with DRV_ERROR_NOT_SUPPORT (65534).

This is not a general a2a3 execution failure: the same vector example passes without DFX, normal HBM rtMemcpy succeeds, and large 2 MiB / 4 MiB huge-page registrations have succeeded on the same host.

Steps to Reproduce

1. Confirm the Host page size and Driver capability:

getconf PAGESIZE

grep 'support_bar_mem' ~/ascend/log/run/plog/*.log

Observed:

65536

Device info. (... support_bar_mem=0; support_dev_mem_map_host=0;
support_bar_huge_mem=1; ...)

2. Install Simpler and run the base example:

python -m pytest \
  examples/a2a3/tensormap_and_ringbuffer/vector_example/test_vector_example.py \
  --platform a2a3 \
  --device 0 \
  -s

Observed:

1 passed

3. Enable DepGen:

python -m pytest \
  examples/a2a3/tensormap_and_ringbuffer/vector_example/test_vector_example.py \
  --platform a2a3 \
  --device 0 \
  -s \
  --enable-dep-gen

Expected Behavior

a2a3 DFX collectors should work on supported hardware with either 4 KiB or 64 KiB Host base pages.

When ordinary-page BAR mapping is unavailable but huge-page BAR mapping is supported, Simpler should select a compatible allocation or transfer strategy instead of assuming that every rtMalloc(..., RT_MEMORY_HBM, 0) buffer can be registered with DEV_SVM_MAP_HOST.

The existing 4 KiB-page path should not regress.

Actual Behavior

ProfilerBase::alloc_paired_buffer: register_cb_ failed: 65534
DepGenCollector: failed to allocate dep_gen shared memory (1280 bytes)
init_dep_gen failed: -1
RuntimeError: run failed with code -1

The CANN Driver log reports:

Not support pcie bar remote map. (svm_addr=...; devid=0)

Git Commit ID

23dbb86fdaf5b93c3585da01aa521c640198a416

The failure was reproduced on this commit. As of c440a5dd1d4a78545290986d72cff54f13dd3b0e, static source inspection shows the same rtMalloc(..., RT_MEMORY_HBM, 0) plus halHostRegister(..., DEV_SVM_MAP_HOST, ...) path, but that newer commit has not been rerun on the affected host.

CANN Version

9.0.1

The relevant rtMalloc allocation and PcieHostRegister paths are unchanged between the public Runtime v9.0.0 and v9.0.1 tags.

Driver Version

26.0.rc1

ascendhal_version=7.35.23

Host Platform

Linux (aarch64), Kunpeng, 64 KiB base pages.

Additional Context

The Driver capability logic initializes the two capabilities differently:

feature_bar_mem =
    ((device_page_size == host_page_size) && support_wc)
        ? device_feature_bar_mem
        : 0;

feature_bar_huge_mem =
    support_wc ? device_feature_bar_mem : 0;

The observed combination:

support_bar_mem=0
support_bar_huge_mem=1

therefore indicates that the underlying BAR capability exists, but ordinary-page BAR mapping is disabled because the Host and Device page sizes do not match.

The first DepGen buffer is only 1,280 bytes. Runtime uses the ordinary-page allocation path for allocations at or below its 1 MiB huge-page threshold, so devmm_dev_svm_map_para_check() rejects the subsequent registration.

Relevant source:

• Simpler allocation:
  https://github.com/hw-native-sys/simpler/blob/23dbb86fdaf5b93c3585da01aa521c640198a416/src/a2a3/platform/onboard/host/memory_allocator.cpp
• Simpler DFX registration callbacks:
  https://github.com/hw-native-sys/simpler/blob/23dbb86fdaf5b93c3585da01aa521c640198a416/src/a2a3/platform/onboard/host/device_runner.cpp
• Paired-buffer allocation:
  https://github.com/hw-native-sys/simpler/blob/23dbb86fdaf5b93c3585da01aa521c640198a416/src/common/platform/include/host/profiler_base.h
• CANN Driver BAR capability initialization:
  https://gitcode.com/cann/driver/blob/9.0.0/src/sdk_driver/svm/v2/master/comm/svm_master_dev_capability.c
• CANN Driver remote-map check:
  https://gitcode.com/cann/driver/blob/9.0.0/src/sdk_driver/svm/v2/master/pmaster/svm_master_remote_map.c
• CANN Runtime allocation:
  https://gitcode.com/cann/runtime/blob/v9.0.1/src/runtime/feature/src/drv/npu_driver_mem.cc

Possible implementation directions, without prescribing one:

1. Use an explicit huge-page allocation policy for DFX paired buffers when ordinary BAR mapping is unavailable but huge-page mapping is supported.
2. Use a Host shadow plus explicit copy transport, similar to the existing non-SVM collector path.
3. Add a capability check and actionable diagnostic if neither transport is available.

Related: #1253, which unified the collector allocation/transport abstraction, but did not address 64 KiB Host-page compatibility.

Suggested acceptance coverage:

• DepGen passes on an a2a3 Linux aarch64 Host with 64 KiB base pages.
• Existing 4 KiB-page behavior remains unchanged.
• L2 Swimlane, ArgsDump, PMU, DepGen, and ScopeStats paths sharing the same registration mechanism are covered.