[WORKING]Win11 VM won't boot after passthrough of GPU - Vendor Reset not able to set reset_method (solution: update kernel - unbind via hook script)

S

s2d4

New Member
May 18, 2025
9
0
1
Hi all, hopefully someone can point me in the right direction.

This is the error:
error writing '1' to '/sys/bus/pci/devices/0000:03:00.0/reset': Inappropriate ioctl for device
failed to reset PCI device '0000:03:00.0', but trying to continue as not all devices need a reset
swtpm_setup: Not overwriting existing state file.
stopping swtpm instance (pid 3392) due to QEMU startup error
TASK ERROR: start failed: QEMU exited with code 1

Which is after the following:

I managed to get vendor-reset added as shown:
cat /etc/modules
vfio
vfio_iommu_type1
vfio_pci
vendor-reset

which is confirmed by the following (although kernel is tainted due to adding vendor-reset?):
dmesg | grep vendor_reset
[ 8.081690] vendor_reset: loading out-of-tree module taints kernel.
[ 8.081693] vendor_reset: module verification failed: signature and/or required key missing - tainting kernel
[ 8.097532] vendor_reset_hook: installed

lsmod | grep vendor
vendor_reset 110592 0

However, the following shows that vendor reset for the device specific method is not working:
journalctl -b 0 | grep vfio-pci
vfio-pci 0000:03:00.0: vgaarb: deactivate vga console
vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=none
Unsupported reset method 'device_specific'

journalctl -b 0 | grep reset
kernel: vendor_reset: loading out-of-tree module taints kernel.
kernel: vendor_reset: module verification failed: signature and/or required key missing - tainting kernel
kernel: vendor_reset_hook: installed
systemd[1]: Started vreset.service - AMD GPU reset method to 'device_specific'.
systemd[1]: vreset.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: vreset.service: Failed with result 'exit-code'.
kernel: vfio-pci 0000:03:00.0: Unsupported reset method 'device_specific'

The following is the code for setting the device_specific method:
Code: 
Bash:
cat << EOF >>  /etc/systemd/system/vreset.service
[Unit]
Description=AMD GPU reset method to 'device_specific'
After=multi-user.target
[Service]
ExecStart=/usr/bin/bash -c 'echo device_specific > /sys/bus/pci/devices/0000:03:00.0/reset_method'
[Install]
WantedBy=multi-user.target
EOF
systemctl enable vreset.service && systemctl start vreset.service

As derived the following information
lspci -nnks 03:00

03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:7550] (rev c0)
Subsystem: ASUSTeK Computer Inc. Device [1043:061a]
Kernel driver in use: vfio-pci
Kernel modules: amdgpu
03:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:ab40]
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:ab40]
Kernel driver in use: vfio-pci
Kernel modules: snd_hda_intel

The following also shows that the reset_method has not being writen to:
cat /sys/bus/pci/devices/0000:03:00.0/reset_method
bus

So I figured I would try and manually overwrite bus with device-specifc
systemctl stop vreset.service
nano /sys/bus/pci/devices/0000:03:00.0/reset_method

This is where I was faced the locked status:
[ Error writing lock file /sys/bus/pci/devices/0000:03:00.0/.reset_method.swp: Permission denied ]


Maybe I am overlooking something? There is so much conflicting information I am not sure if what I am doing is correct. It appears I am very close but yet so far..


Additional info:
cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-10-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on iommu=pt hugepagesz=2M hugepages=24576 nomodeset pcie_acs_override=downstream

cat /etc/mdoprobe.d/vfio.conf
options vfio-pci ids=1002:7550,1002:ab40 disable_vga=1

dmesg | grep -e DMAR -e IOMMU
[ 0.000000] Warning: PCIe ACS overrides enabled; This may allow non-IOMMU protected peer-to-peer DMA
[ 0.019803] ACPI: DMAR 0x0000000042767000 000050 (v02 INTEL EDK2 00000002 01000013)
[ 0.019833] ACPI: Reserving DMAR table memory at [mem 0x42767000-0x4276704f]
[ 0.112687] DMAR: IOMMU enabled
[ 0.240798] DMAR: Host address width 39
[ 0.240798] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[ 0.240804] DMAR: dmar0: reg_base_addr fed91000 ver 5:0 cap d2008c40660462 ecap f050da
[ 0.240806] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 0
[ 0.240807] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[ 0.240807] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[ 0.242233] DMAR-IR: Enabled IRQ remapping in x2apic mode
[ 7.176231] DMAR: No RMRR found
[ 7.176232] DMAR: No ATSR found
[ 7.176232] DMAR: No SATC found
[ 7.176239] DMAR: dmar0: Using Queued invalidation
[ 7.176669] DMAR: Intel(R) Virtualization Technology for Directed I/O

