On Tue Nov 3, 2026 at 11:52 PM +08, Anup Patel wrote:
> On Tue, Nov 3, 2026 at 1:34 PM Troy Mitchell <troy.mitchell@linux.dev> wrote:
>>
>> Remote IMSIC state updates are deferred to a timer on the target CPU.
>> If that CPU has stopped its local clockevent and is waiting for a
>> broadcast interrupt, enabling the broadcast IRQ can depend on delivery
>> of that same interrupt. This can stall timer delivery when the broadcast
>> IRQ is unmasked or moved to another CPU, including during CPU hotplug.
>>
>> Queue hard IRQ work to synchronize remote state independently of timer
>> delivery. Keep synchronous updates on the local CPU and the timer retry
>> for an unfinished vector move. Hard IRQ work also avoids depending on a
>> schedulable worker when PREEMPT_RT is enabled.
>
> Using timer retry for local CPU and IRQ work queue for remote CPUs looks
> strange. Why not use IRQ work queue even for local CPU ??
On the local CPU the sync runs synchronously, so there is nothing to
queue. The timer only retries an unfinished move, and by then the new
vector is already enabled, so it cannot stall on the broadcast IRQ.
Requeueing IRQ work from its own handler would just keep self-IPIing
until the old CPU catches up.

I'll add more comments and modify the commit body.

-- 
Troy Mitchell