HP t740 / Raven Ridge (1002:15dd): GPU passthrough works only once after host reboot – PCI reset causes host freeze

[Tomblarom]

Hi everyone,

I'm trying to pass through the integrated Radeon Vega GPU of an HP t740 thin client to a Debian VM (as a moonlight client for sunshine server). After extensive testing, I found a workaround that allows the first successful GPU initialization, but the GPU cannot be initialized a second time without rebooting the Proxmox host.

• HP t740, AMD Ryzen Embedded V1756B
• Radeon Vega (Raven Ridge), PCI ID 1002:15dd, revision 82
• GPU at 0000:04:00.0, isolated in its own IOMMU group
• Proxmox VE 9.2.24, kernel 7.0.14-26-pve
• pve-qemu-kvm 11.0.3-4, qemu-server 9.2.13
• Debian 13 guest, OVMF, q35, CPU host
• GPU bound to vfio-pci during host boot

Problem 1: PCI reset freezes the host
With the standard GPU reset methods (flr bus), starting the VM with the GPU passed through can freeze the entire Proxmox host. The host kernel previously logged:

AMD-Vi: IOMMU ... Completion-Wait loop timed out
IOTLB_INV_TIMEOUT device=0000:04:00.0

Using pci=noats alone did not resolve the host freeze.


Workaround for the first VM start
The following combination allows the VM to boot with GPU passthrough:

# Host kernel parameter:
pci=noats

# Disable PCI reset methods before VM start:
printf '\n' > /sys/bus/pci/devices/0000:04:00.0/reset_method

I implemented the latter using a Proxmox VM pre-start hookscript:

Spoiler: /var/lib/vz/snippets/vega210-noreset.sh

#!/bin/bash
set -eu

VMID="${1:-}"
PHASE="${2:-}"

[ "$VMID" = "210" ] || exit 0
[ "$PHASE" = "pre-start" ] || exit 0

CONFIG="/etc/pve/qemu-server/${VMID}.conf"
GPU="/sys/bus/pci/devices/0000:04:00.0"

# Only apply, when Vega is present
if ! grep -Eq '^hostpci0:[[:space:]]*(0000:)?04:00\.0([,[:space:]]|$)' "$CONFIG"; then
    logger -t vega210-noreset \
      "VM 210: no Vega passthrough configured, skipping"
    exit 0
fi

# Checks
[ "$(hostname -s)" = "aribup" ]
grep -qw 'pci=noats' /proc/cmdline
[ "$(readlink -f "$GPU/driver")" = \
  "/sys/bus/pci/drivers/vfio-pci" ]

# Disable PCI-Resetmethods for Vega
printf '\n' > "$GPU/reset_method"
[ -z "$(cat "$GPU/reset_method")" ]

logger -t vega210-noreset \
  "VM 210: Vega PCI reset methods disabled"

Proxmox reports:

failed to reset PCI device '0000:04:00.0',
but trying to continue as not all devices need a reset

Despite this warning, the guest boots successfully, amdgpu initializes, /dev/dri/renderD128 is created, and the physical DisplayPort output works. Mesa's Wayland/EGL path can also render on the actual AMD GPU.

The Debian guest requires firmware-amd-graphics.


Problem 2: GPU cannot be reinitialized
After the first successful run, both of these fail:

1. Rebooting the Debian guest.
2. Completely shutting down the guest and starting a new QEMU process with qm start.

The second initialization produces GPU page faults, including:

amdgpu: no-retry page fault
amdgpu: VM_L2_PROTECTION_FAULT_STATUS: 0xFFFFFFFF
amdgpu: failed to write reg 28b4 wait reg 28c6

The guest does not complete booting, although QEMU may report status: running.

With PCI reset methods disabled, the Proxmox host remains accessible. Removing the GPU passthrough allows the VM to boot normally again.

Additional tests that did not resolve the issue

• pci=noats without disabling PCI resets
• d3cold_allowed=0
• vfio-pci.disable_idle_d3=1
• reboot: 0 (a new QEMU process still cannot reinitialize the GPU)

The host reports the GPU in D0 after guest shutdown. A full host reboot restores functionality for exactly one guest initialization. I also found a somewhat similar report for a Radeon 780M under PVE 9, where the author reports that PVE 8.4 works correctly: https://forum.proxmox.com/threads/pve-9-x-ryzen-igpu-passthrough.177030/

Questions
Is there a known hardware-specific reset limitation or quirk for Raven Ridge 1002:15dd? Could this be related to a regression in newer kernels or VFIO? Is there a safe reset/reinitialization approach that would avoid rebooting the entire host?

I'd appreciate any pointers on where to investigate next or what additional logs would be useful.