DeepSpeed

36b2ab3b - XPU: register pinned host memory via Level Zero ext_memmap (#8887)

XPU: register pinned host memory via Level Zero ext_memmap (#8887) ## Motivation DeepSpeed's native pin-memory path (`DS_PIN_MEMORY_BACKEND=native`) currently has no device registration on XPU — `register_host_memory()` returns `False`, so pinned host buffers are mlock-only and device access to them does not go through device page-table mappings. This PR implements the L0 equivalent of `cudaHostRegister` on the XPU accelerator. ## Implementation - `XPU_Accelerator.register_host_memory()`: map existing host memory into the device's page tables via Level Zero's external host-memory mapping (`zeMemAllocHost` with the `ZE_extension_external_memmap_sysmem` descriptor chain), created in our own L0 context — device page tables are shared across the driver's contexts, so buffers registered here are accessible from torch's runtime as well. - `unregister_host_memory()` releases the mapping. - Graceful degradation: returns `False` when the L0 loader or the extension is unavailable. ## Tests Three monkeypatched unit tests in `tests/unit/v1/pin_memory/test_pin_memory.py` (same pattern as the existing CUDA/CPU/NPU tests — no XPU hardware needed in CI): - registration calls Level Zero with the correct descriptor chain (host desc -> `pNext` -> external memmap desc), address and size passthrough - a mapping that comes back at a different address is treated as a failed registration - failure paths return `False` rather than raising ## Operational notes - On multi-NUMA hosts, binding the process to the GPU's NUMA node (`numactl --cpunodebind=N --membind=N`) is recommended when registering large ranges. - `ulimit -l unlimited` (or an equivalent memlock limit) is required for large registrations; the DeepSpeed pin-memory path already checks and reports this. --------- Signed-off-by: Ma, Guokai <guokai.ma@intel.com>