I am able to do GPU passthrough on the standard 3.16 Kernel that comes with Debian Jessie without any problems using KVM.

Motherboard: AsRock Z170 Pro4 Skylake ATX
Chip: Intel Pentium i3 Dual-Core i3-6300 3.8 GHz
GPU (for passthrough): NVIDIA Corporation GK104 [GeForce GTX 760]
OS: Debian Jessie (8)

Doing something along the lines in this howto

The problem is that Skylake is not supported very well until kernel 4.3 or so and I can't run dual monitors or onboard sound.

I installed kernel 4.5.0 and xserver-xorg-video-intel from jessie-backports and my sound and intel graphics work brilliantly.

However now when I run the VM's there is no output from the Nvidia card (not even a post screen) and no error messages shown. I have updated initramfs for the new kernel and ensured that pci-stub is still claiming the addresses. I have also tried using vfio to claim the addresses at boot without any success.

On a straight Debian Stretch install I had the same problem but when I tried using OVMF instead of seabios, I did get a post screen from the nvidia card but being EFI it obviously wont boot my guest os's. This does not work either though on the setup described above.

No-one else has reported this issue that I can find. I have been trying to get it to work for days without any luck.

Anyone had similar problems or know what the problem might be?

The thing about ' the bleeding edge' is that bloodletting is likely. We sense your pain. It may be up to you. File a bug.

On a separate note, Debian is not noted for running with the latest versions - quite the reverse, in fact. That mightn't be the smartest base for a bleeding edge kernel. What version of kernel headers have you?

Indeed. Problem is I don't know where the bug is! QEMU? Kernel 4.5? KVM module? - no reported errors.
I did try it on Testing/Stretch with similar results. It didn't work with no headers installed or with headers for both kernels.

Kernel 4.5+ works fine with gpu passthrough under Arch. I am using an IvyBridge system though. I do use OVMF: what's the guest OS?

You would want the latest headers for the bleeding edge kernel. 2sets of headers is a bad notion. Then try it and report a specific error message. "It won't work" is totally inadequate for diagnostic purposes.

It works under Debian Stretch using OVMF (I was able to boot a Mint live CD) but my guests are legacy bios. They are Linux Mint 17.3 and Windows 7.
I don't understand why the kernel headers would come into it - I am not building modules from source, or are you suggesting I should?
See my OP. There are no error messages reported.

You can run Windows 7 under OVMF, don't know about Mint 17.3. As far as posting a bug, it it might be hard to track down or reproduce for anyone else because your setup is a little unique. If you revert to your original kernel, does the problem persist? Same with your xserver; if you revert it but keep kernel 4.5, does the problem persist? Do you have the latest seabios?

You can run both on UFI firmware but it means reinstalling. I thought about that but the windows install ISO failed to boot!!
No. I currently have both kernels installed and I can choose which to boot on the grub menu. This is how I am dealing with the problem at the moment. If I want to run VM's I boot the 3.16 kernel and if I want 2 screens and sound (without having to plug a USB sound card in) I boot the 4.5. Not ideal!
I am using the xserver that comes with debian stable/Jessie. Graphics don't work at all (on the host) if I use the new kernel with the old Intel graphics drivers.
I have tried the Debian packaged version from Jessie (1.7.5-1) and also I compiled from latest release (1.9.2) both with the same result - blank screen!!

UEFI reinstalls: yeah that's easiest, but you can migrate Windows 7 from MBR to GPT then use OVMF. I did, no reinstall, but ymmv.

Mint should be easier: back up with rsync, make a new machine and restore.

Kernel versions: if you are determined to find where the problem is, I guess you could bisect until you find the offending change, look at the kernel change logs and file a bug. A lot of work, and unfortunately, since your system is non-standard, no one may care to fix it or be able to. One reason I switched to Arch from Slackware is that when you have a stable base system and use a much newer kernel, you get these kind of weird problems and no one but you has them.

OVMF only worked on testing/stretch and I have now reverted back to stable using kernel from backports (because there where other problems and glitches on testing that i couldn't live with). With this setup even OVMF doesn't work
Too much for me ATM. I have too much else on to be delving into the problem that far! I guess I will live with booting separate kernels until maybe someday it is fixed or I have time to look into it further. Thanks for your input though.

PS: DNA - Awesome - RIP