> On 12. May 2026, at 22:36, Scott J. Goldman <[email protected]> wrote:
> 
> On Tue May 12, 2026 at 1:54 PM EDT, Mohamed Mediouni wrote:
>> 
>> 
>>> On 27. Apr 2026, at 21:55, Scott J. Goldman <[email protected]> wrote:
>>> 
>>> Commit b5f8f77271 ("accel/hvf: Implement WFI without using pselect()")
>>> changed hvf_wfi() from blocking the vCPU thread with pselect() to
>>> returning EXCP_HLT, intending QEMU's main event loop to handle the
>>> idle wait. However, cpu->halted was never set, so cpu_thread_is_idle()
>>> always returns false and the vCPU thread spins at 100% CPU per core
>>> while the guest is idle.
>>> 
>>> Fix this by:
>>> 
>>> 1. Setting cpu->halted = 1 in hvf_wfi() so the vCPU thread sleeps on
>>>  halt_cond in qemu_process_cpu_events().
>>> 
>>> 2. Arming a per-vCPU QEMU_CLOCK_VIRTUAL timer to fire when the guest's
>>>  virtual timer (CNTV_CVAL_EL0) would expire. This is necessary
>>>  because HVF only delivers HV_EXIT_REASON_VTIMER_ACTIVATED during
>>>  hv_vcpu_run(), which is not called while the CPU is halted. The
>>>  timer callback mirrors the VTIMER_ACTIVATED handler: it raises the
>>>  vtimer IRQ through the GIC and marks vtimer_masked, causing the
>>>  interrupt delivery chain to wake the vCPU via qemu_cpu_kick().
>>> 
>>> 3. Clearing cpu->halted in hvf_arch_vcpu_exec() when cpu_has_work()
>>>  indicates a pending interrupt, and cancelling the WFI timer.
>>> 
>>> 4. Re-arming the WFI timer from hvf_vm_state_change() on the resume
>>>  transition for any halted vCPU, since the QEMUTimer is per-instance
>>>  state and is not migrated. After cpu_synchronize_all_states() the
>>>  migrated vtimer state is mirrored in env, so we can read CNTV_CTL
>>>  and CNTV_CVAL from there. If the vtimer has already expired by the
>>>  time the destination resumes, hvf_wfi_timer_cb() is invoked
>>>  directly so the halted vCPU is woken up.
>>> 
>>> Fixes: b5f8f77271 ("accel/hvf: Implement WFI without using pselect()")
>>> Signed-off-by: Scott J. Goldman <[email protected]>
>> 
>> Hi,
>> 
>> A bit of a side note for reproducing this:
>> 
>> To reproduce this on current master, as far as I can tell you need either 
>> -M kernel-irqchip=off or -M virt-11.0 or earlier. -M virt(-11.1) on master 
>> uses 
>> the HVF vGIC path.
> 
> Just wanted to confirm that I re-tested and it seems like you are
> correct. This must have changed semi recently?

Hi,

It finally got merged last week.

> I was just running with `-M virt` before. Either way, it's good that the 
> defaults seem to work
> better now. Either way, I guess the fix still needs to go in for the
> non vGIC path?
> 

Yes. I’ll do a review. This patch is also a qemu-stable candidate.




Reply via email to