How do I set qemu guest CPU speed?

[szatox]

Long story short I'm trying to run an untrusted, resource-hungry application in a VM and it kinda looks single-threaded to me.
So, is there any way to instruct qemu not to limit passed-through CPU's speed? My qemu guest only sees 1,8GHz, while the host tends to reliably put out 2,4GHz on every core (out of 3,9GHz advertised).
I control my VMs with virt-manager; the host is Intel Core i5, in case it makes any difference.

[eccerr0r]

Odd, my qemu/virt-manager guests passes bogomips and cpu MHz in /proc/cpuinfo pretty much straight through. Your vm shouldn't be changing these things if kvm is working... also kvm is working pretty close to native/baremetal speeds as well and will slow down only if the host machine is bogged down... (at least this seems to be the case for my C2Q and i5/i7/Xeons with and without HT.) Note all my machines have vmx but I'd suspect your machine has vmx if it's 3.9GHz and iX series...

Sure KVM is working properly?

Another observation is that when you run two processes in parallel in qemu it seems to run the processes as two threads on the host which gets parallelized by the host kernel... not sure what you're seeing?

Incidentally I don't know if it's possible to "slow down" guests when using KVM (other than limiting number of cores and setting nice to the qemu process). So if there are timing related software problems they are hard to emulate a slower machine other than perhaps using full emulation...

[szatox]

> Sure KVM is working properly?

It certainly is slower than native, but it doesn't feel 'kvm not working'-slow... Well, I'll double check it to be on the safe side. It would actually be hilarious too.


> Another observation is that when you run two processes in parallel in qemu it seems to run the processes as two threads on the host which gets parallelized by the host kernel... not sure what you're seeing?

I see a VM with 2-3 cores and load avg around 1, when application inside can't keep up with crunching through the data stream thrown at it.
So I think it just doesn't scale out, even though it is "technically" multithreaded.
Other applications can use multiple cores at the same time. However, now that you mentioned it, I've seen some emerge jobs take much longer than they should, with load average also equal to 1. I shrugged it at the time, but maybe it is actually worth a second glance.

[Anon-E-moose]

You might try pinning cores/threads to your vm instance,
it might help, especially if this is one of the processors with e-cores,
but even if just regular cores, it might make a difference.

I know libvirt should have an option for tagging cores but not sure what it's called,
with cmd line qemu, I would use taskset "taskset -c 4,5,6,7,12,13,14,15"
and set smp to some sane value "-smp 8,cores=4,threads=2"

Edit to add: https://wiki.archlinux.org/title/PCI_pa ... nce_tuning

[szatox]

KVM is enabled and in use.

lscpu from guest:

Code: Select all

# lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          39 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   2
  On-line CPU(s) list:    0,1
Vendor ID:                GenuineIntel
  BIOS Vendor ID:         QEMU
  Model name:             Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
    BIOS Model name:      pc-q35-9.2  CPU @ 2.0GHz
    BIOS CPU family:      1
    CPU family:           6
    Model:                142
    Thread(s) per core:   1
    Core(s) per socket:   1
    Socket(s):            2
    Stepping:             12
    BogoMIPS:             3600,00
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm co
                          nstant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic
                           movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibr
                          s_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflusho
                          pt xsaveopt xsavec xgetbv1 xsaves arat vnmi umip md_clear flush_l1d arch_capabilities
Virtualization features:  
  Virtualization:         VT-x
  Hypervisor vendor:      KVM
  Virtualization type:    full
Caches (sum of all):      
  L1d:                    64 KiB (2 instances)
  L1i:                    64 KiB (2 instances)
  L2:                     8 MiB (2 instances)
  L3:                     32 MiB (2 instances)
NUMA:                     
  NUMA node(s):           1
  NUMA node0 CPU(s):      0,1

# grep MHz /proc/cpuinfo 
cpu MHz		: 1800.000
cpu MHz		: 1800.000

From host:

Code: Select all

Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Address sizes:                        39 bits physical, 48 bits virtual
Byte Order:                           Little Endian
CPU(s):                               4
On-line CPU(s) list:                  0-3
Vendor ID:                            GenuineIntel
Model name:                           Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
CPU family:                           6
Model:                                142
Thread(s) per core:                   1
Core(s) per socket:                   4
Socket(s):                            1
Stepping:                             12
CPU(s) scaling MHz:                   98%
CPU max MHz:                          3900.0000
CPU min MHz:                          400.0000
BogoMIPS:                             3601.00
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust sgx bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities
Virtualization:                       VT-x
L1d cache:                            128 KiB (4 instances)
L1i cache:                            128 KiB (4 instances)
L2 cache:                             1 MiB (4 instances)
L3 cache:                             6 MiB (1 instance)
NUMA node(s):                         1
NUMA node0 CPU(s):                    0-3

# grep MHz /proc/cpuinfo 
cpu MHz		: 400.000
cpu MHz		: 3769.270
cpu MHz		: 3841.356
cpu MHz		: 3794.204

Bogomips is the same, but guest doesn't have speed controls, and the speed presented to it doesn't even match cpu name.
HT is disabled right now, looking at that wiki page I wonder if it would actually make things better in this case. Gotta give it a shot.

[Anon-E-moose]

what parameters are you using for "cpu" libvirt-wise

Edit to add: "host" or a particular model type?

[eccerr0r]

hmm maybe something i don't have enabled right, I've always thought my qemu client exposed too much information about the host.

Code: Select all

client$ lscpu
Architecture:            i686
  CPU op-mode(s):        32-bit
  Address sizes:         36 bits physical, 0 bits virtual
  Byte Order:            Little Endian
CPU(s):                  4
  On-line CPU(s) list:   0-3
Vendor ID:               GenuineIntel
  Model name:            Intel Celeron_4x0 (Conroe/Merom Class Core 2)
    CPU family:          6
    Model:               2
    Thread(s) per core:  4
    Core(s) per socket:  1
    Socket(s):           1
    Stepping:            3
    BogoMIPS:            5668.08
    Flags:               fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov p
                         se36 clflush mmx fxsr sse sse2 ht syscall nx eagerfpu p
                         ni ssse3 hypervisor lahf_lm
Virtualization features: 
  Hypervisor vendor:     KVM
  Virtualization type:   full
client# qlop -mvt glibc
2025-01-26T13:07:36 >>> sys-libs/glibc-2.40-r8: 21�28�

host# qlop -mvt glibc
2025-03-10T17:58:00 >>> sys-libs/glibc-2.40-r8: 53′10″

hmm..something not right here... but anyway... actually looking at the merge logs it seems my VM is about half the speed of the host when doing emerges and not the other way around. That merge was probably a fluke. However half is pretty bad, maybe I have some optimization to do too... Anyone else have emerge data on VMs compared to host?

Granted this specific qemu host does not have turboboost, the client bogomips matches the host. (my host is a Yorkfield.) I'd really like to lie about bogomips...

As for HT, as a general observation, it tends to increase throughput about 20% or so, meaning you get almost another processor for every four real cores (provided you have enough RAM). You probably disabled it due to the spectre bugs, alas my cpus are so slow that I want my 20%...

Another thing I noticed with one of my "ill" computers (laptop), it seems to not stay in turboboost often for whatever reason despite it saying it can turboboost. A difference between "can" versus "does"...

[szatox]

> what parameters are you using for "cpu" libvirt-wise

I'm using host cpu (pass-through mode).

> As for HT, (...)

I actually disabled it because there's not enough cooling to run full throttle anyway. Like you said, "it could" doesn't mean "it would".
Welll, it does look a bit better today, with HT enabled and cpu changed to host-model. Still, it's not good enough.

Anyway, I'll try to convert it to an LXC. Maybe qemu just isn't the right tool for the job...

[Anon-E-moose]

A container or chroot is sometimes a better choice, all depending on what you're trying to do.

[blu3bird]

My qemu guest only sees 1,8GHz, while the host tends to reliably put out 2,4GHz on every core (out of 3,9GHz advertised).

QEMU does not report the current CPU frequency to the guest instead it reports a fixed frequency. Why? Because it's not implemented.

This is mostly a cosmetic issue. Your guest will get the full performance (clocks) of the CPU and will not be limited to the advertised speed.

If you really want your VM to see the real CPU frequency you can patch QEMU to support CPPC. This may improve performance as it helps improve scheduling decisions but for your use-case that's neglectable.

[szatox]

Yes, it is just a visual bug. Thanks for pointing that out.
I've run some number crunching in the VM and on the host, and the difference it raw power is like 5%... And yet the application performance difference (vm vs host) is huge. But it must be caused by something else. _Could_ have something to do with usb rediretion via spice (input lag), but I find load average = 1 to be suspicious. It being almost exactly 1 when a multi-threaded application is not getting enough CPU power on a multicore system is just weird.

I eventually ended up restricting the app with a different user and firewall (access to my files was already somewhat restricted compared to defaults). Well, I guess that's about as good as it gets for now.
Oh well. I'll leave it for now.

[eccerr0r]

system calls including I/O have always been an Achilles heel to virtualization, it's bad enough as it is on baremetal, worse on virtual, perhaps that's why my VM emerges so slow compared to host, granted it's not an apples to apples comparison (32 vs 64 bit).

Still strange why my machine copies bogomips and MHz straight to the VM as far as I can see (I suppose it doesn't matter on my Core2Quad which does not have turboboost, but still see the same behavior on my turboboost capable machines too.)