Re: [PATCH] x86/ucode: Remove MICROCODE_UPDATE_TIMEOUT and associated panic()

On 19/08/2026 3:53 pm, Jan Beulich wrote:
> On 19.08.2026 16:04, Andrew Cooper wrote:
>> One other idea I had:
>>
>> If we rearrange the loop to have a periodic "taken $X seconds" (shows
>> liveness), and maybe at 40s decide to panic (by passing through the out:
>> label first so we release the APs, so they can crash more cleanly), then
>> that might be acceptable.
>>
>> By 40s, the system isn't surviving even if the cores do all come back.
> Maybe, yet I'm curious: How did you land at 40s as the "magic" boundary?

Mostly arbitrary.  Linux has as least one timeouts around the 20s mark
(panic on soft lockup).  XenServer has some clustering timeouts around 30s.

> For a runtime load, even the 4.5s that you say GNR takes may already be
> too much for the system (Dom0 and/or DomU-s) to properly survive as a
> whole, depending on their requirements and/or configuration.

Its 9s all together, given our algorithm.  And I was a bit surprised,
but even a busy system doesn't seem to suffer any permanent issues as a
consequence.

> Even our
> time calibration rendezvous wants to occur once a second (albeit it may
> not really need to run that often, plus iirc you have been saying that
> we should get rid of it altogether).

Most hardware from the past 15y doesn't need it at all, because of
Invariant TSC.  Some >=8 socket Intel servers need a one-off calibration
during AP bringup, but that suffices AIUI.

There is one advantage to the tsc rendezvous.  If a core/thread/etc
really goes offline, it guarantees to get caught.  With the watchdog, 5
seconds after that, you'll notice.  System-wide TLB flushes have this
property too, but they're irregular and never the thing caught by the
watchdog.

~Andrew