Add restricted AMD xHCI IMOD module

[Ravinity]

Summary

Adds a restricted PawnIO module for inspecting AMD xHCI controller layout and reading or updating the per-interrupter IMOD interval.

The module currently allowlists the AMD PCI device IDs 1022:15B7 and 1022:43FD.

Safety boundaries

• validates the PCI BDF, AMD vendor/device ID, xHCI class code, memory decoding, and BAR0 memory type
• rejects I/O and reserved BAR encodings
• derives CAPLENGTH, HCSPARAMS1.MaxIntrs, and RTSOFF from the controller rather than using fixed offsets
• bounds the calculated runtime mapping to 1 MiB
• exposes controller information and per-interrupter reads without arbitrary MMIO access
• updates IMOD through the xHCI-required 32-bit read/modify/write while preserving the sampled counter field
• refuses writes to unconfigured or disabled interrupters
• verifies readback and performs a best-effort immediate restore after a failed read or value mismatch
• unmaps controller MMIO after each request

Validation

• compiled successfully with Pawn 4.1.7152 using the repository CI flags: -C64 -;+ -(+ -p
• deterministic AMX output across repeated builds
• PCI IDs and BDF discovery validated on an AMD X870E system with one 15B7 and two 43FD controllers

Live register execution is not claimed yet: the production PawnIO driver correctly requires a maintainer-signed module, so this contribution remains a draft pending actual hardware testing.

The motivation is to provide a narrow alternative to generic RW-Everything-style kernel/MMIO access for xHCI interrupt-moderation experiments.

[namazso]

Changed this to draft, only mark as ready once tested on actual hardware.

[Ravinity]

Understood — I’ll keep this draft until it has been exercised on the actual target controllers.

The hardware is available here: one 1022:15B7 controller and two 1022:43FD controllers. The current production PawnIO driver rejects unsigned custom modules, while the unrestricted installer path is still affected by PawnIO.Setup #11. I do not want to re-enable RW-Everything or weaken Secure Boot/Code Integrity merely to produce the test result.

Would you be willing to provide a test-signed AMX from commit 779eac6, or recommend another supported test route that preserves production Windows trust? I can then attach controller discovery, read/write/readback, rollback, reboot, sleep/resume, USB stability, and latency/DPC results before marking the PR ready.

[namazso]

supported test route that preserves production Windows trust?

No. It's in the name, its production trust. It's not meant to run test code.

If you really want this, you can start an LLC, purchase an EV code signing certificate, apply to the Microsoft Hardware Developer program, build PawnIO with your own key (or unrestricted build), upload it to Hardware Dev Center for signing, and load it.

I think enabling test mode is easier, but each to their own.

[Softhe]

A five-device allowlist handoff is ready at Ravinity#1 (commit 11cd3aa). It adds 15B6, 15B8, and 43F7 to the existing 15B7/43FD scope without changing the module's MMIO, validation, readback, rollback, or cleanup behavior.

Evidence boundaries remain explicit:

• 15B6, 15B8, 43F7: local discovery, read-only enumeration, bounded write/readback/restore, reboot, cold-boot, and resume evidence.
• 15B7, 43FD: discovery/BDF evidence only; live register execution is still required on the PR author's hardware.

The five-ID source was built twice with Pawn 4.1.7152 and the repository flags. Both 21,808-byte outputs were identical: SHA-256 cc91910714a6e1a7fba075684a9836728ea7c5439518ab5a0a0019866544a16a.

The local AMX is development evidence only and is not a substitute for maintainer signing. @Ravinity, please review/merge the handoff branch when satisfied. @namazso, maintainer review and an official signed module release remain the production gate after live coverage is accepted.