cat /etc/pve/qemu-server/800.conf
bios: ovmf
boot: order=virtio0
cores: 20
cpu: host,flags=+pcid
efidisk0: zfspool:vm-800-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
hostpci0: 0000:03:00,pcie=1
machine: pc-q35-9.2+pve1
memory: 49152
meta: creation-qemu=9.2.0,ctime=1747375148
name: win11
net0: virtio=BC:24:11:7E:72:86,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsihw: virtio-scsi-single
smbios1: uuid=c0a45d16-e5a1-411c-87c4-c168cd0f6a0a
sockets: 1
tpmstate0: zfspool:vm-800-disk-1,size=4M,version=v2.0
vga: none
virtio0: zfspool:vm-800-disk-2,cache=writethrough,iothread=1,size=128G
vmgenid: 5acfade8-67fa-4319-9535-ca32db66e29c
 
Last edited:
Seems like nobody care this post either, i have not a similar problem but im getting error 43 on Windows 11 , i can pass the GPU to any Linux VM , do you get it ?
 
s2d4 said:
Unsupported reset method 'device_specific'
Click to expand...
The vendor-reset module is probably not loaded.
s2d4 said:
kernel: vendor_reset: module verification failed: signature and/or required key missing - tainting kernel
Click to expand...
Looks like vendor-reset cannot be loaded because of Secure Boot. Disable Secure Boot or sign the vendor-reset module. I don't know how to do that, only that it was explained in an older thread.
 
leesteken said:
The vendor-reset module is probably not loaded.

Looks like vendor-reset cannot be loaded because of Secure Boot. Disable Secure Boot or sign the vendor-reset module. I don't know how to do that, only that it was explained in an older thread.
Click to expand...
output to mokutil --sb-state
is as follows:
SecureBoot disabled

so this is why dmesg still gives
[ 8.113559] vendor_reset_hook: installed


Ciroloco said:
Seems like nobody care this post either, i have not a similar problem but im getting error 43 on Windows 11 , i can pass the GPU to any Linux VM , do you get it ?
Click to expand...
I am not there yet.
 
Last edited:
I'm not a huge fan on vendor_reset, try without it first.
If your gpu is released within the last 5 years, you probably don't need it. My 6600 doesn't require it.
Your GPU looks like a 9070?
 
frankmanzhu said:
I'm not a huge fan on vendor_reset, try without it first.
If your gpu is released within the last 5 years, you probably don't need it. My 6600 doesn't require it.
Your GPU looks like a 9070?
Click to expand...
I did try without it initially, wouldn't boot as qm start would always attempt to reset it which promptly fails. The qemu version in pve also doesn't make much sense as it doesn't recognise reset disable when supposedly v7+ should do, and thus this route of vendor_reset.

It's a 9070xt, the pricing here doesn't make much sense unfortunately.
 
Last edited:
s2d4 said:
I did try without it initially, wouldn't boot as qm start would always attempt to reset it which promptly fails. The qemu version in pve also doesn't make much sense as it doesn't recognise reset disable when supposedly v7+ should do, and thus this route of vendor_reset.

It's a 9070xt, the pricing here doesn't make much sense unfortunately.
Click to expand...
This sounds like a pass-through issue rather than reset. 9070 XT is a bit new, but I don't expect AMD introduce the reset bug back to the new card.

If early bind doesn't work well for you, use the old blacklist way will resolve most issues.
 
frankmanzhu said:
This sounds like a pass-through issue rather than reset. 9070 XT is a bit new, but I don't expect AMD introduce the reset bug back to the new card.

If early bind doesn't work well for you, use the old blacklist way will resolve most issues.
Click to expand...
So with just the following (without the vendor_reset):

root@ms-01:~# cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=1002:7550,1002:ab40 disable_vga=1

