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

[Jan Beulich <jbeulich@suse.com>]

On 18.08.2026 15:07, Andrew Cooper wrote:
> Panicing in the case of a timeout turns out to be about the worst possible
> action Xen can take.  It leaves all other APs waiting on the condition
> variable, some in NMI context.  As a result, they fail to be shot down and
> dump state for kexec crash analysis.

At the same time there likely isn't much to be learned from a kexec dump, as
the source of the issue is in the CPU, not in Xen.

Further, this code runs with the watchdog disabled. If there's truly no
progress anymore, how would one know from the outside whether the system is
dead altogether vs the control CPU still kicking around?

> Microcode Loading on Granite Rapids takes about 4.5s of wallclock time, far in
> excess of the of the arbitrary 1s Xen allows.  This time is spent in the WRMSR
> to load the blob, and there's nothing the system can do but to sit and wait.
> Despite the delay, the system as a whole does survive.

For this I wonder whether the log message issues after 1 sec is adequate. If
we know things can take this long, wouldn't we better issue the log message
no earlier than, say, 5s * nr_sockets?

> Microcode loading occures through admin operation only, so get rid of the
> timeout completely.  It does nothing but make a bad sitaution worse.

Worse when taking one perspective, yes, yet a silent hang also is worse than
a panic() telling you what was wrong.

This is a tough one, with - likely - no really good options. And establishing
what's "least bad" may also be difficult.

Jan