This from the chap behind the IGD passthrough code in QEMU is very useful:
https://git.qemu.org/?p=qemu.git;a=blob;f=docs/igd-assign.txt;h=e17bb50789ada12b210897a5574bf89ee64b80fb;hb=HEAD
Just to report back that a deb-patched deb package has brought the functionality back via Proxmox server (subject to suppressing PCI bridge 2 as per https://forum.proxmox.com/threads/igd-passthrough-and-hard-coded-pci-bridges.68285)
Okay. Great - it being overridden is fine. In the meantime I figured out a patch that will work for all builds:
diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index 2d348f8237..a633df965e 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -25,6 +25,7 @@
#include...
My fix is simply defining CONFIG_VFIO_IGD which I'm not sure will wash with them ;). I'm not familiar enough with their process to see how to introduce a preprocessor variable from a kconfig variable.
But since Proxmox always has CONFIG_PCI I might make it a deb patch. If I do, and install...
Instead of messing around with Proxmox patches I've reproduced the bug (and fix) in clean upstream sources. Filed a bug here:
https://bugs.launchpad.net/qemu/+bug/1882784
Thanks for the attention and help - I'm not sure if this should be marked solved as of now?
I'll be using a patched QEMU...
So I've verified that the normal build pulls in the refactored IGD code, and that it still doesn't work.
Reverting the patch however does.
I'll follow up with upstream, but in the meantime would the pve patches be doing something? I do doubt it but I thought I'd ask.
Ah, thanks for the insight, that package did the trick.
Regarding the QEMU5 commit I understood the same, that it should be there with CONFIG_PC_PCI, so reverting the patch will be part of my investigation.
I'm specifically looking for where for example CONFIG_PC_PCI might be defined. I'm...
Thanks for the reply. I've since made some progress but am now getting the following error trying to compile in a debian 10 container. I'll read the dev docs to see if there are any clues.
In file included from /root/pve-qemu/pve-qemu-kvm-5.0.0/include/qemu/timer.h:4,
from...
@Becod how did you get on? I'm getting the following error when trying to compile in a Debian Buster container:
In file included from /root/pve-qemu/pve-qemu-kvm-5.0.0/include/qemu/timer.h:4,
from /root/pve-qemu/pve-qemu-kvm-5.0.0/include/qemu/timed-average.h:29...
Legacy IGD passthrough appears to have some further issues. I've started a new thread here:
https://forum.proxmox.com/threads/qemu-5-and-legacy-igd-passthrough.71036/
I've found a possible issue with QEMU5. I've described the issue further here:
https://forum.proxmox.com/threads/qemu-5-and-legacy-igd-passthrough.71036/
6.2 may have broken VMs that use legacy IGD passthrough.
This is somewhat related to https://forum.proxmox.com/threads/igd-passthrough-setup-broke-with-proxmox-6-2.69670, except legacy IGD PT also relied on a quirk in qemu. This quirk used to be generally available, but since QEMU 5 has become...
I'm interested in this (I currently monitor smart on the host).
My question is how are you managing to keep the host disk in the host if you're passing through the whole controller?
Edit: I see the host uses an nvm drive.
The code specifically doesn't create the bridges with q35 (see above).
The VFIO guys insist that legacy passthrough will never work with q35, so it's probably something else. That said, they said the same about OVMF and it works there! But with coffee lake I think you can use UPT and not legacy...
I edited the file at:
./usr/share/perl5/PVE/QemuServer.pm
and ran
pvedaemon restart
And have resolved the issue.
I commented out $bridges->{2} = 1; to avoid creating the second extra bridge. The alternative would be to keep it at a different address, but I feel that this might be safer...
I have successfully managed to pass through my P4600 IGD to a VM. However I could only get it working up to a machine of pc-i440fx-2.2.
The error given with pc-i440fx > 2.2 was that the address 1f.0 was in use by another device and the vfio legacy IGD passthrough requires this address to be...
@Symbol that is what was understood by @Klaus Steinberger first reply, but a later posted suggested that having the discard option set on the Virtio adaptor was alone enough.
Hence the testing. The confusion appears to be in the PE option and the fstab option both being using the word...
I just did some tests, and with the VirtIO SCSI discard option on, deleting a (large) file from the guest DOES NOT reduce the usage on the host.
When fstrim is run in the guest, the usage is then reduced in the host.
As such, the recipe in #4 is the approach I'm taking.
EDIT: Running fstrim...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.