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)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 15/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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).
- Lenguaje dominante
- C++
- Estrellas
- 1.5k
- Forks
- 303
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de intel/compute-runtime
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
intel/compute-runtime#943 ·
-
【资源分享】Gemini Pro 稳定号(高质量已过验证反重力)Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 1/100
intel/compute-runtime#1022 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
intel/compute-runtime#1019 ·
-
OS: Linux Type: Bug
Dificultad 4/5 3-5 días Aptitud para principiantes 34/100
intel/compute-runtime#1017 ·
-
OS: Linux Type: Bug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
intel/compute-runtime#1016 · 3 comentarios ·
Todos los issues de intel/compute-runtime
Issues similares
-
os:Linux
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
acceptable_buffer_backends: unknown backend names are silently ignoredPosiblemente ocupada @mini-1235 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
ros2/rmw_fastrtps#945 ·
Los mantenedores suelen responder en 1 día
-
bot-triaged module: correctness (silent) module: mps module: NaNs and Infs triage review
Dificultad 2/5 Medio día Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
README: CI link/badge checkAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
SCIInstitute/SCIRun#2842 ·
Los mantenedores suelen responder en 3 días