. On Mon, 28 Feb 2022 at 07:04, Eugene Huang <euge...@nvidia.com> wrote: > I am running qemu on an arm64 CentOS host. Inside a ubuntu VM, a process runs > a timer created using timer_t: > > ev.sigev_notify_function = m_callback; > > … > > timer_create(CLOCK_MONOTONIC, &ev, &m_timer_t); > > > > This timer sometimes has significant delays. For example, the 50 ms timer can > have a callback delay of 100ms. > > > > I did a host kernel trace and see a lot of WFx kvm_exits, and the following > events between kvm_exit and kvm_entry:
For questions that are really about KVM and not QEMU, you'll probably find more experts on kvm...@lists.cs.columbia.edu. My non-expert look at this series of events: > kvm_exit > kvm_wfx_arm64 The guest kernel has nothing to do, so it idles, waiting for the next interrupt. > kvm_get_timer_map > sched_switch > kvm_timer_save_state So the host schedules something else instead of this vCPU (I think). > kvm_timer_update_irq > vgic_update_irq_pending At some later date, the timer IRQ fires... > kvm_timer_restore_state > kvm_vcpu_wakeup > kvm_arm_setup_debug > kvm_arm_set_dreg32 > kvm_entry ...so we reschedule the vCPU and re-enter the guest. I don't know why the timer might have significant delays, but of course if your host system is very heavily loaded we might not get round to rescheduling the vCPU for a bit. thanks -- PMM
