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)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 15/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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),
xekernel 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).
- Ngôn ngữ chính
- C++
- Star
- 1.5k
- Fork
- 303
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của intel/compute-runtime
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
intel/compute-runtime#943 ·
-
【资源分享】Gemini Pro 稳定号(高质量已过验证反重力)Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 1/100
intel/compute-runtime#1022 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
intel/compute-runtime#1019 ·
-
OS: Linux Type: Bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 34/100
intel/compute-runtime#1017 ·
-
OS: Linux Type: Bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
intel/compute-runtime#1016 · 3 bình luận ·
Tất cả issue của intel/compute-runtime
Issue tương tự
-
os:Linux
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
acceptable_buffer_backends: unknown backend names are silently ignoredCó thể đã có người làm @mini-1235 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
ros2/rmw_fastrtps#945 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bot-triaged module: correctness (silent) module: mps module: NaNs and Infs triage review
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
README: CI link/badge checkĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
SCIInstitute/SCIRun#2842 ·
Maintainer thường phản hồi trong vòng 3 ngày