PCIe resource allocation issue after DDA GPU assignment

Question

Hi

I’m configuring a Windows Server host where assigning a physical PCIe GPU to a guest VM using discrete device assignment (DDA) causes SR‑IOV virtual functions on attached network adapters to stop working. The issue seems tied to how the host manages PCIe resource allocation and MMIO space parameters, specifically the flag HasMMIOSpaceNotConfigured.

Here’s what I’m seeing:

When a GPU is passed through via DDA, SR‑IOV VFs on NICs fail to initialize correctly.

The host reports insufficient MMIO space allocation for the PCIe hierarchy.

Rebooting or re‑enumerating PCIe devices doesn’t restore SR‑IOV functionality unless the GPU is detached.

I’ve reviewed BIOS and firmware settings for PCIe resource mapping and tried adjusting IOMMU and large memory range configurations, but the problem persists. Is there a recommended method to reconfigure host PCIe resource allocation and MMIO space parameters to support both DDA GPU passthrough and SR‑IOV NICs simultaneously ?

Any insights or configuration examples from Microsoft team or the community would be greatly appreciated. I can share more details about the host setup if needed. Thanks in advance.

Answer 1

Hello RahmaNali,

What you are seeing is a PCIe resource exhaustion problem: when you assign a GPU via Discrete Device Assignment, the host must reserve large MMIO ranges for that device, and this can starve SR‑IOV NICs of the address space they need to expose virtual functions. The flag HasMMIOSpaceNotConfigured confirms that the host cannot allocate sufficient MMIO resources for both devices simultaneously. Hyper‑V itself does not provide a tunable parameter to increase MMIO space; the allocation is determined by BIOS/firmware and the platform’s PCIe root complex.

The supported remediation is to adjust BIOS settings to enable “Above 4G Decoding” or “Large BAR/MMIO support,” which allows the host to map larger PCIe address ranges. On servers with multiple GPUs and SR‑IOV NICs, this setting is mandatory. You should also ensure that IOMMU/VT‑d is enabled and that the NIC firmware is current, since older firmware can fail to negotiate MMIO ranges correctly. If the platform still cannot allocate enough space, the only safe option is to split workloads—either dedicate the GPU to one host and SR‑IOV NICs to another, or avoid combining DDA GPU passthrough with SR‑IOV on the same PCIe hierarchy.

In short, you cannot reconfigure MMIO allocation from Windows; it must be handled at the hardware/firmware level. Check that “Above 4G Decoding” and SR‑IOV are enabled in BIOS, update NIC and GPU firmware, and if the platform still reports insufficient MMIO space, you will need to separate the devices across hosts or PCIe root complexes.

If my answer is useful for you, please hit Accept the answer to support me.

Thank you,

HL.

Answer 2

The supported Microsoft guidance in this scenario is to verify and correct VM MMIO configuration for DDA, and to consider enabling SR-IOV as part of troubleshooting.

For a VM that uses a GPU through DDA, check these VM settings from an elevated PowerShell session:

Get-VM -Name <VMName>

The VM should have these values:

• Automatic Stop Action = TurnOff
• GuestControlledCacheTypes = True
• LowMemoryMappedIoSpace = 3000000000
• HighMemoryMappedIoSpace = 33280000000

If they are not set, configure them:

Set-VM -Name VMName -AutomaticStopAction TurnOff
Set-VM -GuestControlledCacheTypes $true -VMName VMName
Set-VM -LowMemoryMappedIoSpace 3Gb -VMName VMName
Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName VMName

Those MMIO values are reasonable starting values for experimenting with a single GPU. If the VM still reports resource errors such as Code 12 or "Insufficient system resources exist to complete the requested service," increase MMIO based on the device requirements.

For precise sizing, use the DDA machine profile script SurveyDDA.ps1. It reports whether the system is correctly configured for DDA, which devices are compatible, each device's Location Path, and any MMIO requirement it detects. The DDA planning guidance also shows that MMIO must be calculated per assigned device plus buffer.

Microsoft troubleshooting guidance also explicitly says to consider enabling SR-IOV when using DDA, because that setting might resolve some issues. If BIOS or UEFI settings are changed, restart the host before continuing.

If the GPU is mounted but workloads or services still do not recognize it, also verify:

1. The latest supported GPU vendor driver is installed and shows no errors in Device Manager.
2. The GPU has enough MMIO space allocated in the VM.
3. The GPU model is supported by the vendor for this passthrough configuration.
4. The guest OS is supported for DDA: Generation 1 or 2 VM with Windows 10 or later, or Windows Server 2016 or later.
5. The host and guest are fully updated.

The provided Microsoft content does not include a host-level procedure to manually reconfigure PCIe hierarchy resource allocation or a documented method to tune a host flag such as HasMMIOSpaceNotConfigured. The documented path is to:

1. Validate DDA compatibility and MMIO requirements with SurveyDDA.ps1.
2. Set the VM MMIO values correctly.
3. Consider enabling SR-IOV.
4. Restart after BIOS/UEFI changes.
5. If the issue remains, collect diagnostics and contact Microsoft Support or the GPU vendor.

For escalation, gather:

Get-PnpDevice -FriendlyName "<device-friendly-name>"
Get-VMHostPartitionableGpu | FL Name, ValidPartitionCounts

Also record the GPU properties from Device Manager, Driver Model from DxDiag, GPU status in Windows Admin Center, and any load data from Task Manager or nvidia-smi.

---

References:

• Hyper-V GPU assignment, partitioning, and passthrough troubleshooting guidance
• Deploy devices by using Discrete Device Assignment
• Deploy graphics devices by using Discrete Device Assignment