Dear YangFeng, thanks for the question :-)
Timekeeping is a complex topic. Could you perhaps add more detail on what you are trying to achieve? Linux offers various API functions for timing, in the kernel and in the user space - though oops, you haven't mentioned what guest VM you are considering... Different timing functions serve different purposes, and under the hood, they tap into different hardware "resources" available (timers, counters, whatever). Such as, you can ask the guest OS: - "wake me up after 20 ms, starting from now" - Or, you can ask it "wake me up at 13:07:21.057 precisely". - Or, you may merely want to know "what time is it, right now as I'm asking?" Note that QEMU/KVM comes accompanied by a set of guest-side drivers. One of them presents a virtual PHC. This will provide a fairly precise answer to the question "what time is it right now", tapping into the host's timebase and hardware. Ordinarily, you would let your guest OS sync its timebase to that PHC, and your applications running in the guest would then get precise time just by asking their OS in the standard way. If the question really is, "how precise are the emulated HW timers", e.g. the PC AT i8254 programmable timer, or some HPET (not sure if this even gets emulated) - obviously that emulation is not so rosy. Its precision boils down to event (interrupt) handling latency and jitter. Things are relatively good if you have a whole CPU core reserved to the particular VM guest instance - but if multiple guest VM instances share the time of a physical host CPU core, guess what's likely to happen... Same thing if the HV/host OS instance is busy, especially if busy serving other interrupts. Please note that the PIT and HPET exist just once for the whole physical machine (are a part of the chipset) and therefore need to be emulated for each VM guest instance. Modern x86 CPU's supposedly also have the "local APIC timer" - and the LAPIC supposedly is private to a CPU core. Not sure to what extent the LAPIC is beneficial to virtualization - you could argue that the VM guest could use it directly, if the CPU core is reserved/dedicated to a particular guest. Yet I wouldn't bet on this, and for the general case, the host / HV will likely want to keep a handle on the LAPIC timer per core (and maybe make it available to the VM guest through some virty encapsulation mechanism). The one hardware counter that IMO needs no virty wrappers, is the TSC :-) It just counts forward, at some constant frequency, derived by multiplication from the physical CPU's external reference base. I don't quite understand your note about the TCG *accelerator*. I'm just a fellow user of QEMU, not conversant in the guts. A quick google is telling me that the TCG is the code generator inside QEMU, that's able to emulate instructions not supported by your physical CPU. In that vein, for optimal results, I would suggest to set the emulated CPU to "host" (=native). This should allow your guest OS to adapt to your host CPU's physical capabilities, thus all guest instructions get executed natively by bare metal, and thus the need to actually emulate instructions via the TCG gets minimized... Frank https://www.vmware.com/docs/vmware_timekeeping https://wiki.osdev.org/APIC_Timer https://airbus-seclab.github.io/qemu_blog/tcg_p1.html Subject: Timer quality From: Yanfeng Liu <yfliu2...@qq.com> To: qemu-discuss@nongnu.org Date sent: Wed, 05 Mar 2025 15:37:30 +0800 > Dear experts, > > I am wondering how the precision of timers are with QEMU on x64 Ubuntu > Linux and TCG accelerator? > > Regards, > yf > > > >
