The Virtbook Concept

[computeforpeople]

I think the Level 1 forums are one of the finest places to discuss these topics
and get feedback, where there is a lot of concentrated interest here in
virtualization as a tool for empowering people. This first post may seem
somewhat abstract but I think it is good to lay out some high level ideas that
we can discuss before getting into the details of concrete implementations.

OK, what is this about?

A hardware and software design concept that represents a leap forward in
professional mobile computing, in a nutshell: secure, easy and performant GPU
enabled virtualization on a mobile platform.

Why?

It is simple:

1. We need a Free Software base operating system that respects our rights.
   Current proprietary operating systems are just not compatible with privacy,
   security and freedom. Lately they are not even stable or well designed, and
   are now focused on shoveling as many subscription based products of dubious
   utility and quality in the users face as possible. Professionals are losing
   patience fighting against this deluge of mediocrity, not to mention time and
   money.

   And frankly these proprietary operating systems have proven time and again
   that they cannot be trusted with the bare metal and unrestricted access to
   the Internet. We can be sure data will be lost and/or exfiltrated.

2. While there is now more high quality Free Software available for all needs
   than ever before, many professionals still require compatibility with some
   number of proprietary programs.

   Example 1: As long as you need to view and edit office documents from people
   who use that proprietary office suite, you will likely need to run a copy
   of that proprietary office suite. Free Software office suites have long
   struggled to achieve compatibility with the obtuse file formats used by
   that proprietary office suite, based on fake standards which the same
   proprietary office suite does not even abide by.

   The efforts made in the last 20 years to reverse engineer and reimplement
   the actual non compliant and ever changing behavior of that proprietary
   office suite so that documents look the same and do not get mangled on save
   have been enormous, yet the Free Software office suites are perpetually
   missing that “last 5%” of compatibility.

   Example 2: In many industries, there are deeply entrenched incumbent
   software providers whose proprietary product represents a de facto standard.
   Generally the interoperability with Free Software programs is low to
   nonexistent due to a variety technical and nontechnical factors. Many of
   these programs are tied to a single proprietary operating system. In these
   cases, there is just no practical way to avoid these proprietary products
   and the proprietary operating system they are tied to for people working in
   certain industries.

3. Historically virtualization of these proprietary programs on mobile
   platforms has been… sometimes ok. Many times bad or just impossible.
   Almost never performant or pleasant to use due to higher latency. Why is
   that? Well… GPUs. Most professional design and engineering software, even
   office suites and web browsers, depends on GPUs for rendering and
   acceleration of various tasks such as media encode and decode.

   When software rendering works at all, it is almost always slow. The other
   half of the equation is getting those rendered frames from the virtual
   machine onto the physical display. The historical solutions have suffered
   from poor throughput and latency.

So as a solution what we need is an adequate virtualization based system that
respects our rights to the highest degree possible with Free Software but also
lets us run these proprietary programs in a safe and performant way, one that
we can carry with us too: the virtbook.

A virtbook is:

1. Laptop capable of running simultaneously at least 4 GPU accelerated virtual
   machines
2. Framerates of 60 FPS or better for lighter applications such as a web
   browser or office program when displayed at 1920x1200 on a virtual desktop
3. Input latency of 100 ms or less on virtual desktops
4. Support for GPU sharing with Linux and Windows virtual machines
5. Support for open standard graphics APIs such as Vulkan and OpenGL, as well
   as proprietary graphics APIs, inside VMs
6. Hardware encode/decode for modern media codecs (AV1, VP9, h264) inside VMs
7. Free Software host OS and open driver stack
8. Security boundaries enforced by hardware for GPU sharing
9. Battery runtime of at least 5 hours for light GPU loads in a VM
10. Integrated graphical tools to manage virtual machines and their resources
11. Secure, performant and seamless file sharing between host and VMs
12. Tools to isolate or restrict network access to VMs

So how would you achieve this in 2025?

I am sure a lot of you already know where I am going with this… more in the
next few days.

Postscript:

I think the real solution to achieving widespread software freedom has to be a
political one. As Free Software advocates and engineers, we have got to cut out
the “we just need to try harder” attitude on the technical front and accept
that we cannot win through technical achievements alone.

The game is rigged, the decision makers and the corporate and government
purchasing officers get massive kickbacks to go along with schemes to prop up
bad proprietary software. Geopolitics also comes in to play as the big players
pressure the smaller ones to use their national proprietary software or else.
Any discussion of significant public funding for Free Software is quashed by
powerful special interests. The flood of constant corporate propaganda has
created so many blind followers. Etc.

So let us accept this reality while we continue to advance not only on
technical fronts but also on social and political fronts, and help people see a
clear path forward to empower themselves with computing and safeguard their
rights as much as possible. And to have a good attitude while doing it.

And if it means people use a few pieces of nonfree software in a less harmful
manner for a while longer, so be it, as long as it is within the frame of a
coherent strategy where we prioritise software freedom. You and I may strictly
reject all nonfree software, and accept the consequences of that decision, but
we cannot reasonably expect others to do so in all situations.

copyright computeforpeople 2025

I give permission for this content to be incorporated in a machine
learning corpus or used to train machine learning models only when the full
corpus is made available publicly under an open content license and all code
used to generate said models is made available publicly under a license
compliant with the Free Software Definition.

[computeforpeople]

To cut to the chase, there are two key components that can be used to assemble
a virtbook in 2025:

• SRIOV, a mechanism which lets us share GPUs efficiently and securely with
  VMs.
• Looking Glass, a high performance and low latency headless virtual
  monitor, keyboard and mouse. Similar in purpose to SPICE, although worlds
  faster.

So this particular implementation of a virtbook is basically a marriage between
SRIOV and Looking Glass.

These two things currently do not play well together out of the box, but there
are some tricks with advanced libvirt/QEMU options and indirect display drivers
that we can use to assure a functional cooperation.

You might be thinking, why not just use standard PCIe passthrough with a second
GPU? Because GPU passthrough only supports a single virtual machine at a time,
it’s not an option to build a virtbook.

Also dGPUs on laptops are generally bad because they are most often:

a) expensive
b) power hungry (we sacrifice battery runtime)
c) hot (we need more powerful, bulkier cooling)
d) frequently don’t let you use iGPU and dGPU at the same time
e) require closed source driver stacks

So in general a laptop with an dGPU might work in some cases for a single
virtual machine, but would entail other significant sacrifices.

As far as I am aware, there are no laptop dGPUs which support SRIOV currently.

Let’s get on to how to assemble a virtbook.

What kind of hardware can we use as a base for a virtbook?

There are now coming on to the second hand market a lot of business laptops
with Alder Lake (Intel 12th gen) mobile platform from 2022: i5-1230U, i5-1240p,
up to i7-1280p, with so-called “Iris Xe” graphics.

https://www.intel.com/content/www/us/en/ark/products/codename/147470/products-formerly-alder-lake.html#@Mobile

These have between 2 and 6 P-cores and 8 E-cores, and have 80 or 96 GPU
execution units, which translates to 5 or 6 Xe cores. NVMe storage with PCIe
4x4. Processor base power between 15W and 28W. They will all work just fine
with the virtbook configuration that I will describe.

Many were sold with DDR4-3200, although the processors do support up to
DDR5-4800 SODIMM and there are a few laptop models which support that.

A critical factor here is memory bandwidth, so if there is are SODIMM slots,
make sure all are populated to take advantage of 2 memory channels. Many of
these models were shipped with 8 GB soldered RAM, but some have 16 GB soldered,
alongside a single SODIMM slot. A model which supports DDR5 should have an
advantage here.

Many of these systems can accept a 32GB SODIMM, which is great for allowing
more concurrent virtual machines, however memory bandwidth with 8+32 will be on
average lower than 8+8 because 24 of that 32 GB SODIMM will operate in single
channel mode. Now 16+16 will enable a full 32 GB in dual channel mode.

The GPU is pretty much the same on all Alder Lake mobile from i5-1230U on up
with very minor variance in execution units and frequency, so it’s not an
important factor when looking at different hardware configurations.

That’s it for now, next time we will look at the host operating system
configuration.

[dumetrulo]

Why do you manually break your lines? Very jarring when reading your posts on a mobile phone.

