Re: [PULL 05/11] hpet: fix and cleanup persistence of interrupt status

[Fiona Ebner <f.ebner@proxmox.com>]

Hi,

Am 23.07.24 um 16:15 schrieb Paolo Bonzini:
> There are several bugs in the handling of the ISR register:
> 
> - switching level->edge was not lowering the interrupt and
>   clearing ISR
> 
> - switching on the enable bit was not raising a level-triggered
>   interrupt if the timer had fired
> 
> - the timer must be kept running even if not enabled, in
>   order to set the ISR flag, so writes to HPET_TN_CFG must
>   not call hpet_del_timer()

we've been getting user reports about increased CPU usage for QEMU
processes on the host after they updated from QEMU 9.0 to QEMU 9.2.
Bisecting points to this change, and users confirmed that adding the
machine option hpet=off reduces the CPU usage again. Some quick
experimentation suggests that in particular the last part here, i.e.
"timer must be kept running even if not enabled" is the reason for this.

I reproduced the issue with a Debian 12.10 guest with kernel 6.1. It
enables and then immediately disables the HPET timer again during boot
(i.e. the HPET_TN_ENABLE bit).

I also installed 6.13.7 in the guest for comparison, but that just made
the issue worse, because it uses a higher frequency for the timer.

Is this something Linux should/could handle differently? I suppose there
is nothing that can be done on the QEMU side to avoid this while aiming
to keep the implementation correct?

If necessary, our management layer downstream could disable the hpet
timer by default and make users explicitly enable it if
desired/required. I just wanted to ask if the issue is known and if
there are any other suggestions? Thanks!

Best Regards,
Fiona