Skip to content

Latest commit

 

History

6 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

CMP 170HX 40/64 GB Hyper-V DDA Gen2 experiments

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.

Why it exists

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.

Observed success and its limits

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.02 with 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.

Compatibility update — 6 September 2026

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.

Reproduction update — 7 September 2026

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.

Safety

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.

Install

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 reboot

Check the result:

journalctl -u cmp170-dda-gen2-prep.service -b
nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.width.current \
  --format=csv,noheader

The 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.

How it works

For each selected supported device, the helper performs:

  1. BAR0 0x8c2c0: clear bit 2
  2. BAR0 0x8c040: set bits 19:18 to 2
  3. BAR0 0x8872c: write 0x00000006
  4. endpoint PCIe Link Control 2: repeatedly request target speed 2
  5. 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.

License

GPL-2.0-only. See LICENSE.

About

Boot-time PCIe Gen2 workaround for NVIDIA CMP 170HX 40GB/64GB in Linux guests under Windows Hyper-V DDA.

Topics

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages