From: "Scott J. Goldman" <scottjgo@gmail.com>
To: "Scott J. Goldman" <scottjgo@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: <qemu-devel@nongnu.org>, <qemu-arm@nongnu.org>,
<rbolshakov@ddn.com>, <phil@philjordan.eu>, <agraf@csgraf.de>,
<peter.maydell@linaro.org>,
"Mohamed Mediouni" <mohamed@unpredictable.fr>
Subject: Re: [PATCH v2] target/arm/hvf: Fix WFI halting to stop idle vCPU spinning
Date: Tue, 21 Apr 2026 16:24:16 -0700 [thread overview]
Message-ID: <DHZ7Y1A1LLPK.3R5MOKPN5NWPD@gmail.com> (raw)
In-Reply-To: <DHVPR5CMUKMG.3803OP5N2C9J3@gmail.com>
On Fri Apr 17, 2026 at 1:30 PM PDT, Scott J. Goldman wrote:
> On Fri Apr 17, 2026 at 2:57 AM PDT, Philippe Mathieu-Daudé wrote:
>> Hi Scott,
>>
>> On 16/4/26 23:20, Scott J. Goldman wrote:
>>> Philippe-- apologies for the nag here but this is a fix for a unfortunate
>>> regression. Any chance you could take a look? Thanks!
>>>
>>> On Thu Apr 9, 2026 at 11:18 PM PDT, Mohamed Mediouni wrote:
>>>>
>>>>
>>>>> On 10. Apr 2026, at 07:50, Scott J. Goldman <scottjgo@gmail.com> 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 host-side QEMU_CLOCK_HOST 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.
>>>>>
>>>>> Fixes: b5f8f77271 ("accel/hvf: Implement WFI without using pselect()")
>>>>> Signed-off-by: Scott J. Goldman <scottjgo@gmail.com>
>>>>
>>>> Reviewed-by: Mohamed Mediouni <mohamed@unpredictable.fr>
>>>>> ---
>>>>> include/system/hvf_int.h | 1 +
>>>>> target/arm/hvf/hvf.c | 65 +++++++++++++++++++++++++++++++++++++++-
>>>>> 2 files changed, 65 insertions(+), 1 deletion(-)
>>
>> I haven't looked at your patch yet. While looking at commit
>> b5f8f77271 I noticed the previous a14afa985e3 ("accel/hvf: Skip
>> WFI if CPU has work to do") is different in my local tree, where
>> I have:
>>
>> -- >8 --
>> diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
>> index 5fc8f6bbbd9..1a76c9cf402 100644
>> --- a/target/arm/hvf/hvf.c
>> +++ b/target/arm/hvf/hvf.c
>> @@ -2037,6 +2037,11 @@ static int hvf_wfi(CPUState *cpu)
>> return 0;
>> }
>>
>> + if (cpu_test_interrupt(cpu, CPU_INTERRUPT_HARD | CPU_INTERRUPT_FIQ)) {
>> + /* Interrupt pending, no need to wait */
>> + return EXCP_INTERRUPT;
>> + }
>> +
>> return EXCP_HLT;
>> }
>>
>> ---
>>
>> Does that help? Now I'm really confused.
>
>
> Hi Phillipe-- Appreciate your help here. The good news is the bug is
> very easy to reproduce (start a linux VM with 1 cpu, watch the vCPU on
> the host will always spin 100%). The bad news is I double checked my
> bisect and you can see before b5f8f77271 there is no problem, and after
> the commit is introduced, the problem appears. I also applied the
> additional cpu_test_interrupt() patch you suggested and it did not
> change the behavior.
>
> thanks
> -sjg
Hi Philippe- Apologies again for bugging you, but it looks like v11 is
about to be released and it would be a bummer if this regression went
out with the stable version. Have you had a chance to either look at my
patch or check if there was some other simpler fix?
Also, I'm not a regular qemu contributor, so if there is some process
here, that I'm missing, please let me know.
thanks
-sjg
next prev parent reply other threads:[~2026-04-22 0:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-10 4:47 [PATCH] target/arm/hvf: Fix WFI halting to stop idle vCPU spinning Scott J. Goldman
2026-04-10 5:06 ` Mohamed Mediouni
2026-04-10 5:28 ` Scott J. Goldman
2026-04-10 5:50 ` [PATCH v2] " Scott J. Goldman
2026-04-10 6:18 ` Mohamed Mediouni
2026-04-16 21:20 ` Scott J. Goldman
2026-04-17 9:57 ` Philippe Mathieu-Daudé
2026-04-17 20:30 ` Scott J. Goldman
2026-04-21 23:24 ` Scott J. Goldman [this message]
2026-04-27 11:15 ` Peter Maydell
2026-04-27 18:42 ` Scott J. Goldman
2026-04-27 19:55 ` [PATCH v3] " Scott J. Goldman
2026-05-12 16:46 ` Scott J. Goldman
2026-05-12 19:18 ` Peter Maydell
2026-05-12 17:54 ` Mohamed Mediouni
2026-05-12 20:36 ` Scott J. Goldman
2026-05-12 20:51 ` Mohamed Mediouni
2026-05-13 1:21 ` Mohamed Mediouni
2026-05-13 2:21 ` [PATCH v11.1+ v4] " Scott J. Goldman
2026-05-15 10:39 ` Peter Maydell
2026-05-13 2:25 ` [PATCH v3] " Scott J. Goldman
2026-05-13 7:14 ` Mohamed Mediouni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DHZ7Y1A1LLPK.3R5MOKPN5NWPD@gmail.com \
--to=scottjgo@gmail.com \
--cc=agraf@csgraf.de \
--cc=mohamed@unpredictable.fr \
--cc=peter.maydell@linaro.org \
--cc=phil@philjordan.eu \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rbolshakov@ddn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.