Project status [Info]

[Unb0rn]

Hey! Just wanted to ask you if there are any plans on updating it? After the 4.1 release I think we'll probably need some patches.
While it looks like the packages are mostly compatible (Xen 4.14, libvirt 6.6.0), the kernel is 5.10 now (with Fedora 32 in dom0) is it okay to patch it with 5.4 XenGT patches? Thanks!

[jevank]

Hi, this repository looks a bit abandoned because we switched to building our projects with qubes-builder and are trying to offer them to upstream as much as possible.

The latest patches for Qubes OS components to support GVT-g can be found in these pull requests:

• TBD: Add partially Intel GVT-g support (xengt device) QubesOS/qubes-vmm-xen#125
• Add GVT-g support (xengt device) QubesOS/qubes-core-libvirt#38
• Add Intel GVT-g support (xengt device) QubesOS/qubes-vmm-xen-stubdom-linux#43
• dummyqbs: Add glamor acceleration QubesOS/qubes-gui-agent-linux#150

The kernel can be built from this repository. The version is still 5.4, but it is quite compatible with R4.1.
https://github.com/tabit-pro/qubes-linux-kernel-gvt

For building and installing QWT, check out qubes-windows-tools-cross and some of the threads on the Qubes OS forum.

[Unb0rn]

Thank you! It would be great to see this merged)

[jevank]

Let's keep it open for a while

[Unb0rn]

Its a bit sad to see this is being upstreamed so slowly, still hope eventually it will be merged.
In the meantime I wanted to build it myself but got stuck with some problems building gui-agent-linux and Linux kernel, so I wanted to ask two more questions:

• Are there any patches for 5.15 kernel (Qubes 4.1.1) I'm not sure if those will do.
• Is there any CI system that builds unofficial rpms with those patches? Maybe someone made one and it's possible to download pre-build packages instead of building them? It would be much easier until everything is merged...
  Thanks!

[tlaurion]

@jevank what threads on qubes forum?
I'm also holding my breath until packages land at least under qubes contrib repo, and not sure I understand what is stopping packages to be built and published since qubes published article on your progress and then radio silence.

What is stopping contributed packages to be built from Qubes project?

@marmarek? @fepitre?

[jevank]

Hi and thanks for your support. The current challenge is to get the safeboot functionality including LUKS seal/unseal up and running. This works quite well on our hardware. Perhaps by that time something will have progressed with GVT-g patches..

Are there any patches for 5.15 kernel (Qubes 4.1.1) I'm not sure if those will do.

Unfortunately, only 5.4 kernel is working at now. We have couple tries to bump it to 5.10, but it requires more time.

Is there any CI system that builds unofficial rpms with those patches? Maybe someone made one and it's possible to download pre-build packages instead of building them? It would be much easier until everything is merged...

Our CI system builds from private git repositories, so I assume it's incorrect to publish them. But perhaps a Qubes-compatible public binary repository is the way to deliver such changes.. We should think about that.

what threads on qubes forum?

Unfortunately, experience with qwt-cross has shown that most users find it hard to build components from source and without GUI/console integration it is hard to promote use. But it is the usefulness of qwt-cross project that motivates to follow through :)

[Unb0rn]

Just a quick update.
I've finally managed to build all the components. No problems in patches or Qubes builder, only my misunderstanding.
Several notes:
First, xengt module seems to load fine in dom0, although there are some errors about direct firmware load. It may be related to rather old kernel 5.4 with more or less new hardware (Librem 14, 10710U, CNL)
Second, it looks like Qubes 4.1.1 still works with kernel 5.4, so I hope we may test everything...
Third, Fedora 36 VM seems to boot fine and even load i915, drm and drm_kms_helper kernel modules but no /dev/dri catalogue gets created so I think adding xf86 drivers has no meaning. It may be related to nomodeset default kernel parameter which I have no idea how to remove in Qubes, it is not passed in qvm-prefs or in grub.conf inside the vm, but still passed somehow and I can see it in /proc/cmdline
Fourth and the final one, maybe I should try contacting Purism and ask them if they're interested in maintaining XenGT-capable kernel? After all, Librem 14 seems to be the only relatively modern laptop with coreboot (and heads) mainline support, which has the last SoC that supports graphics virtualization (neither ICL nor TGL support GVT-g and their SR-IOV is not in i915 driver at least for now). Qubes with HW-accelerated graphics on modern hardware sounds like a killer feature for me...

P.S. Guys from tabit-pro, YOU ROCK! =) Seriously, thank you!

[jevank]

Second, it looks like Qubes 4.1.1 still works with kernel 5.4, so I hope we may test everything...

