Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

zeVirtualMemMap of one physical object into a second VA range returns SUCCESS, then access through it gives ZE_RESULT_ERROR_DEVICE_LOST (Arc Pro B60)

未关闭
  • 哪里不对？
#1,024 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
15/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
cpp
领域
hpc

调研方向

The payload names no source files, only the standalone repro l0_alias_repro.cpp and the calls zeVirtualMemMap, zePhysicalMemCreate and zeCommandListAppendMemoryCopy. Build the repro against the Level Zero loader and confirm the 0x70000001 result on the second range. Done means a decision on whether the second map should fail or the alias should work, which the thread has not yet made. This is driver memory-management work and needs maintainer input before any change.

由索引模型根据 Issue 内容生成。

描述

Moved from oneapi-src/level-zero#536 at the maintainers' request.

Summary
Mapping the same ze_physical_mem_handle_t into two reserved virtual ranges succeeds (both zeVirtualMemMap calls return ZE_RESULT_SUCCESS). A write through the first range completes, but the first access through the second range fails with ZE_RESULT_ERROR_DEVICE_LOST (0x70000001). From SYCL/PyTorch kernels the same access hangs instead. The spec does not say a physical object may be mapped only once, so either the second map should fail, or the alias should work.

Repro (single file, l0_alias_repro.cpp):

l0_alias_repro.cpp 
// Level Zero: one physical memory object mapped into two virtual ranges.
// Writes through range A, then reads through range B with an immediate command list.
// Build: g++ -O1 l0_alias_repro.cpp -I/usr/local/include -L/usr/local/lib -lze_loader -o l0_alias_repro
#include <level_zero/ze_api.h>
#include <cstdio>
#include <cstdlib>
#include <cstring>
#include <vector>

#define CHECK(call)                                                       \
  do {                                                                    \
    ze_result_t r = (call);                                               \
    if (r != ZE_RESULT_SUCCESS) {                                         \
      std::printf("%s failed: 0x%x\n", #call, (unsigned)r);              \
      std::exit(1);                                                       \
    }                                                                     \
  } while (0)

int main() {
  CHECK(zeInit(ZE_INIT_FLAG_GPU_ONLY));
  uint32_t n = 1;
  ze_driver_handle_t driver;
  CHECK(zeDriverGet(&n, &driver));
  n = 1;
  ze_device_handle_t device;
  CHECK(zeDeviceGet(driver, &n, &device));
  ze_context_desc_t ctx_desc = {ZE_STRUCTURE_TYPE_CONTEXT_DESC, nullptr, 0};
  ze_context_handle_t ctx;
  CHECK(zeContextCreate(driver, &ctx_desc, &ctx));

  size_t page = 0;
  CHECK(zeVirtualMemQueryPageSize(ctx, device, 2 << 20, &page));
  ze_physical_mem_desc_t pdesc = {ZE_STRUCTURE_TYPE_PHYSICAL_MEM_DESC, nullptr, 0, page};
  ze_physical_mem_handle_t phys;
  CHECK(zePhysicalMemCreate(ctx, device, &pdesc, &phys));

  void *va_a = nullptr, *va_b = nullptr;
  CHECK(zeVirtualMemReserve(ctx, nullptr, page, &va_a));
  CHECK(zeVirtualMemReserve(ctx, nullptr, page, &va_b));
  CHECK(zeVirtualMemMap(ctx, va_a, page, phys, 0, ZE_MEMORY_ACCESS_ATTRIBUTE_READWRITE));
  CHECK(zeVirtualMemMap(ctx, va_b, page, phys, 0, ZE_MEMORY_ACCESS_ATTRIBUTE_READWRITE));
  std::printf("page=%zu va_a=%p va_b=%p: both maps returned SUCCESS\n", page, va_a, va_b);

  ze_command_queue_desc_t qdesc = {ZE_STRUCTURE_TYPE_COMMAND_QUEUE_DESC, nullptr, 0, 0, 0,
                                   ZE_COMMAND_QUEUE_MODE_ASYNCHRONOUS, ZE_COMMAND_QUEUE_PRIORITY_NORMAL};
  ze_command_list_handle_t list;
  CHECK(zeCommandListCreateImmediate(ctx, device, &qdesc, &list));

  std::vector<unsigned char> src(page, 0x5a), dst(page, 0);
  CHECK(zeCommandListAppendMemoryCopy(list, va_a, src.data(), page, nullptr, 0, nullptr));
  CHECK(zeCommandListHostSynchronize(list, UINT64_MAX));
  std::printf("write through va_a: done\n");
  std::fflush(stdout);

  CHECK(zeCommandListAppendMemoryCopy(list, dst.data(), va_b, page, nullptr, 0, nullptr));
  // 10 s timeout: on Arc Pro B60 this read never completes
  ze_result_t r = zeCommandListHostSynchronize(list, 10ull * 1000 * 1000 * 1000);
  std::printf("read through va_b: result=0x%x, data %s\n", (unsigned)r,
              r == ZE_RESULT_SUCCESS ? (std::memcmp(src.data(), dst.data(), page) ? "WRONG" : "ok")
                                     : "not available");
  return r == ZE_RESULT_SUCCESS ? 0 : 2;
}

g++ -O1 l0_alias_repro.cpp -I/usr/local/include -L/usr/local/lib -lze_loader -o l0_alias_repro
ZE_AFFINITY_MASK=0 ./l0_alias_repro

Output:

page=2097152 va_a=0x7af6a2000000 va_b=0x7af6a1c00000: both maps returned SUCCESS
write through va_a: done
zeCommandListAppendMemoryCopy(list, dst.data(), va_b, page, nullptr, 0, nullptr) failed: 0x70000001

Expected: the read through va_b returns the bytes written through va_a (as cuMemMap allows on CUDA), or the second zeVirtualMemMap returns an error.

Environment

  • GPU: Intel Arc Pro B60 (Battlemage G21), xe kernel driver, kernel 6.14.0-37-generic
  • compute-runtime (libze-intel-gpu1): 26.18.38308.1
  • Level Zero loader: 1.28.0
  • OS: Ubuntu 25.04

Impact: SGLang's DWDP (expert-weight prefetch for MoE) has to unmap and remap pool pages before every layer on Level Zero instead of aliasing them, which costs a host synchronisation per layer (sgl-project/sglang#40763).

主要语言
C++
星标
1.5k
派生
303
30 天内没有已合并 PR

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

intel/compute-runtime 的其他 Issue

查看 intel/compute-runtime 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。