Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature] Support Hyper-V GPU Partitioning (GPU-P) / VMBus Paravirtualized & SR-IOV vGPU devices

Open
  • Is something wrong?
#417 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
macos, rust
Domain
backend, operating-systems

Research direction

Start by reading the NVRM.kext, NVAccel.kext, NVRMFB.kext, and NVMTLDriver / NVK initialization paths named in the issue, then determine whether Hyper-V GPU-P exposes a usable PCIe VF or requires a VMBus bridge. The issue describes alternative architectures but does not identify files or tests; done means initializing GPU-P devices and providing Metal 3 acceleration in the specified macOS VM.

Written by the indexing model from the issue text.

Description

enhancement
What should it do, and why does it matter to you?
What should it do, and why does it matter to you?
What it should do

Enable nvidia-macos-driver (NVRM.kext, NVAccel.kext, NVRMFB.kext, and the NVMTLDriver / NVK stack) to initialize and provide Metal 3 hardware acceleration when running inside a Hyper-V Generation 2 macOS virtual machine configured with GPU Partitioning (GPU-P) (Add-VMGpuPartitionAdapter).

Specifically, this would involve supporting one or both of the following paths depending on architectural feasibility:

  1. SR-IOV / Virtual Function (VF) Enumeration in NVRM.kext: Allow NVRM (built on NVIDIA's open kernel modules r610+) to detect, attach to, and initialize partitioned NVIDIA Virtual Functions or hypervisor-passthrough devices where the GSP firmware is already initialized by the host hypervisor (skipping bare-metal physical GSP boot/reset sequences and physical display head probing when running headless/virtualized), while binding a virtual display/headless framebuffer in NVRMFB so WindowServer can composite via NVAccel.
  2. Hyper-V VMBus (hv_vmbus) / Paravirtualized Transport Bridge: On client Windows 10/11 Hyper-V, Add-VMGpuPartitionAdapter exposes the partitioned GPU over VMBus (SYNTH3D / dxgkrnl paravirtualized channel) rather than a raw PCIe BAR. If NVRM.kext requires direct PCIe MMIO/BAR access that client GPU-P does not expose via PCIe, an alternative paravirtualized kernel shim (or forwarding command buffers from NVK / NVAccel over a VMBus guest kext to the host GPU partition) would allow the userspace Metal-to-SPIR-V/NVK translator to execute workloads on the host NVIDIA partition.

At a minimum, having NVRM gracefully handle hypervisor presence checks (CPUID hypervisor bit), small/partitioned BAR1 allocations, and virtualized/headless display output without stalling at PCI configuration or failing GSP handshake when a GPU is shared would unlock virtualized workflows.

Why it matters to me

Running macOS 15 Sequoia / 26 Tahoe inside Hyper-V on Windows 11 is an essential workflow for cross-platform developers and systems engineers, particularly on single-GPU desktops and Optimus/hybrid laptops (e.g., Intel + RTX 40-series Mobile) where Full PCIe Passthrough / Discrete Device Assignment (DDA) is either unsupported on client Windows or leaves the host OS without a GPU.

  1. Zero-Reboot Cross-Platform Development: With GPU-P, the Windows host retains full access to the RTX GPU while dynamically sharing a fraction of VRAM and compute with the macOS VM. We can test and build macOS software, Xcode projects, Metal shaders, and audio/graphics plugins alongside native Windows tools simultaneously without dual-booting or sacrificing the GPU exclusively to a single OS.
  2. Laptop & Single-GPU Viability: On laptops with muxless/Optimus RTX GPUs where display outputs are wired to the iGPU and IOMMU groups prevent clean bare-metal passthrough, Hyper-V GPU-P is the only way to allocate NVIDIA hardware acceleration to a guest VM on Windows.
  3. Headless & Remote Compositing: Combined with NVAccel and a virtualized framebuffer in NVRMFB, GPU-P support would transform sluggish CPU-rendered macOS VMs under Hyper-V into fully Metal 3-accelerated environments at near-native responsiveness.
Dominant language
Rust
Stars
2.5k
Forks
233
Avg merge
3d 14h
Merged PRs (30d)
14

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nullmoth/nvidia-macos-driver

All issues in nullmoth/nvidia-macos-driver

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.