[FEATURE] Improve Device Fidelity Beyond Current Xilinx PCIe Core Limitations

[omaralmasoud]

📋 Feature Request

Improve Device Fidelity Beyond Current Xilinx PCIe Core Limitations

Background

While testing device cloning with a Realtek RTL8111/8168 donor device, I noticed that basic identity cloning works well (VID/DID, subsystem IDs, revision IDs, class code, etc.), but there appear to be several areas where the generated endpoint behavior differs from the original hardware.

From my investigation, these differences seem related to limitations imposed by the Xilinx PCIe Core itself rather than the PCILeechFWGenerator collection process.

Areas of Interest

Potential fidelity limitations include:

• Xilinx PCIe Core overriding or generating some PCI configuration space fields.
• BAR behavior not matching the donor device exactly.
• PCIe capability structures partially generated by the Xilinx PCIe IP.
• Link capability and link status behavior differing from the donor hardware.
• Power management related registers and state transitions differing from the donor.
• Internal device-specific register behavior not matching the original device.
• EEPROM / firmware specific behavior not being replicated.
• MSI/MSI-X implementation differences depending on the underlying PCIe IP.

Question

What is currently considered the practical fidelity limit when using the standard Xilinx PCIe Core?

For example:

• Which PCI configuration fields can be fully overridden?
• Which fields are controlled by the Xilinx PCIe IP and cannot be modified?
• Which capabilities can be cloned accurately?
• Are there plans to improve capability-level fidelity in future releases?
• Is a higher-fidelity mode planned that would patch or emulate additional PCIe configuration registers generated by the Xilinx core?

Goal

The objective is not necessarily perfect hardware emulation, but understanding:

1. Current fidelity limitations.
2. Which limitations originate from Xilinx PCIe IP.
3. What improvements are realistically achievable inside PCILeechFWGenerator.

Any documentation, roadmap information, or recommended approaches for improving donor fidelity would be greatly appreciated.

[marlow05]

Quite interested in this too. There are some conversations around fundamental limits in the PCIe IP that I'd love to understand.

[ramseymcgrath]

yeah you're basically right, most of what you're seeing is the Xilinx core, not the collector.

quick rundown of where the line is on 7-series:

• VID/DID/subsys/rev/class, MSI-X layout, DSN, link cap, MPS, AER/ARI/cpl-timeout all clone fine (they get pushed into the IP + the cfgspace shadow).
• BAR sizes/types now clone too (just pushed that, see below).
• IP-locked: LTSSM/link training, TLP framing, completion timing, and the actual ASPM/power-state transitions are owned by the hard block, so those don't follow the donor.

the realtek thing specifically: a lot of NICs put their registers on BAR2 (BAR0 is IO), and the firmware was always serving the register window on BAR0 regardless. so enumeration saw the wrong BAR. just fixed that in #630 - it now serves the donor's register BAR at its real index and sizes everything to match. if anyone's got a board + a donor like that handy, would appreciate a test run and a lspci -vv to confirm before it merges.

UltraScale isn't covered yet, just 7-series for now. and it's one register BAR at the moment, full multi-BAR is on the list.