GPU Passthrough Status - (Purely a meta-discussion, no specifics)
Yuraeitha
The underlying reason it's currently not working, appears to be because of its current state a virtual GPU for a specific VM, would require direct access to dom0. This is deemed a serious security threat breaking a central pillar of what Qubes is all about, attempting to isolate dom0 as far as possibly possible. Therefore, from what I can gather, what we need is virtual GPU operating from an underlying DomU stub-domain, preferably, one separated from another DomU stub-domain, which holds the important and critical VM data and user operations. Thereby it's not only about single virtualization anymore, but also about group segmenting and isolating entire virtual stub-domains. That means, one group of VM's is isolated from another group of VM's. Please correct me if I'm wrong here, it's great for the discussion to have the most accurate information.
Here is a scenario that stresses the above,
https://groups.google.com/forum/#!topic/qubes-users/cmPRMOkxkdA
Managing to make GPU passthrough work, but only by passing it directly to Xen, instead of Libvirt, which in turn, exposes dom0.
Initially, this is all the reasons I can think of for wanting V-GPU.
- Heavy graphic designer job or hobby (movies, animations, etc.).
- Running Qubes on many screens at desk.
- Extending a single Qubes machine around the house or company, using multiple of screens, keyboards/mouses or other thinkable means.
- Gamers who take security and privacy seriously (there is surprisingly many of them out there).
- Cryptocoin miners who wish to utilize a single machine for all round purposes.
- Using a qube as a streaming TV, and want good graphics for the specific TV-VM. For example 4k or even 8k+ or more on multiple tied screens.
Some of these are exotic and probably not many around use them, however, others are quite common. Whichever the case, it's all scenarios with a common problem. The point here, is to underpin the possible use-cases.
I must be tired, I initially wrote 'qubestions' instead of 'questions' here...
aight, so possible questions for the discussion.
- What would it take for Qubes to obtain stubdomains in a feasible means to allow safe GPU Passthrough?
- Are there other problems that needs solving too? If so, which ones?
- What is the grand big picture status between the above two questions?
- Are there currently any plans for any of these required implementations? For example Qubes stub-domains in Qubes 4.1? Qubes 5? or are they still unplanned? If planned, or in part planned, like only halfway there, then, what are these plans? Please elaborate.
- Other possible questions you can think of.
I'm sure there are aspects I did not think of, but that's fine, after all, this is a discussion. This initial post is just to kick it off. The purpose is to combine information that a few selected individuals might be sitting on, with the many users who do not know about the current state. Thereby, building community awareness of the current situation. Whatever you got to say, or ask, about GPU Passthrough, this thread can be used for that! The only limitation, is that it is a discussion, and not a place to ask how to get your own specific case of GPU Passthrough to work. It's a general, meta discussion.
What is your thoughts on the matter?
awokd
> Aight, so the idea of this thread, is to get an overview of where we
> stand, that is, how far are we away from archiving GPU Passthrough on
> Qubes.
hardware capable of virtualization such as Nvidia Grid, Radeon Sky(?),
Intel GVT-g and hypervisor support.
https://www.nvidia.com/object/grid-technology.html
https://www.amd.com/en-us/innovations/software-technologies/sky
https://01.org/igvt-g
https://code.vmware.com/article-detail/-/asset_publisher/8n011DnrSCHt/content/vsga-datasheet
https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-configuring-graphics.pdf
Not something I've ever played with, but it seems kind of like IOMMU to
me. You could write a software layer to provide slow virtualized GPUs, or
use hardware for faster ones.
Of these, it seems like Intel's approach is the most open source friendly.
XenGT has working code. No idea how hard it would be to integrate with
Qubes, though.
> I must be tired, I initially wrote 'qubestions' instead of 'questions'
> here... aight, so possible questions for the discussion.
Yuraeitha
> On Sat, December 16, 2017 2:25 am, Yuraeitha wrote:
> > Aight, so the idea of this thread, is to get an overview of where we
> > stand, that is, how far are we away from archiving GPU Passthrough on
> > Qubes.
>
> If you look at how the "competition" is approaching it, you need GPU
> hardware capable of virtualization such as Nvidia Grid, Radeon Sky(?),
> Intel GVT-g and hypervisor support.
>
> https://www.nvidia.com/object/grid-technology.html
> https://www.amd.com/en-us/innovations/software-technologies/sky
> https://01.org/igvt-g
> https://code.vmware.com/article-detail/-/asset_publisher/8n011DnrSCHt/content/vsga-datasheet
> https://docs.citrix.com/content/dam/docs/en-us/xenserver/xenserver-7-0/downloads/xenserver-7-0-configuring-graphics.pdf
>
> Not something I've ever played with, but it seems kind of like IOMMU to
> me. You could write a software layer to provide slow virtualized GPUs, or
> use hardware for faster ones.
>
> Of these, it seems like Intel's approach is the most open source friendly.
> XenGT has working code. No idea how hard it would be to integrate with
> Qubes, though.
>
That's a very interesting perspective, to bring in the market movements and other open source developments into the discussion as well, possibly detecting spots that might work together with Qubes. The competition also seems to be getting more fierce as virtual augmentation and reality becomes bigger? That's a very good idea for topic discussion too, I agree. It's interesting questions you set in motion, like for example to ponder over how far these developments can be be put together with Qubes with our current or emerging means of tomorrow.
Between software or hardware controlled IOMMU graphics, maybe the question for Qubes is which one of them is more secure though? I'm not a code developer my self, but from what I understand, complex software is hard to make secure, compared to well-made hardware minimizing use of software. If Qubes hypothetically were to adopt these, would the hardware approach be more secure here? Or maybe one can even use software controlled IOMMU in a less secure Stub-domain, for less important things as well? Kind of like a Qubes opt-in feature? I wonder how feasible this would be though, but it sounds really attractive to have user-choices like these.
I haven't read through all the links and their interconnected topics yet, but plan to do that over the next couple of days as I have more time. The ones I read were quite interesting to read already.
> > I must be tired, I initially wrote 'qubestions' instead of 'questions'
> > here... aight, so possible questions for the discussion.
>
> I like it! Let's rename the FAQ to Frequently Asked Qubestions.
huehue, mistakes when tired (or even when high) can lead to some interesting places sometimes :-)
Tom Zander
> f, but from what I understand, complex software is hard to make secure,
> compared to well-made hardware minimizing use of software. If Qubes
> hypothetically were to adopt these, would the hardware approach be more
> secure here?
The overall design and concept is what is more important.
The actual approach of how to do this makes or breaks the security mode.
From that approach follows what parts are required to be in hardware (to
still be fast and secure).
I claim no expertise in the domain you address in this thread, so apologies
for the generic answer.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
Tom Zander
> Initially, this is all the reasons I can think of for wanting V-GPU.
> multiple of screens, keyboards/mouses or other thinkable means.
Not sure what your usecase is, but there has to be a better way than
allowing a multitude of foreign, not-directly-connected hardware from
accessing various very security sensitive channels.
...
> for all round purposes.
on the machine. It literally drains money out of your system to use it on
the same hardware as you main desktop.
If you install 8 GPUs on a mainboard, you have to realize that the mainboard
ends up costing a fraction of the total.
Reusing it for non-mining purposes (while mining) just doesn't make any
sense. Both from an economics as well as a security point of view.
nickla...@jordogskog.no
Just to add a use case is all developers doing something including the gpu.
I found Qubes OS the other day and installed it on a secondary pc. It seems great, and besides the security concerns it also gives a great way to organize the computer. To keep work, private and open source projects separated.
I work on TilelessMap, an open source project to keep huge amounts of map data locally (linux, windows or android). Can be view as a privacy project since it makes you independent of connection which reveals what maps you are interested in (where you are in other words).
https://github.com/TilelessMap
It renders the map in openGL som I have a problem adopting Qubes OS on my primary laptop. But I would really love to do it.
write this just to point out that it isn't just gaming that is the use case.
Anyway, Qubes OS looks fantastic, for more or less anything else.
Thanks !
Alex Dubois
I think it makes sense it you are on a budget. But you do not need GPU path-through, you only need CUDA interface, so I believe it is already feasible today.
Use the integrated GPU for Dom0 and all your work VMs.
Have a MiningVM with all the other GPU attached to it.
However ,you probably want a kvm switch to distance yourself from your new radiator and noise generator.