clocksource on SeaBios vs UEFI

[planetf1]

I have a Intel N100 16GB PC (4 cpu) running some fedora 40 guests. Both use host cpu type

One proxmox guest (UEFI) is reporting some clock instability trying to use tsc & throws a few events in dmesg, ending up with hpet . kvm-clock isn't available
Another guest (Seabios) has no such issues, and happily uses kvm-clock

I think the difference in behaviour is down to bios type.
Reviewing dmesg output I see that the seabios version knows it's working in kvm ('Hypervisor detected') and so tries to use the kvm clock. The uefi version doesn't report anything like this

 

[gfngfn256]

What does cat /sys/devices/system/clocksource/clocksource0/current_clocksource show (on host).

 

[planetf1]

tsc

All looks fine on the host - no oddities, simple use of tsc

I had thought tsc would be ok in the vm too. Yet I have one on kvm, the other hpet

The factor seems to be the bios. I'm wondering about moving that vm back to seabios (that presumably means a re-install )

 

[planetf1]

I created a new fc40 vm with UEFI - it used the kvm clocksource. So that's consistent with my 'good' vm.

So the other big difference is that the 'bad' vm has pci passthrough of the igpu, bluebooth, audio .....

 

[planetf1]

I notice that `system-detect-virt` returns 'qemu` on the UEFI bios, but `kvm` on the seabios

 

[planetf1]

If it's not bios, I'm wondering if it relates to the use of passthrough in some way

 

[planetf1]

Digging further, there's a difference in whether the hypervisor is detected (hypervisor.c in the kernel). Why, when both are set to 'host', I'm not sure.

 

[planetf1]

So looking into the cpuid more:

On the desktop with gpu passthrough:
jonesn@nigel-desktop:/etc$ cpuid | grep -y hyper
hyper-threading / multi-core supported = true
hypervisor guest status = true
hypervisor_id (0x40000000) = "\0\0\0\0\0\0\0\0\0\0\0\0"
hyper-threading / multi-core supported = true
hypervisor guest status = true
hypervisor_id (0x40000000) = "\0\0\0\0\0\0\0\0\0\0\0\0"
hyper-threading / multi-core supported = true
hypervisor guest status = true
hypervisor_id (0x40000000) = "\0\0\0\0\0\0\0\0\0\0\0\0"
hyper-threading / multi-core supported = true
hypervisor guest status = true
hypervisor_id (0x40000000) = "\0\0\0\0\0\0\0\0\0\0\0\0"


whilst on the other vm, with a working kvm clock:

root@fed40:~# cpuid | grep -y hyper
hyper-threading / multi-core supported = true
hypervisor guest status = true
hypervisor_id (0x40000000) = "KVMKVMKVM\0\0\0"
hypervisor features (0x40000001/eax):
map gpa range hypercall supported = false
hypervisor features (0x40000001/edx):
hypervisor_id (0x40000100) = "\0\0\0\0\0\0\0\0\0\0\0\0"
hyper-threading / multi-core supported = true
hypervisor guest status = true
hypervisor_id (0x40000000) = "KVMKVMKVM\0\0\0"
hypervisor features (0x40000001/eax):
map gpa range hypercall supported = false
hypervisor features (0x40000001/edx):
hypervisor_id (0x40000100) = "\0\0\0\0\0\0\0\0\0\0\0\0"
hyper-threading / multi-core supported = true
hypervisor guest status = true
hypervisor_id (0x40000000) = "KVMKVMKVM\0\0\0"
hypervisor features (0x40000001/eax):
map gpa range hypercall supported = false
hypervisor features (0x40000001/edx):
hypervisor_id (0x40000100) = "\0\0\0\0\0\0\0\0\0\0\0\0"
hyper-threading / multi-core supported = true
hypervisor guest status = true
hypervisor_id (0x40000000) = "KVMKVMKVM\0\0\0"
hypervisor features (0x40000001/eax):
map gpa range hypercall supported = false
hypervisor features (0x40000001/edx):
hypervisor_id (0x40000100) = "\0\0\0\0\0\0\0\0\0\0\0\0"


I've checked the vm settings very closely - they are very similar, certainly for cpu, machine type etc.
The kernel cmdline is too
Running on same proxmox server

 

[planetf1]

proxmox is specifically passing 'kvm=off' to qemu.

I think this is driven by https://github.com/proxmox/qemu-ser...8d45845703d7a0519f/PVE/QemuServer/PCI.pm#L612

This may then cause the clock source difference.

Is kvm-off required when doing passthrough? I don't know....

 

[gfngfn256]

proxmox is specifically passing 'kvm=off' to qemu.

I'm enjoying your investigation process! Keep hunting!

Maybe look here - it provides some useful insight.

 

[planetf1]

After reading through proxmox & kernel code, I unclicked 'primary vga' in my desktop with passthrough. This avoids setting 'kvm=off' and allows the kvm-clock to work. Gory details available if anyone is interested!

The vm seems happier with kvm-clock, and the desktop still runs fine on the passed-through GPU.

 

[gfngfn256]

I've learned something new today.

Good you've got it working. Maybe tag mark the thread-title with [SOLVED], (upper right hand corner under title).