as confirmed by:
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 7550 (rev c0)
Subsystem: ASUSTeK Computer Inc. Device 061a
Kernel driver in use: vfio-pci
Kernel modules: amdgpu
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device ab40
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device ab40
Kernel driver in use: vfio-pci
Kernel modules: snd_hda_intel

Vm config as follows:
root@ms-01:~# cat /etc/pve/qemu-server/800.conf
balloon: 4096
bios: ovmf
boot: order=usb0;virtio0
cores: 18
cpu: host,flags=+pcid
efidisk0: zfspool:vm-800-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
hostpci0: 0000:03:00,pcie=1,x-vga=1
machine: pc-q35-9.2+pve1
memory: 40960
meta: creation-qemu=9.2.0,ctime=1747375148
name: win11
net0: virtio=BC:24:11:7E:72:86,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsihw: virtio-scsi-single
smbios1: uuid=c0a45d16-e5a1-411c-87c4-c168cd0f6a0a
sockets: 1
tpmstate0: zfspool:vm-800-disk-1,size=4M,version=v2.0
usb0: host=1b1c:1a90
vga: none
virtio0: zfspool:vm-800-disk-2,cache=writethrough,iothread=1,size=128G
vmgenid: 5acfade8-67fa-4319-9535-ca32db66e29c

and
root@ms-01:~# cat /etc/modprobe.d/blacklist.conf
blacklist radeon
blacklist amdgpu

Starting the VM ends up with the following:\
root@ms-01:~# qm start 800
error writing '1' to '/sys/bus/pci/devices/0000:03:00.0/reset': Inappropriate ioctl for device
failed to reset PCI device '0000:03:00.0', but trying to continue as not all devices need a reset
swtpm_setup: Not overwriting existing state file.
kvm: ../hw/pci/pci.c:1654: pci_irq_handler: Assertion `0 <= irq_num && irq_num < PCI_NUM_PINS' failed.
stopping swtpm instance (pid 9595) due to QEMU startup error
start failed: QEMU exited with code 1
 
s2d4 said:
So with just the following (without the vendor_reset):

root@ms-01:~# cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=1002:7550,1002:ab40 disable_vga=1

as confirmed by:
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 7550 (rev c0)
Subsystem: ASUSTeK Computer Inc. Device 061a
Kernel driver in use: vfio-pci
Kernel modules: amdgpu
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device ab40
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Device ab40
Kernel driver in use: vfio-pci
Kernel modules: snd_hda_intel

Vm config as follows:
root@ms-01:~# cat /etc/pve/qemu-server/800.conf
balloon: 4096
bios: ovmf
boot: order=usb0;virtio0
cores: 18
cpu: host,flags=+pcid
efidisk0: zfspool:vm-800-disk-0,efitype=4m,pre-enrolled-keys=1,size=1M
hostpci0: 0000:03:00,pcie=1,x-vga=1
machine: pc-q35-9.2+pve1
memory: 40960
meta: creation-qemu=9.2.0,ctime=1747375148
name: win11
net0: virtio=BC:24:11:7E:72:86,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsihw: virtio-scsi-single
smbios1: uuid=c0a45d16-e5a1-411c-87c4-c168cd0f6a0a
sockets: 1
tpmstate0: zfspool:vm-800-disk-1,size=4M,version=v2.0
usb0: host=1b1c:1a90
vga: none
virtio0: zfspool:vm-800-disk-2,cache=writethrough,iothread=1,size=128G
vmgenid: 5acfade8-67fa-4319-9535-ca32db66e29c

and
root@ms-01:~# cat /etc/modprobe.d/blacklist.conf
blacklist radeon
blacklist amdgpu

Starting the VM ends up with the following:\
root@ms-01:~# qm start 800
error writing '1' to '/sys/bus/pci/devices/0000:03:00.0/reset': Inappropriate ioctl for device
failed to reset PCI device '0000:03:00.0', but trying to continue as not all devices need a reset
swtpm_setup: Not overwriting existing state file.
kvm: ../hw/pci/pci.c:1654: pci_irq_handler: Assertion `0 <= irq_num && irq_num < PCI_NUM_PINS' failed.
stopping swtpm instance (pid 9595) due to QEMU startup error
start failed: QEMU exited with code 1
Click to expand...
Looks like you are on the blacklist route. You probably need to blacklist more drivers. like your audio is using snd_hda_intel
You need to blacklist that too and have another go.