[IgorDe]

I suppose what we’d really need is a way to use vGPU on most graphic hardware and possibly ways to expose individual application frontend via vGPU and e.g. Looking Glass to a host.

Also I had to check twice if you’re not Louis Rossmann (though I think chances of him drilling down that deep on the software side are probably not as high, because he seems like a hardware professional) or that SalemTechspert guy .

You’re definitely not wrong, though I’d argue, that while the mission is great, there’d be a lot of overhead if you e.g. ran 4 VMs simultaneously just for 4 applications.
Maybe something like e.g. RDP with a terminal server where an individual window can be exposed rather than the whole desktop, but it probably wouldn’t be anywhere as fast as a proper PCIe passthrough.

[computeforpeople]

@IgorDe

I suppose what we’d really need is a way to use vGPU on most graphic hardware and possibly ways to expose individual application frontend via vGPU and e.g. Looking Glass to a host.

What we really really need is for hardware manufacturers to enable SRIOV in their consumer GPUs. SRIOV is an open standard that all three major GPU makers support.

AMD uses the marketing name “MxGPU” for SRIOV.

NVIDIA also supports SRIOV.

@IgorDe

there’d be a lot of overhead if you e.g. ran 4 VMs simultaneously just for 4 applications.

Probably not as much overhead as you’d expect. I have no problems running more than 10 single application VMs simultaneously on mobile hardware more than a decade old. If you want strong security and isolation, you need VMs with hardware supported virtualization, containers are not going to cut it. Without hardware supported virtualization, you could have container or virtual machine escapes and problems with a single GPU thread crashing your whole system.

Solutions like virtio-gpu which do not strictly require virtualization support from the GPU hardware are interesting, but at present don’t get my vote of confidence from a security and stability perspective.

virtio-gpu docs

@IgorDe

RDP with a terminal server where an individual window can be exposed rather than the whole desktop

This is certainly possible with a Linux guest using X11. I was not aware that Terminal Server allows RDP connections to a single application, thanks for that.

@dumetrulo

Why do you manually break your lines? Very jarring when reading your posts on a mobile phone.

Sorry about that, it’s due to copy-pasting from a text editor because generally I draft my posts offline. I will fix it.

[computeforpeople]

Now let’s take a look at the software configuration on the host.

These are my choices but you can set up your system how you like and you can call it a virtbook when it meets the general requirements laid out in the spec.

Software

• Base OS: Fedora 42 XFCE. You can use other Linux distros with at least kernel 6.8.
• Windowing system: Xorg. XFCE currently is exclusive to Xorg. XFCE and Xorg are chosen for maximum stability, also I have more experience tinkering and fixing Xorg than I do with Wayland. However a Wayland setup with Fedora 42 KDE could also be interesting.
• Virtualization: KVM, QEMU, libvirt administered through virt-manager GUI
• GPU virtualization: i915-sriov-dkms kernel module
• Video acceleration: VAAPI, libva-intel-media-driver
• Virtual desktop viewing: Looking Glass with IDD for Windows guests, xrdp (with VAAPI) for Linux guests, Remmina as RDP client, which uses the FreeRDP library.

Basic host configuration

Summary:

• Install Fedora 42 XFCE on the laptop.
• Install and enable libvirtd, add your user to group libvirt.
• Install virt-manager.
• Install C development packages, git, kernel headers, DKMS.
• Install Remmina with RDP plugin.
• Install igt-gpu-tools (for intel_gpu_top).
• Install python3-policycoreutils.
• Confirm IOMMU is enabled: dmesg | grep IOMMU. Otherwise enable it in the UEFI firmware.
• Disable secure boot in the UEFI firmware.

Regarding secure boot: Unless you sign your own bootloader, remove the preloaded Microsoft keys from UEFI and load your own, secure boot is a net negative. Otherwise it creates a false sense of security. There are plenty of bootkits that boot just fine with secure boot, they use a Microsoft-signed UEFI shim, so you need to clear out the Microsoft keys if you want meaningful protection. Secure boot is not a security mechanism unless you own the keys. Most people should disable secure boot as they probably aren’t in a position to sign their bootloader with their own keys.

