It’s still worth a look. I for one would be elated to see this as I’ve been debating whether or not I need to get something with a dGPU, which would set me back at least another 3.5K for my needs and still only serve one VM at a time.
Could be. But modern desktop software becomes less usable with software rendering every day. So there should be a way to turn it off, but most of “normal” users would not.
Seems I was wrong about the future of SR-IOV support for Intel mobile chips. Apparently the new Panther Lake chips will officially support SR-IOV. The expected release date is Q4 2025 or Q1 2026, which is conveniently soon. https://www.phoronix.com/news/Intel-SR-IOV-PTL-ARL-State
Panther Lake was also apparently designed without hyperthreading. This may avoid a whole class of security problems (like the Spectre and Meltdown vulnerabilities). But it may not depending on how cache is implemented, which I know nothing about. Why Intel Panther Lake CPUs Will Not Use Hyper Threading – EJS Computers
IDK how well Xen will handle selecting when to use P cores vs E cores, but if Xen does ok there, Panther Lake might be good laptop hardware for running QubesOS.
2 Likes
there is whole thread about optimizing Qubes for heterogenous core layout on newer CPUs. But i still wonder if Meteor Lake would be any good for virtual GPU.
So, still no luck. Funny, I could as well just skip my last hardware upgrade. To add insult to injury, i was also prematurely forced to 4.3 because Meteor Lake is unsupported by 4.2 :))
The spike in RAM prices is another insult to add to the injury list too…
1 Like
I managed to virtualize my iGPU via SR-IOV. So this is at least on Intel possible. But requires you to load an out of tree Kernel Module in dom0. So it should be considered dangerous unless you can understand the code and check it.
Also of course this is unofficial.
See here for the Guide.
I wonder how it would work with sys-gui.
Probably not, because the generated PCI devices wont be availbale to dom0
Why it should be available for dom0?
Ah, sys-gui. I I’m more akin to sys-gui-gpu.
Oh, i see. In my head sys-gui was the same as sys-gui-gpu (obviously not true…).
So if the GPU is still in dom0 (sys-gui) it should work. If the GPU is in another VM (sys-gui-gpu) I would thinkt that it doesn’t work, because the virtualised GPUs would also appear in that VM.
With sys-gui-gpu pci gpu device is in sys-gui-gpu (server, display machine) and dom0 is another VM client. So this sr-iov dkms need to be done in sys-gui-gpu.
But it’s still in early alpha state, not production/usage ready so I won’t test it.
But I wonder if it’s doable there.
Based on what I understand from SR-IOV, you could do that in dom0 and pass a virtual GPU to sys-gui-gpu. So that dom0 is still managing the hardware, but the GUI is all done on sys-gui-gpu.
While it would surely present other challenges, that could mitigate the issues of completely losing the display if there is anything wrong when setting sys-gui-gpu up.
The problem is I don’t like doing it in dom0 at all
If we are optimistic, at some point the full SR-IOV support for Intel iGPUs will land in the mainline kernel and no out-of-tree drivers will be required. That would cover the “installing stuff in dom0” angle.
Whether you can do SR-IOV with a passed-through device is an open question. But I agree that it may be best to wait until sys-gui-gpu is more stable before worrying about that.
No, since this directly interacts with how Qubes manages PCIe devices you need to do this in dom0. Using this would conflict with sys-gui-gpu to my understanding.