Have a look at my suggested config and once you get it working, then remove relevant parts one by one. I've survived multiple cpu/motherboard/gpu with the same configuration like that.
F

Post in thread 'GPU Passthrough issues'

Your BIOS setting doesn't look right.

Resizable BAR: Disabled (Not Enabled)
Above 4G decoding: Disabled (Not Enabled)
IOMMU: Enabled (Not AUTO)
Prefered GPU Setting : External (looks like in your case, you need to choose egpu first on your boot if that's the only windows VM you boot up)

Only with those settings done, then you can proceed with GPU passthrough. Once you get it working, maybe you can try relax those settings and see if it works without it.

If I understand you correctly, you are trying to blacklist the nvidia driver on the host, right? Try with the following

Code: 
...
 
frankmanzhu said:
Looks like you are on the blacklist route. You probably need to blacklist more drivers. like your audio is using snd_hda_intel
You need to blacklist that too and have another go.

Have a look at my suggested config and once you get it working, then remove relevant parts one by one. I've survived multiple cpu/motherboard/gpu with the same configuration like that.
F

Post in thread 'GPU Passthrough issues'

Your BIOS setting doesn't look right.

Resizable BAR: Disabled (Not Enabled)
Above 4G decoding: Disabled (Not Enabled)
IOMMU: Enabled (Not AUTO)
Prefered GPU Setting : External (looks like in your case, you need to choose egpu first on your boot if that's the only windows VM you boot up)

Only with those settings done, then you can proceed with GPU passthrough. Once you get it working, maybe you can try relax those settings and see if it works without it.

If I understand you correctly, you are trying to blacklist the nvidia driver on the host, right? Try with the following

Code: 
...
Click to expand...
I only went that route because you said so earlier. In reality it was already working because the driver that were used for the GPU was already vfio-pci but I thought what the heck, why not.

Thanks for your assistance thus far.
 
s2d4 said:
I only went that route because you said so earlier. In reality it was already working because the driver that were used for the GPU was already vfio-pci but I thought what the heck, why not.

Thanks for your assistance thus far.
Click to expand...
No worries. Hopefully you can get it working soon. I will be very surprised that it’s vendor reset.

Assertion `0 <= irq_num && irq_num < PCI_NUM_PINS' failed.

I remember I had this issue before on a bad kernel update or forget to add grub cmdline entries. Can you double check those settings?
 
@s2d4 Not sure if you have this fixed. Sorry about the previously knowledge without knowing the pain on the new GPU. I think I have experienced this issue after I upgraded to 7900XTX from my Nvidia 3080. However, the 2nd GPU 6600 isn't impacted at all.

Here is my fix for my issue, you can adjust accordingly.

Code: 
GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt nomodeset initcall_blacklist=sysfb_init"

Make sure vfio-pci is the driver in use for your GPU when you do lspci -nnk

On the VM GPU passthrough, please download a rom from the website https://www.techpowerup.com/vgabios/
When passthrough, use the following way

Code: 
hostpci0: 0000:03:00,pcie=1,rombar=0,romfile=vga_7900XTX.rom

Try exactly same line and see if it works out for you. After the change, you should be able to passthrough the gpu to any VM freely. The drawback is that I found 7900XTX seems to display images after the machine is booted. (not showing the proxmox bios logo etc.)

Of course, the 1st time you boot up a VM, you need to use Display to Default. Then install AMD driver (make sure it's the full version), during the installation of the driver, you'll see the screen show up on your DP port to the monitor. Next time when you boot, you can set the Display to None and use it directly.
 
Last edited:
frankmanzhu said:
@s2d4 Not sure if you have this fixed. Sorry about the previously knowledge without knowing the pain on the new GPU. I think I have experienced this issue after I upgraded to 7900XTX from my Nvidia 3080. However, the 2nd GPU 6600 isn't impacted at all.

Here is my fix for my issue, you can adjust accordingly.

Code: 
GRUB_CMDLINE_LINUX_DEFAULT="quiet iommu=pt nomodeset initcall_blacklist=sysfb_init"

Make sure vfio-pci is the driver in use for your GPU when you do lspci -nnk

On the VM GPU passthrough, please download a rom from the website https://www.techpowerup.com/vgabios/
When passthrough, use the following way

Code: 
hostpci0: 0000:03:00,pcie=1,rombar=0,romfile=vga_7900XTX.rom

Try exactly same line and see if it works out for you. After the change, you should be able to passthrough the gpu to any VM freely. The drawback is that I found 7900XTX seems to display images after the machine is booted. (not showing the proxmox bios logo etc.)

Of course, the 1st time you boot up a VM, you need to use Display to Default. Then install AMD driver (make sure it's the full version), during the installation of the driver, you'll see the screen show up on your DP port to the monitor. Next time when you boot, you can set the Display to None and use it directly.
Click to expand...
Thank you for your suggestions, however, I don't believe I was having issues with vfio-pci not being used, as evidenced by my previous posts that included lspci -k outputs.

The issue is always this
error writing '1' to '/sys/bus/pci/devices/0000:03:00.0/reset': Inappropriate ioctl for device
failed to reset PCI device '0000:03:00.0', but trying to continue as not all devices need a reset

I know you are steering away from doing vendor_reset but ignoring it will always lead to this:
kvm: vfio: Unable to power on device, stuck in D3
kvm: vfio: Unable to power on device, stuck in D3

This is because it is not in a clean state and thus the VM cannot initialise it.

I looked further into why vendor_reset is not working:
ls -l vendor-reset/src/amd/
drwxr-xr-x 3 root root 4096 May 22 15:59 amdgpu
-rw-r--r-- 1 root root 1153 May 22 15:59 amd.h
-rw-r--r-- 1 root root 5978 May 22 15:59 common.c
-rw-r--r-- 1 root root 1132 May 22 15:59 common_defs.h
-rw-r--r-- 1 root root 5956 May 22 15:59 common.h
-rw-r--r-- 1 root root 1344 May 22 15:59 compat.c
-rw-r--r-- 1 root root 2027 May 22 15:59 compat.h
-rw-r--r-- 1 root root 4010 May 22 15:59 firmware.c
-rw-r--r-- 1 root root 1024 May 22 15:59 firmware.h
-rw-r--r-- 1 root root 836 May 22 15:59 Makefile
-rw-r--r-- 1 root root 7228 May 22 15:59 navi10.c
-rw-r--r-- 1 root root 3955 May 22 15:59 polaris10.c
-rw-r--r-- 1 root root 14245 May 22 15:59 vega10.c
-rw-r--r-- 1 root root 4972 May 22 15:59 vega20.c

9070xt is NAVI48 (RDNA 4) and thus not supported.

If using a hookscript to directly do it at the drivers level, then you end up with the following issue so again not supported:
kvm: ../hw/pci/pci.c:1654: pci_irq_handler: Assertion `0 &lt;= irq_num &amp;&amp; irq_num &lt; PCI_NUM_PINS' failed.

My observation is that there does not appear to be a way of getting this (vendor_reset) to work currently via proxmox or anything qemu/kvm based.
 
Last edited:
Code: 
error writing '1' to '/sys/bus/pci/devices/0000:03:00.0/reset': Inappropriate ioctl for device
failed to reset PCI device '0000:03:00.0', but trying to continue as not all devices need a reset
The above is a warning. You can safely ignore it. I got this message and it didn't prevent me passing the gpu around lots of times.

So let's say you use your hook script and get this. Apply vendor reset hook first.
kvm: ../hw/pci/pci.c:1654: pci_irq_handler: Assertion `0 &amp;lt;= irq_num &amp;amp;&amp;amp; irq_num &amp;lt; PCI_NUM_PINS' failed.

Please use the following method. (You are on a working kernel, not bad kernels cause this, I vaguely remember there are some kernels creating this issue no matter what.)

On the VM GPU passthrough, please download a rom from the website https://www.techpowerup.com/vgabios/
When passthrough, use the following way

Code: 
hostpci0: 0000:03:00,pcie=1,rombar=0,romfile=Your9070XT.rom

Use exact format like above and see if the error is gone. That's how I resolve it on my 7900XTX. And you are right, newer hardware might come across newer issues.
 
Last edited:
frankmanzhu said:
Code: 
error writing '1' to '/sys/bus/pci/devices/0000:03:00.0/reset': Inappropriate ioctl for device
failed to reset PCI device '0000:03:00.0', but trying to continue as not all devices need a reset
The above is a warning. You can safely ignore it. I got this message and it didn't prevent me passing the gpu around lots of times.

So let's say you use your hook script and get this. Apply vendor reset hook first.
kvm: ../hw/pci/pci.c:1654: pci_irq_handler: Assertion `0 &amp;lt;= irq_num &amp;amp;&amp;amp; irq_num &amp;lt; PCI_NUM_PINS' failed.

Please use the following method. (You are on a working kernel, not bad kernels cause this, I vaguely remember there are some kernels creating this issue no matter what.)

On the VM GPU passthrough, please download a rom from the website https://www.techpowerup.com/vgabios/
When passthrough, use the following way

Code: 
hostpci0: 0000:03:00,pcie=1,rombar=0,romfile=Your9070XT.rom

Use exact format like above and see if the error is gone. That's how I resolve it on my 7900XTX. And you are right, newer hardware might come across newer issues.
Click to expand...

Yes, I tried that and the replies are as per that last reply.
s2d4 said:
The issue is always this
error writing '1' to '/sys/bus/pci/devices/0000:03:00.0/reset': Inappropriate ioctl for device
failed to reset PCI device '0000:03:00.0', but trying to continue as not all devices need a reset

I know you are steering away from doing vendor_reset but ignoring it will always lead to this:
kvm: vfio: Unable to power on device, stuck in D3
kvm: vfio: Unable to power on device, stuck in D3

This is because it is not in a clean state and thus the VM cannot initialise it.
Click to expand...
 
s2d4 said:
It's a 9070xt, the pricing here doesn't make much sense unfortunately.
Click to expand...
That GPU is not at all supported by vendor-reset, so that's a red herring and there is really no point in trying to use it for this purpose.
The 9000-series has reset issues, which has not been fully solved AFAIK, and it also may depend on the brand and exact model whether it resets properly or not.
It's very new and the latest information on VFIO can usually be found in the Level1Techs forum, for example: https://forum.level1techs.com/t/vfio-pass-through-working-on-9070xt/227194 .
Did you see this thread on this forum: https://forum.proxmox.com/threads/working-amd-rx-9070xt-support.163370/ ?
 
  • Like
Reactions: s2d4
leesteken said:
That GPU is not at all supported by vendor-reset, so that's a red herring and there is really no point in trying to use it for this purpose.
The 9000-series has reset issues, which has not been fully solved AFAIK, and it also may depend on the brand and exact model whether it resets properly or not.
It's very new and the latest information on VFIO can usually be found in the Level1Techs forum, for example: https://forum.level1techs.com/t/vfio-pass-through-working-on-9070xt/227194 .
Did you see this thread on this forum: https://forum.proxmox.com/threads/working-amd-rx-9070xt-support.163370/ ?
Click to expand...
Thanks for pointing that out. Looks like the passthrough is doable from the thread. Just a little extra to workaround the vendor reset issue.
 
leesteken said:
That GPU is not at all supported by vendor-reset, so that's a red herring and there is really no point in trying to use it for this purpose.
The 9000-series has reset issues, which has not been fully solved AFAIK, and it also may depend on the brand and exact model whether it resets properly or not.
It's very new and the latest information on VFIO can usually be found in the Level1Techs forum, for example: https://forum.level1techs.com/t/vfio-pass-through-working-on-9070xt/227194 .
Did you see this thread on this forum: https://forum.proxmox.com/threads/working-amd-rx-9070xt-support.163370/ ?
Click to expand...
Thank you very much for those links, I'll go over them over the weekend.
 
leesteken said:
That GPU is not at all supported by vendor-reset, so that's a red herring and there is really no point in trying to use it for this purpose.
The 9000-series has reset issues, which has not been fully solved AFAIK, and it also may depend on the brand and exact model whether it resets properly or not.
It's very new and the latest information on VFIO can usually be found in the Level1Techs forum, for example: https://forum.level1techs.com/t/vfio-pass-through-working-on-9070xt/227194 .
Did you see this thread on this forum: https://forum.proxmox.com/threads/working-amd-rx-9070xt-support.163370/ ?
Click to expand...
Update - WORKING! :D

This required later version kernel as it wouldn't work on default on 6.8, I ended up using 6.14.0-2.
vendor-reset should not be used for anything beyond NAVI10 (RDNA 1), and perhaps at all considering the use of the working hookscript.

Thank you, you are definitely an indispensable resource on this forum! ( You came up in a lot of the passthrough threads, loved some of the correction posts you made too, lol)
 
Last edited:
You must log in or register to reply here.
Top Bottom