Header type 127 in passthrough: inspect the host first.

Why do some tools say 127 and others say 7f?

Libvirt’s PCI code masks and checks the header type, then formats an unknown type as a decimal number. 127 and 0x7f are the same value. Proxmox uses QEMU/KVM and its messages may differ; do not assume every Proxmox error is generated by libvirt. libvirt: PCI header validation and decimal error formatting.

This is a reason to inspect the host’s PCI device state. It is not evidence that a particular guest Windows installation, ROM file or VM machine type is wrong.

Capture three points in the VM lifecycle

On the host, record the same device at three points: before the first VM start, after a normal guest shutdown, and immediately after a failed second start. Keep the kernel log around each transition.

# Run on the host. Replace the example PCI address.
uname -r
lspci -s 0000:01:00.0 -nnk
sudo lspci -s 0000:01:00.0 -vv
cat /sys/bus/pci/devices/0000:01:00.0/reset_method
sudo journalctl -k -b --no-pager

If reset_method exists, reading it shows enabled/supported reset methods and ordering. Its presence does not promise that a reset will recover a card in every state. A missing file also deserves recording rather than creating it. Linux kernel: PCI sysfs, remove, rescan and reset interfaces.

Check passthrough prerequisites separately

Compare your setup with the Proxmox documentation matching your installed release. Check IOMMU support and groups, the driver owning each required function, and whether another workload is using the card. Whole-device VFIO passthrough and mediated GPU devices have different driver ownership rules. Proxmox VE: PCI passthrough documentation source.

Capture the exact GPU model, subsystem IDs, motherboard, BIOS, host kernel, QEMU/Proxmox version and guest driver. GPU audio and other companion functions should be accounted for according to the documented configuration. Do not detach a function simply because it has a similar address.

Choose a recovery that matches the failure

1. Stop the guest cleanly and preserve its configuration and host logs.
2. Schedule an orderly host reboot if recovery requires it, accounting for other VMs and services.
3. Compare a vendor-supported host kernel or a documented device-specific reset remedy, one change at a time.
4. Test the full start → use → shutdown → start sequence repeatedly within an agreed test window.

Do not “fix” this message by writing a different header byte, resetting an upstream bridge blindly, or applying an unrelated card’s ROM/reset script. Keep IOMMU and security changes separate from evidence of a reset problem. A script that makes one second start succeed is not yet a reliable lifecycle solution.

What about AMD GPUs and vendor-reset?

The upstream vendor-reset project provides reset handling for a defined set of AMD devices. Check its supported-device list and kernel requirements for your exact card; it is not a universal AMD or NVIDIA repair. The project also documents an early-loading requirement. Treat adopting an out-of-tree kernel module as a separate, planned change with distribution guidance and rollback. vendor-reset: device-specific reset module and supported hardware.

Common passthrough questions

Will a guest driver reinstall fix an unreadable host device?

It is not the first repair path. Restore and understand host access before treating this as a guest driver issue.

Should I buy another GPU?

First establish whether the failure follows the card, host platform or software combination using supported comparisons. A replacement purchase based only on “127” can repeat the same failure.

What is worth keeping after I fix it?

A versioned working configuration, lifecycle test record, recovery procedure and upgrade rollback notes. These are more reusable than a long list of unexplained boot parameters.