feat: Add AMD Instinct GPU isolation (GPU memory limiting + Computing unit (CU) partitioning)

[kenji-mido]

What would you like to be added:
AMD Instinct GPU isolation support — per-pod memory limiting and compute unit (CU) partitioning for AMD ROCm GPUs.

What type of PR is this?

/kind feature

After discussion, I will prepare for the code contribution.

What this PR does / why we need it:

I have a working prototype tested on AMD Instinct MI300X (192GB HBM3e) across ROCm 6.2, 7.0, 7.1, and 7.2. I'd like to discuss the approach before opening PRs.

HAMi-core (libvgpu): libamvgpu.so

• LD_AUDIT library intercepting HIP API calls
• hipMalloc/hipFree tracking with per-pod memory limits
• hipMemGetInfo virtualization (reports HAMi limit, not physical)
• Shared memory region for pod-level cumulative usage tracking with multiple processes in a pod.

HAMi (device-plugin + scheduler)

• AMD device plugin: amd.com/gpumem (MB) + amd.com/gpucores (CU count)
• CU bitmap scheduler for exclusive CU partitioning across pods
• ROC_GLOBAL_CU_MASK and LD_AUDIT injection into pods

Why LD_AUDIT instead of LD_PRELOAD

ROCm 7.x HIP's internal symbol resolution breaks with LD_PRELOAD due to recursive interception of HIP-internal calls. LD_AUDIT's la_symbind64 intercepts only cross-library bindings, avoiding this
issue. The existing NVIDIA LD_PRELOAD path is unchanged.

Test results

Tested on AMD Developer Cloud with some kinds of inference servers like vLLM, Ollama, TGI, llama.cpp and SGLang.

Special notes for your reviewer:

Discussion points

1. LD_AUDIT vs LD_PRELOAD: Is a separate LD_AUDIT code path acceptable for AMD, or should we try to unify with the existing LD_PRELOAD approach? First I tried with LD_PRELOAD approach, but move to the current implementation after repeated errors.
2. PR structure: Should I submit HAMi-core and HAMi changes together, or as separate PRs?
3. amd-smi / rocm-smi: These tools use sysfs/drm (not HIP) and cannot be virtualized via LD_AUDIT.

Does this PR introduce a user-facing change?:

New resource types: amd.com/gpumem (MB), amd.com/gpucores (CU count)

[archlitchi]

thanks kenji, that implementation looks fine, though we need to test if using LD_AUDIT instead of LD_PRELOAD works on older version of glib, we can do the testing after the implementation.

And about the concerns you have:

1. we'll do the testing first, maybe we will switch from LD_PRELOAD to LD_AUDIT with nvidia devices after testing:)
2. yes, i would recommend to create a standalone amd-hami-core repo, and you can put the sources there. I'm granting you the access: https://github.com/Project-HAMi/amd-hami-core
3. well, that won't be a problem right now, we can manage to find a solution after your implementation, even we can't, we can still point that out on document

[kenji-mido]

Hi @archlitchi , thank you for setting up the repo.

I have pushed the HAMi-core code to amd-hami-core:
https://github.com/Project-HAMi/amd-hami-core

Verified the pushed codes on AMD Developer Cloud MI300X (ROCm 7.2) — build + tests pass. (Recently, the available resource is in short, so it took some times to verify, sorry.)

For the HAMi side , I need to modify
some existing files (devices.go, pods.go, scheduler.go, webhook.go)
in addition to new AMD-specific files. Should I open a PR directly
to Project-HAMi/HAMi?

[archlitchi]

yes, and we need a modified amd-device-plugin to inject the amd-core to each container