We use it daily on Thinkpad X1 C5-C8 laptops. You may have a problem with digital microphone if you have one, which requires newer SOF firmware (package alsa-sof-firmware). Otherwise, everything is flawless.

Third, Fedora 36 VM seems to boot fine and even load i915, drm and drm_kms_helper kernel modules but no /dev/dri catalogue gets created so I think adding xf86 drivers has no meaning. It may be related to nomodeset default kernel parameter which I have no idea how to remove in Qubes, it is not passed in qvm-prefs or in grub.conf inside the vm, but still passed somehow and I can see it in /proc/cmdline

Take a look to wiki page. It looks bit deprecated, but dom0 and necessary VM configuration (kernel cmdline and video-model option) looks OK.

Fourth and the final one, maybe I should try contacting Purism and ask them if they're interested in maintaining XenGT-capable kernel? After all, Librem 14 seems to be the only relatively modern laptop with coreboot (and heads) mainline support, which has the last SoC that supports graphics virtualization (neither ICL nor TGL support GVT-g and their SR-IOV is not in i915 driver at least for now). Qubes with HW-accelerated graphics on modern hardware sounds like a killer feature for me...

That would be cool, but as far as I know they have their own preinstalled Linux-based OS.

[Unb0rn]

Take a look to wiki page. It looks bit deprecated, but dom0 and necessary VM configuration (kernel cmdline and video-model option) looks OK.

Yeah, my bad, passed gvt_enable instead of modeset to i915 driver. Should take a break =)
Now /dev/dri is there, but glxinfo still returns llvmpipe... (of course I've built both xorg-dummy-egl and xorg-modesetting-qbs with mock and replaced /etc/X11/xorg-qubes.conf.template with xorg-modesetting-qbs.conf.template) and journal reports some weird warnings with additional error in dom0 journal like:
gvt: vgpu(2) Invalid FORCE_NONPRIV write 10002349 at offset 24e0
Maybe because there is no vbios in my coreboot image? only libgfxinint and vbt tables...

That would be cool, but as far as I know they have their own preinstalled Linux-based OS.

It looks like they're trying to endorse Qubes project, but I'm not sure if they really want to contribute...

Added the journal of i915 init with warnings (kernel 5.15 in fedora 36 vm) just in case
journal.log

[jevank]

of course I've built both xorg-dummy-egl and xorg-modesetting-qbs

It's better to use dummy-egl driver, not sure that modesetting-qbs is fine now...
Guest xorg logs could be found here /home/user/.local/share/xorg

gvt: vgpu(2) Invalid FORCE_NONPRIV write 10002349 at offset 24e0

As I understand this is harmless

Added the journal of i915 init with warnings (kernel 5.15 in fedora 36 vm) just in case

Using 5.4 guest kernel is stable, but with upstream 5.15 in could be fine. Log warnings about GuC firmware and vbios missing should be harmless too.

[Unb0rn]

It's better to use dummy-egl driver, not sure that modesetting-qbs is fine now...
Guest xorg logs could be found here /home/user/.local/share/xorg

Yep, you were right, it were just xorg drivers. It works now on my Purism Librem 14/Qubes 4.1.1/coreboot 4.17+heads (if someone searches for this info) QubesOS/qubes-issues#4979
To summarize:

• Qubes builder
• Upstream sources with your patches mentioned in PRs above (I still haven't figured about gui-agent-linux, everything seems to work without it, while qubes-builder builds the version for fc35, not fc36)
• 5.4 Kernel from tabit-pro/qubes-linux-kernel-gvt
• xorg-dummy-egl from this repo
  Let's hope the maintainers will merge everything or at least add some contrib packages and that Purism will get interested =)
  Thanks!

[theonlyfoxy]

Hi. Is there any update for this? Will Qubes 4.1.2 be supported?
Also does it support Windows guest VM? It seems so.

Ref:
-https://raw.githubusercontent.com/01org/XenGT-Preview-kernel/master/XenGT_Setup_Guide.pdf

[jevank]

Hi. Is there any update for this? Will Qubes 4.1.2 be supported?

It still requires building the kernel from sources, but that is now the only requirement.

Also does it support Windows guest VM? It seems so.

Unfortunately no, it requires guest support Intel GVT-g device and Qubes video virtualization stack.

[theonlyfoxy]

Also does it support Windows guest VM? It seems so.
Unfortunately no, it requires guest support Intel GVT-g device and Qubes video virtualization stack.

What is reason behind this? Doesn't XenGT already support Windows based on what stated in docs?

[theonlyfoxy]

Would you guys update the kernel to upstream 6.x ?