-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sun, Jul 21, 2024 at 09:37:12PM -0400, privacymiscoccas...@cock.li wrote: > Hi everyone, > > First, a big thank you to the hardworking developers of Qubes OS. It is an > OS I have been reading about and hope to use soon to secure my digital life. > > I came across the project on supporting "GPU acceleration" > (https://github.com/orgs/QubesOS/projects/17), and did some cursory reading > on (specifically) Intel GPU acceleration for VMs because this is something I > am interested in. > > I ahev listed a few resources, but in short: Intel's GVT-g allows one to > create SR-IOV-esque slices of the iGPU while also letting the host (dom0 for > us) use the GPU like usual. This is great because if someone has anything > from the 5th to 10th gen Intel processors and isn't doing some very > heavy-duty window border graphics (talking specifically about how Qubes OS > works, using the compromise from `sys-gui`), the iGPU is mostly being > under-utilized. > > Note that this is specifically for Intel processors from 5th gen to 10th gen > (after which SR-IOV is the official supported method). > > Resources: > 1. Venerable Arch wiki: https://wiki.archlinux.org/title/Intel_GVT-g > 2. Intel's set-up guide: > https://github.com/intel/gvt-linux/wiki/GVTg_Setup_Guide#562-create-xengt-vm > 3. IOV support matrix: https://open-iov.org/index.php/GPU_Support > 4. Xenserver confirmation of support: > https://docs.xenserver.com/en-us/citrix-hypervisor/graphics/hv-graphics-config.html#intel-gvt-d-and-gvt-g > 5. Related XCP-ng forum thread: > https://xcp-ng.org/forum/topic/6259/intel-gvt-g-vgpu-support-for-intel-igpu-s-how-do-i-enable-this/3 > and video in german: https://www.youtube.com/watch?v=FW9TPMrdTYc > 6. The last time this was mentioned in the crosvm forums, and was promptly > declined: > https://groups.google.com/a/chromium.org/g/chromium-os-discuss/c/jXAQvTY-rU8/m/24CNeOgJBAAJ > 7. If relevant, KVM tutorial (there's plenty of them since this is > supported): > https://forum.level1techs.com/t/tutorial-on-how-to-use-gvt-g-to-share-an-intel-igpu-with-a-windows-vm/157363 > > This picture might be helpful in visualizing what I mean: > https://open-iov.org/index.php/File:Intel_GVT-g_Capabilities.png > > Of course, I can see the glaring problem; Demi Marie Obenour has selected > `crosvm` via the `vhost-user`. From my cursory reading I feel confident in > the security posture being maintained here, but I was wondering if Intel > GVT-g and accompanying SR-IOV features would be considered. > > Thank you again, dear devs, for the wonderful work.
SR-IOV will absolutely be supported as soon as it makes its way into the upstream Linux kernel. Unfortunately, SR-IOV requires the Xe driver, which only officially supports Xe2 GPUs. This means Lunar Lake (15th generation) and later, which have not yet shipped. The official driver for currently available GPUs is i915, which has no SR-IOV support in the upstream version shipped in Qubes OS. Therefore, only Xe2 GPUs will support SR-IOV. There is an out-of-tree version of i915 that has SR-IOV support. However, Intel only supports it with datacenter GPUs. There are unofficial kernel modules for use with consumer GPUs (generation 11 through 14 inclusive), but I don't recommend them. Once Xe2 GPUs are available, they will be my recommendation for GPU acceleration in Qubes OS until native contexts ship. They can be configured via sysfs, so no special userspace tools are needed, and VFs appear as regular PCI devices that can be directly attached to a VM using the existing Qubes OS toolstack. I’ve CCd the Qubes Security Team to see if SR-IOV will be a security supported configuration. My understanding is that GVT-g has been discontinued. It required complex emulation in the dom0 kernel, which means that it had substantial attack surface. Since the code is no longer maintained, I suspect it is likely to have unfixed vulnerabilities. SR-IOV and DRM native contexts (which is what crosvm uses) are not mutually exclusive. A VM with an SR-IOV VF can provide DRM native contexts to another VM, providing a second layer of protection in case of a vulnerability in native contexts and limiting the impact of a VF reset. More generally, the hardware device backing DRM native contexts can either be a physical function or a virtual function, and the same VM should be able to use a virtual function and native contexts simultaneously. The main advantage of DRM native contexts over SR-IOV is portability. It should be possible to support native contexts on any hardware that Linux supports, whereas SR-IOV (obviously) requires hardware and driver support. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmae6PwACgkQsoi1X/+c IsHrWBAAnqm2GoAkAc5VAum2LoaTQ20cjRdXmyKUDo/CzyUkz65XFH5nIELs8oij TJnmA2UTd5okKTvF1CuzU/pYeh7mgb+CR15XYnIW0sSYj4omue8FLTkwMZUJc0EP XbFM/T+B5gwFP496DPjfCjvnXETLz9wO8XHAbBeUsSmsJtmSyAwUDfGuMX0UgVbK pGEM/LCF0B1jbTxx6e5Dh5AZfZNdkQY0DiZu5FUTdyt1rIF7wqde9JkOeHSZXre1 8HWeAnormf0ACu2cxf99zeN+F7lhPfdwedL0Cj6UP0T3sZj2zsvofxUzHZs3VLDd hzdKtvD1Hfn5y4wyVxsQrIGmN2FT6h8UIZGicLyJoQn/V6LYLS1C27OoyyRcm1Jx mpl2Ngs4Sau/OBT1jQ8joP6DeDxiKJzC/cpHB8qB1V1Qe+M22ApRlcudwcH1bfcI utgOay40vDzCCcr63pwpiPCZx6hhYOaWXsbQ3gilgrv5Yu49V3PIUD8L99JKGSz+ xwos7qtlpG9pXBxvJi35c/T0cEh7d3iQBFlbmfj1j/6Vu8TrIdoB7tU4Pj4nU5Ni fB6hXdglP4v86TPT2Kw442k5V6b7rLSjfpi45ykNAhZDZjCMpBTx2fJ4VXO9Uit1 M68z+b0H2T7Dt5LnMI5AvNkpWQ6DoHy1KPXBaN3TG6yuhkfNbCY= =Ceyh -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zp7o_CUOkxGQt2JE%40itl-email.
