Whonix 15: increasing allocated CPU number makes the VM incredibly slow

Weird bug. Happens both in live-boot and persistent modes.

I noticed my Whonix 15 Workstation was incredibly slow: slow boot, very slow reaction times, whatever I would do (simple terminal tasks, browsing, etc.), everything is slow and almost freezing, although I have allocated 4GB of RAM and up to 4 CPUs.

I tested the .qcow2 disk in other VM, and it worked just fine.

I tried reinstalling everything, worked very fast as expected with default settings.

Then I increased the CPU count to 4, and it was again very slow. Decreased to 1 (default), fast again…

What could be the cause of such behavior?

I should add just in case that I am using kernel 5.0.6, so I had to uncomment the parameter

 <blkiotune>
    <weight>250</weight>
</blkiotune>

I see that the default CPU setting is “host-passthrough”. Could it be related (didn’t test with other options)?

Here are some stats to compare:

“fast” boot with default CPU number (1):

user@host:~$ sudo systemd-analyze time
Startup finished in 1.318s (kernel) + 7.430s (userspace) = 8.749s 
graphical.target reached after 3.097s in userspace

“slow” boot with 4 CPU:

user@host:~$ sudo systemd-analyze time
Startup finished in 8.774s (kernel) + 20.572s (userspace) = 29.346s 
graphical.target reached after 20.551s in userspace
1 Like

That’s because I use CPU pinning by default to isolate VM CPUs from eachother to prevent side-channel attacks on crypto if there is a vuln in OpenSSL. So even if you add more cores you are essentially overloading a single real one with this setting until it is removed.

To get rid of this behavior remove the

cpuset='1'

in the vcpu tag.

Added because you are not the first to run into this:

1 Like

The pinning parameter cpuset='1' must be removed in the vcpu tag in the XML settings to allow adding more cores to a VM, otherwise performance issues and lockups will happen.

Ok, that must be removed but what must be done to add other CPUs?

CPU pinning is done to safeguard processes in other VMs that run cryptographic operations from side-channel attacks in case of a vulnerability in a crypto library.

That might imply that adding vCPUs does undermine protection gained from CPU pinning? Can vCPUs (or any real core) be added without undermining protection gained from CPU pinning

Just increment the number between the vcpu tags higher to increase their no.

Yes you would pin the additional ones to different physical cpus than the ones of say Whonix GW. Needs to be done 1:1.

Attempting to overcommit the no. of vcpus when pinned will cause problems like overcommitting RAM does, if their is no ballooning (because security) and if its all allocated at once (this I will change to allocate as is basis soon with Buster).

1 Like

This isn’t really a problem or a bug, but it should be noted that the performance impact this has with multiple CPUs is profound. On my host system with an i9-14900HX CPU:

  • With a single CPU, Kicksecure 18 for KVM boots in about 12.6 seconds.
  • With two CPUs, it takes about 20 seconds.
  • With 32 CPUs (which I was using earlier trying to speed up a Linux kernel build), it takes about 42.5 seconds.

Disabling CPU pinning results in fast bootup (around 12 seconds) even with 32 CPUs.

It’s probably worth adding something to systemcheck that can detect when multiple CPUs are being used with KVM, and warn the user that they should either reduce their CPU count to 1, or disable CPU pinning if they are willing to accept the risks it comes with.

2 Likes