[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230810202519.GD212435@hirez.programming.kicks-ass.net>
Date: Thu, 10 Aug 2023 22:25:19 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
Borislav Petkov <bp@...en8.de>,
Ashok Raj <ashok.raj@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [patch 23/30] x86/microcode: Provide new control functions
On Thu, Aug 10, 2023 at 08:38:00PM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@...utronix.de>
>
> The current all in one code is unreadable and really not suited for adding
> future features like uniform loading with package or system scope.
>
> Provide a set of new control functions which split the handling of the
> primary and secondary CPUs. These will replace the current rendevouz all in
> one function in the next step. This is intentionally a separate change
> because diff makes an complete unreadable mess otherwise.
>
> So the flow separates the primary and the secondary CPUs into their own
> functions, which use the control field in the per CPU ucode_ctrl struct.
>
> primary() secondary()
> wait_for_all() wait_for_all()
> apply_ucode() wait_for_release()
> release() apply_ucode()
This hard assumes SMT2, right? If someone were ever to do an x86 smt4
part then smt siblings 1,2,3 would all apply concurrently in secondary,
is that intended?
> + /*
> + * Wait for primary threads to complete. If one of them hangs due
> + * to the update, there is no way out. This is non-recoverable
> + * because the CPU might hold locks or resources and confuse the
> + * scheduler, watchdogs etc. There is no way to safely evacuate the
> + * machine.
> + */
> + if (!wait_for_ctrl())
> + panic("Microcode load: Primary CPU %d timed out\n", ctrl_cpu);
One way around this is to first hot-unplug the CPUs, then NMI prod them
into the rendevous, and only on-line them again if ucode update is
successful. On failure stick them in a (new) error state so that manual
online also fails and scream murder, like above.
But yeah, rather unlikely, and for another day etc..
Powered by blists - more mailing lists