revert pinned hostmem for pod comm

[AtlantaPepsi]

Motivation

This is to add back the option of extended GPU memory in cross pod transfer.

Technical Details

Removed CheckPages() inside AllocateMemory() for pinned host memory. This would cause a silent fail on the node where it's allocated, and other nodes will hang at broadcast inside ExchangeMemory.

It's also not tested yet on either Nvidia or AMD platforms.

Test Plan

Test Result

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

[Copilot]

Pull request overview

This PR adjusts pod-communication (fabric-handle) memory allocation to better support exporting extended (HOST_NUMA) memory across pods, and avoids a failure mode where NUMA page validation caused one rank to error while other ranks hung in collectives.

Changes:

• Add a GetMemLocation() helper to correctly select DEVICE vs HOST_NUMA locations for pod-comm VMM allocations and access descriptors.
• Remove CheckPages()/move_pages() validation for fabric-exportable host allocations (keep zeroing), with an explanatory comment.
• Extend CUDA-compat macro aliases/undefs to include hipMemLocation and hipMemLocationTypeHostNuma.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[gilbertlee-amd]

Why is this hipSetDevice even necessary? The runtime should already have the ability to determine where the memory handle is. It also seems strange that you would not need it for CPU memory types but GPU memory types.

Based on the documentation, cuMemExportToSharableHandle doesn't require the current device context either, and won't ever return CUDA_ERROR_INVALID_CONTEXT