SRIOV configuration on the host

Enable the module with DKMS

Take a look at the README for i915 SRIOV module:

i915 SRIOV DKMS git repository

We will follow the Manual Installation Steps, adapted for Fedora.

As root:

git clone https://github.com/strongtz/i915-sriov-dkms.git
dkms add ./i915-sriov-dkms
dkms install i915-sriov-dkms/2025.07.22

Set kernel command line options

Edit /etc/default/grub, add the following to GRUB_CMDLINE_LINUX:

intel_iommu=on i915.enable_guc=3 i915.max_vfs=7 module_blacklist=xe

Note: max_vfs sets the maximum number of virtual functions (“VFs”, which can be thought of as virtual GPUs) that can be created. The number of VFs which are actually created can be set at any point using a sysfs variable, but cannot be changed again until reboot.

Note 2: “xe” is the new Intel GPU driver for Linux, but there is no support for SRIOV on Alder Lake iGPUs from this driver yet yet, so we need to prevent it from loading.

Regenerate grub and initramfs (the easy way):

dnf download kernel-core
dnf reinstall ./kernel-core*.rpm -y

This will run all the kernel update hooks, such as for grub, initramfs, dkms, etc. Now when you later need to regenerate these, you can just run the second command, and because we downloaded the kernel-core RPM, we can do this offline. If your kernel updates and you need to once again manually regenerate grub, initramfs etc, you will want to redownload the RPM of the latest kernel-core package and remove the old one. Or do a one-off dnf reinstall kernel-core.

Configure virtual functions with sysfs variable

Reboot the system. Review lspci | grep VGA: there should still only be one VGA device at this point. As mentioned before, we can enable between 1 and 7 VFs with a sysfs variable. We’ll use systemd-tmpfiles to write to the appropriate file in sysfs.

Create a file /etc/tmpfiles.d/10-sriov.conf with the following:

w /sys/devices/pci0000:00/0000:00:02.0/sriov_numvfs - - - - 7

This indicates to systemd-tmpfiles that it should write the character “7” to the file /sys/devices/pci0000:00/0000:00:02.0/sriov_numvfs during boot. “7” is the number of VFs we wish to create. Note that there is always one “VF” assigned to the host, so using a value of “7” here will actually leave us with a total of 8 VFs, one for the host and 7 which we can assign to virtual machines.

Test that the tmpfiles configuration works:

systemd-tmpfiles --create --prefix /sys/

Now lspci | grep VGA should show another 7 VGA devices for the new VFs.

When you reboot, systemd-tmpfiles will automatically write the file.

How many VFs do we need?

So how many VFs should you create? Do you really need 7?

Well, if there were some kind of penalty for creating additional VFs, you might assume you should create the minimum number you would need to use concurrently. You might naively think that there would be a penalty due to slicing the dedicated VRAM into fixed sizes based on the number of VFs, but that appears not to be the case with these Alder Lake Xe iGPUs. Instead, the driver will take what memory it needs from the assigned system memory, up to a certain limit.

For example, independently of whether we create a single VF or 7, the Intel Graphics Software utility will report “128 MB VRAM | 4 GB shared” with a Windows VM assigned 8GB of system memory, and “128 GB | 8 GB shared” with 16 GB.

With an 8 GB Linux VM, memtest_vulkan reports:

6GB Intel(R) Iris(R) Xe Graphics (ADL GT2)

and with a 16 GB Linux VM:

12GB Intel(R) Iris(R) Xe Graphics (ADL GT2)

memtest_vulkan git reposiroty

In other words, a VF in a Windows VM may use up to half of the assigned system memory for the GPU, and a VF in a Linux VM may use up to three quarters of the assigned system memory. There appears to be no such thing as “dedicated video memory” as such, and I believe the UEFI firmware option only exists for legacy systems without proper graphics drivers. Furthermore, based on my observations, each VM with a VF will be able to use all of the physical Xe cores.

So based on this, there appears to be no penalty on Alder Lake Xe iGPUs for creating the maximum number of VFs of 7.

At this point we now have some virtual functions available which represent our SRIOV hardware virtualized GPUs and we can start setting up guest VMs with these VFs.

That’s all for now.