On Thu, Nov 8, 2018 at 11:48 AM Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On Thu, Nov 08, 2018 at 01:52:37AM -0800, John Mitchell wrote: > > On Thursday, November 8, 2018 at 10:24:13 AM UTC+1, Laszlo Zrubecz wrote: > > <snip> > > > > > I should just say: > > > RTFM. > > > > > > But let me share some details: > > > > > > Qubes is supporting PCI-passthrough from the very first release. > > > That is how the sys-net using your network devices. > > > > > > Later releases extended this for USB buses -> now the default install > > > creating a sys-usb Qube for you. > > > > > > What is not working (out of the box) is passing VGA devices. > > > Because this is a different beast. > > > Read the docs, and the previous discussions (on qubes-users) about > > > this if you really interested... > > > > > > And honestly, I believe if you would ever try Qubes OS, you would not > > > start this thread at all. > > > > > > Peace. > > > - -- > > > Zrubi > > > > <snip> > > > > So if I understand correctly, PCI device passthrough is supported but not > > GPU because it can be hacked and compromise the host? > > > > While more difficult or perhaps not mature yet, well maybe not, other PCI > > devices (USB, SATA drives, etc.) can also be hacked. > > > > So it appears security isn't the problem so it must be complexity although > > users are getting it working because zen supports it. > > Yes, the main problem with GPU passthrough is complexity - those devices > abuse PCI specification in so many ways you wouldn't believe... There > are some workarounds, but most require qemu running in dom0, which is a > security issue.
The main actual problem, considering you would never keep the passed through GPU ever in dom0 (always in vfio-pci), is how to reset the device. There are known bugs in Vega and Polaris implementation of PCIe reset so they do not reset right - and additionally some mainboards do not reprogram PCIe configuration space for secondary bridges. Typically the GPU is passed in as a secondary card - skipping the whole VGA passthrough thing. With older driver versions, you had to also specify a ROM file (containing video rom dump), but latest ones do not require it as they have a fallback interface to access AtomBIOS. nVidia on the other hand strictly requires as much hiding of the VM as possible unless you own a Quadro and always have to add the video ROM, but if it's successful it just works. Passing the GPU between VM instances requires belief that device reset for such a complex device has no data leaks... On top of that, you have the problem that some IOMMU implementations do not reset devices fully either. Passing the GPU between VM instances securely requires belief that device reset for such a complex device has no data leaks... If you will never remove the GPU from VM nor stop the VM using it, this shouldn't be a problem - but ensuring that in Windows world is pretty hard with those silly automatic updates. GPU VM, always on, never reset, with some sort of a proxy could avoid this issue. I think Looking Glass project has some reasonable software that can be investigated for this. R. -- 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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CAAmECqRV32dPTadvQJfhPv-rqO4DKV8HNM8gfJ6a_vx_TYpcaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
