Experimental guest-side helper that attempts PCIe Gen2 negotiation for
NVIDIA CMP 170HX 40 GB (10de:2082) and 64 GB (10de:20c2) cards under
Windows Hyper-V Discrete Device Assignment (DDA).
Reproduction limitation: Gen2 x16 was observed on a 40 GB card in a previously host-modified test setup. Guest-only operation from an unprepared host has not been established, and subsequent attempts after a hardware rebuild remained at Gen1. The 64 GB variant has no successful validation with this DDA helper so far. See the reproduction notes and negative results.
The existing cmpunlocker
Gen2 patch prepares three GA100 BAR0 registers and then retrains the upstream
PCIe bridge. Hyper-V DDA does not expose that upstream bridge inside the
guest, so pci_upstream_bridge() returns NULL and the patch exits before
the BAR0 preparation is performed.
This workaround performs the same three guarded BAR0 operations from a tiny userspace helper, then repeatedly writes target speed Gen2 to the endpoint's PCIe Link Control 2 register until Link Status reports Gen2 or better.
Platform of the earlier successful observations:
- NVIDIA CMP 170HX 40 GB, PCI ID
10de:2082 - direct CPU PCIe x16 slot; no PCIe switch in the successful topology
- Windows Server 2025 Hyper-V host with DDA
- Ubuntu 26.04 guest, kernel
7.0.0-30-generic - NVIDIA open kernel modules
610.43.02with cmpunlocker patches
Observed result:
- Gen1 x16 before guest-side preparation, then Gen2 x16
- Gen2 x16 also observed after warm host restarts and VM cold boots
- one later warm-restart trial reached Gen2 during preparation round 2, iteration 282
An audit of the original records found an important qualification: earlier Windows experiments had changed the upstream root port's Target Link Speed from 4 to 2. One warm restart restored 4, after which a host-side experiment set it to 2 again. For a later successful warm-restart run, no root-port measurement was captured before the guest helper ran; the subsequent measurement showed 2. These observations do not establish independence from prior host-side changes. This corrects the earlier README's stronger guest-only interpretation; the observed Gen2 links themselves are not withdrawn.
No full AC power-cycle has been verified yet. PCIe-switch topologies are not
claimed to work. The 10de:20c2 64 GB card uses the same guarded GA100
register sequence and is supported by the tool, but this exact DDA workaround
has not yet been successfully validated on that PCI ID.
Attempts with a CMP 170HX 64 GB card on an older Intel Xeon platform have not achieved Gen2 so far. It is not yet clear whether the limitation is related to the Xeon platform, the 64 GB card variant, or their interaction. This is an unsuccessful tested combination, not evidence that all Xeon systems or all 64 GB cards are incompatible. The confirmed 40 GB result above, with its reproduction limitations, remains separate. Please report results with both the host platform and card variant identified.
After a hardware rebuild, bounded attempts on the previously successful 40 GB card remained at Gen1 x16, including the exact former driver core, a normal host restart, reduced guest RAM, the formerly successful guest environment, temporary persistence mode, and an initialization-order control. A separate bounded attempt on the second 40 GB card remained at Gen1 x4. A fresh host-side read showed upstream Target Link Speed 4 while the endpoint requested 2. This is an unresolved difference, not proof that changing the root-port target is necessary or sufficient. Do not replay earlier experimental Windows writers on that basis.
A subsequent firmware-controlled comparison set the two occupied slots to Gen2 and rebooted normally. An independent Windows read then confirmed root-port TLS2 for the x16 card, but the same bounded guest procedure still remained at Gen1 x16; the second card also remained at Gen1 x4. Matching the targets alone has therefore not reproduced the earlier success. See controls E/F in the ledger for the evidence and its limits.
The dated experiment ledger records unsuccessful controls so they need not be rediscovered. This update changes documentation only, not the helper or driver.
This writes undocumented device MMIO registers. It is experimental research software for a disposable test setup, not a production driver. A wrong device, platform, or timing can wedge the GPU, crash the guest, or crash the host. No firmware is flashed and no voltage or clock setting is changed.
The helper fails closed unless the selected sysfs device is exactly
10de:2082 or 10de:20c2. By default the boot script processes every
supported card sequentially. An explicit BDF allowlist can narrow the target.
Read the reproduction limitations above before enabling automatic boot-time attempts. Installation is not a claim that Gen2 will work on a fresh host.
Requirements inside the DDA Linux guest:
- GCC and make
pciutils(lspci,setpci)- systemd
- root access
- GPU BAR0 exposed through
/sys/bus/pci/devices/.../resource0
make
sudo make install
sudo systemctl enable cmp170-dda-gen2-prep.service
sudo rebootCheck the result:
journalctl -u cmp170-dda-gen2-prep.service -b
nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.width.current \
--format=csv,noheaderThe defaults are three preparation rounds and 600 target-speed writes per
round with 50 ms spacing. Override them in /etc/default/cmp170-dda-gen2:
CMP170_GEN2_ROUNDS=3
CMP170_GEN2_ITERATIONS=600
CMP170_GEN2_INTERVAL=0.05
CMP170_GEN2_BDFS="0000:41:00.0 0000:42:00.0"If CMP170_GEN2_BDFS is unset, all locally visible 2082 and 20c2 cards
are processed one after another.
For each selected supported device, the helper performs:
- BAR0
0x8c2c0: clear bit 2 - BAR0
0x8c040: set bits 19:18 to2 - BAR0
0x8872c: write0x00000006 - endpoint PCIe Link Control 2: repeatedly request target speed 2
- stop as soon as Link Status reports generation 2 or higher
The three MMIO operations are derived from cmpunlocker's
pcie-gen2-probe-retrain.patch.
GPL-2.0-only. See LICENSE.