Finally got sys-gui-gpu working - very limited functionality

Following GUI domain | Qubes OS I finally got sys-gui-gpu working on r4.2. This is on a single GPU Intel 11th gen NUC.

Additional to what the above doc says I had to blacklist the PCI IDs (GPU, Audio and maybe GNA) to get it working and to manually add the Audio pass-through as it would complain about non-supported FLR.

Now lightdm in sys-gui-gpu starts, but the experience is VERY limited:

  • (usb attached) keyboard mouse didn’t work (had to use qvm-usb to hand them to sys-gui-gpu)
  • all dom0 functionality is absent (seeing other domains, being able to passthrough devices from dom0 to any other domU - i.e. using try icons or Qube Manager)
  • even managing sys-gui-gpu itself breaks in Qube Manager (“refresh applications” results in “Service call error: Request refused”)
  • locales are english_us (instead of system-wide configured locales)
  • application menu is broken - what is supposed to start dom0 applications is actually started in sys-gui-gpu (if present), probably related to QubesOS/qubes-issues#6740, however I don’t see any progress or workarounds there

On the plus side:

  • hardware acceleration seems to work out-of-the box, glxgears gave me ~2500FPS

Is this expected behaviour? Especially the inability to see and interact with other domU makes this completely useless…

So, you experience the same behavior as described here … 10 months ago.
I had my last sys-gui attempt around the same time, and due to the hardware used, with worse results.
The sad truth is that here exists no effort to accommodate systems with only one (embedded) GPU.

Some of the limitations are still there, but managing other qubes, menu, widgets etc should work out of the box. Maybe you forgot sudo qubesctl top.enable qvm.sys-gui-gpu pillar=True before calling sudo qubesctl --all state.highstate?

no I didn’t forget it, still see it my shell history

The missing piece was apparently:
# qubes-prefs default-guivm sys-gui-gpu

Afterwards it was possible to access other domUs

2 Likes

no, there is an issue.

I’m using sys-gui-vnc sometimes which is also a GUI domain, it had rough edges but I can use it. Maybe some RPC rules are missing for sys-gui-gpu :frowning:

However, sys-gui-gpu purpose is only to reduce dom0 attack surface, the name may be confusing, it’s not meant to use the GPU to do anything useful…

1 Like

Hm, my understanding is that sys-gui-gpu has GPU acceleration already enabled (while sys-gui currently doesn’t - see Enable GPU acceleration by default in sys-gui · Issue #8987 · QubesOS/qubes-issues · GitHub). And sys-gui(-gpu) will have to run the Wayland compositor (see Allow one VM to be a Wayland compositor for another · Issue #8998 · QubesOS/qubes-issues · GitHub) to actually have GPU acceleration in any domU (without passthrough to any domU - just to sys-gui-gpu). So I see this as a first step to also make some use of the GPU (sooner and even long-term more secure compared to sys-gui).