Unlike the setting of HPET_EVT_LEGACY in hpet_broadcast_init(), the
setting of HPET_EVT_DISABLE in hpet_disable_legacy_broadcast() isn't init-
only and hence can race other flag manipulation (not all of which occur
while holding the channel's lock). While possibly any such updates would
only ever occur when HPET_EVT_LEGACY isn't set in the first place, this
doesn't look straightforward to prove, so better be on the safe side.

Fixes: d09486dba36a ("cpuidle: Enable hpet broadcast by default")
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -729,7 +729,7 @@ void hpet_disable_legacy_broadcast(void)
 
     spin_lock_irqsave(&hpet_events->lock, flags);
 
-    hpet_events->flags |= HPET_EVT_DISABLE;
+    set_bit(HPET_EVT_DISABLE_BIT, &hpet_events->flags);
 
     /* disable HPET T0 */
     cfg = hpet_read32(HPET_Tn_CFG(0));

On Mon, Nov 17, 2025 at 03:37:21PM +0100, Jan Beulich wrote:
> Unlike the setting of HPET_EVT_LEGACY in hpet_broadcast_init(), the
> setting of HPET_EVT_DISABLE in hpet_disable_legacy_broadcast() isn't init-
> only and hence can race other flag manipulation (not all of which occur
> while holding the channel's lock). While possibly any such updates would
> only ever occur when HPET_EVT_LEGACY isn't set in the first place, this
> doesn't look straightforward to prove, so better be on the safe side.
> 
> Fixes: d09486dba36a ("cpuidle: Enable hpet broadcast by default")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

I also think it's quite likely that hpet_disable_legacy_broadcast() is
not possible to be used concurrently while the setting of the other
flags, that seem to happen in broadcast mode only, but better be on
the safe side.

Acked-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.