There are some guides, but it's very hardware-dependent and touch and go. It took me a couple of weeks to get all of the bugs worked out and things running reasonably smoothly. I would not recommend it for the faint of heart, or those without significant sysadmin experience.

On consumer hardware, it can be hard to find out if you even have IOMMU support, required for passthrough. It's not necessarily new but a lot of hardware doesn't support it. Unfortunately for me, my i7-3770k did not have it (but the i7-3770 non-K did). I did the hypervisor build on a new enterprise-class workstation with a Supermicro motherboard.

I use libvirt for the config. I started to build a custom kernel to enable some extra features, since I had to compile dev branches anyway to troubleshoot periodic hard locks on kernels 4.12 and 4.13, but the setup should work with a stock kernel.

For me, the biggest hangups on the checklist were:

a) Ensure 100% UEFI everywhere. It's possible to do this with BIOS but as far as I understand, not well tested anymore. It can also be hard because of the way boards are sort of straddling a middle ground between UEFI and BIOS; if you don't set everything to explicit UEFI in the setup, it may init the system with either, or may init the BIOS first for hardware compat, which will make things weird.

If your video card is slightly older and from the time when UEFI was just getting supported by PC mobos and does not have UEFI boot, you may be able to find a UEFI-compatible video BIOS online. I had to do this for my GTX 670 (I use a 1070 most of the time though, and it did not need this).

b) Kernel VGA options, particularly video=efifb:off. In theory you don't need this but it depends on your board, hardware, etc. Ensures that the video device is available for vfio-pci to grab and block out other drivers that may try to grab it later. The downside is no video out after the bootloader so you can't watch the boot process. I use a USB serial port to watch the boot now, but for a long time I just waited until SSH came up, and if it didn't come up, used the systemd emergency console to try to poke it blind. This made things far harder than necessary. Get serial output ASAP, or use a board with a built-in IPMI. Didn't realize it was possible to order the workstation I got without it, or I would've made triple-sure I had it. Would've made things way less aggravating.

Along the same lines, having multiple GPUs helps a lot with this, especially if you can configure your system and/or move things around in their slots so that the one you don't want to passthrough gets initialized first. Then you don't have to worry as much about competing with the system EFI, bootloader, or kernel for raw control over the device. Not strictly necessary, but useful.

c) nvidia Code 43 on passthrough. This is nvidia trying to extort some sort of ridiculous data center license out of you or something. There are various potential fixes that are somewhat easy to find floating around, particularly QEMU flags, but this is another one that you just have to poke around until you find a combination of options that work. For recent drivers, one of these things is setting the initial substring of your mobo name to a recognized consumer vendor in QEMU/libvirt.

d) For good sound in the Windows VM, need to hack the driver ini to use MSI for interrupts, which requires running in Windows "Test Mode", aka unsigned driver mode. This breaks some anti-cheat software and I returned PUBG because it didn't allow the game to start while Windows is in Test Mode. You also have to set / tweak specific custom args on QEMU and the host's PulseAudio to get the timing right. Without this, the audio drifts very noticeably out of sync. Alternately, passthrough your sound card or use HDMI audio.

Obviously there were a bunch of other little hiccups but this is what stands out to me off the top of my head. Best resources are Arch Linux wiki on passthrough, Proxmox forums, and /r/vfio.

All this said, the biggest source of pain was not related to IOMMU or virt at all, but rather LVM2-based thin provisioning and device mirroring before I switched as much as I could to ZFS (still working on the last few pieces). ZFS is somewhat stricter but it works reliably. LVM would frequently make boot hang, fail to reinitialize the volumes correctly, etc.

Happy to help anyone going down the same road. It's really a great setup once it's running and I'm sure there'd be more envy for it if I had the energy to do a big write up that showcased it to everyone. :P