Git-Mirrors/Qubes-Community-Content
1
0
Fork 0
mirror of https://github.com/Qubes-Community/Contents.git synced 2024-10-01 01:05:51 -04:00
Code Issues Packages Projects Releases Wiki Activity
7ad1ff5e25
Qubes-Community-Content/docs/customization/windows-gaming-hvm.md
awokd 7ad1ff5e25 Update docs/customization/windows-gaming-hvm.md 
Co-Authored-By: neowutran <me@neowutran.ovh>
2019-04-10 20:52:53 +02:00

5.8 KiB
Raw Blame History

layout title permalink
doc Windows gaming hvm /doc/windows-gaming-hvm/

Windows gaming HVM

Some information to configure a windows HVM for gaming. This is not officially supported, just some community trial & errors

References

Everythings needed is referenced here

Prerequise

You have a functional Windows 7 HVM.

The "how to" for this part can be found on the Qubes OS documentation and here: Useful github comment.

However, few tips:

  • Do a backup (clone VM) of the Windows HVM BEFORE starting to install QWT
  • The Windows user MUST BE "user"
  • Windows 7 Only, do not use Windows 10 or others.

Hardware

To have a Windows HVM for gaming, you must have:

  • A dedicated AMD GPU. By dedicated, it means: it is a secondary GPU, not the GPU used to display dom0. Nvidia GPU are not supported (or maybe with a lot of trick).
  • A really fast disk (M.2 disk)
  • A lot of RAM
  • A dedicated screen

In my case, I use:

  • Secondary GPU: AMD RX580
  • Primary GPU: Some Nvidia trash, used for dom0
  • 32 GB of RAM. 16 GB of RAM will be dedicated for the Windows HVM
  • A fast M.2 disk

Checklist

Short list of things to do to make the GPU passthrough work:

  • In dom0, you edited the file /etc/default/grub or /boot/efi/EFI/qubes/xen.cfg to allow PCI hiding for your secondary GPU, and regenerated the grub if needed
  • You patched your stubdom-linux-rootfs.gz to allow to more than 3 GB of RAM for your Windows HVM

GRUB modification

You must hide your secondary GPU from dom0. To do that, you have to edit the GRUB.

In a dom0 Terminal, type:

qvm-pci

Then find the devices id for your secondary gpu.

In my case, it is "dom0:0a_00.0" and "dom0:0a_00.1".

Edit /etc/default/grub, and add the PCI hiding

GRUB_CMDLINE_LINUX="....rd.qubes.hide_pci=0a:00.0,0a:00.1 "

then regenerate the grub

grub2-mkconfig -o /boot/grub2/grub.cfg

Or if using UEFI boot, edit /boot/efi/EFI/qubes/xen.cfg and add the rd.qubes.hide_pci= option to the kernel= line.

Patching stubdom-linux-rootfs.gz

Follow the instructions here: https://github.com/QubesOS/qubes-issues/issues/4321#issuecomment-423011787

Copy-paste of the comment:

This is caused by the default TOLUD (Top of Low Usable DRAM) of 3.75G provided by qemu not being large enough to accommodate the larger BARs that a graphics card typically has.
The code to pass a custom max-ram-below-4g value to the qemu commandline does exist in the libxl_dm.c file of xen, but there is no functionality in libvirt to addthis parameter.
It is possible to manually add this parameter to the qemu commandline by doing the following in a dom0 terminal:

```bash
mkdir stubroot
cp /usr/lib/xen/boot/stubdom-linux-rootfs stubroot/stubdom-linux-rootfs.gz
cd stubroot
gunzip stubdom-linux-rootfs.gz
cpio -i -d -H newc --no-absolute-filenames < stubdom-linux-rootfs
rm stubdom-linux-rootfs
nano init3

Before the line "# $dm_args and $kernel are separated withx1b to allow for spaces in arguments." add:

SP=$'\x1b'
dm_args=$(echo "$dm_args"\
sed"s/-machine\\${SP}xenfv/-machine\
\\${SP}xenfv,max-ram-below-4g=3.5G/g")

Then execute:

find . -print0 | cpio --null -ov\
--format=newc | gzip -9 > ../stubdom-linux-rootfs
sudo mv ../stubdom-linux-rootfs /usr/lib/xen/boot/

Note that this will apply the change to all HVMs, so if you have any other HVM with more than 3.5 GB ram assigned, they will not start without the adapter being passed through. Ideally to fix this libvirt should be extended to pass the max-ram-below-4g parameter through to xen, and then a calculation added to determine the correct TOLUD based on the total BAR size of the PCI devices are being passed through to the vm.

Pass the GPU

In qubes settings for the windows HVM, go to the "devices" tab, pass the ID corresponding to your AMD GPU. (in my case, it was 0a:00.0 and 0a:00.1)

And check the option for "nostrictreset" for those.

In some case, you might also need to set the "permissive" flag to true (But I didn't need that with the RX 580):

qvm-pci attach windows-hvm dom0:0a_00.0 -o permissive=True -o no-strict-reset=True
qvm-pci attach windows-hvm dom0:0a_00.1 -o permissive=True -o no-strict-reset=True

Conclusion

Don’t forget to install the GPU drivers, you can install the official one from AMD website, no modification or trick to do.

Nothing else is required to make it work (in my case at least, once I finish to fight to find those informations).

If you have issues, you can refer to the links in the first sections.

If it doesn’t work and you need to debug more things, you can go deeper.

  • Virsh (start, define, ...)
  • /etc/libvirt/libxl/
  • xl
  • /etc/qubes/templates/libvirt/xen/by-name/
  • /usr/lib/xen/boot/
  • virsh -c xen:/// domxml-to-native xen-xm /etc/libvirt/libxl/...

I am able to play games on my windows HVM with very good performances. And safely.

Bugs

The AMD GPUs have a bug when used in HVM: each time you will reboot your windows HVM, it will get slower and slower. It is because the AMD GPU is not correctly reset when you restart your windows HVM.

Two solutions for that:

  • Reboot your computer
  • In the windows HVM, use the windows option in the system tray to "safely remove devices", remove your GPU. Restart the HVM.

This bug is referenced somewhere, but lost the link