From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5CE0A3EBF18 for ; Sun, 25 Jan 2026 02:06:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769306779; cv=none; b=PUeWywslIji2zYndd7uZ7rANuQWDipOb0RcN5h7YpeyecdovZSF28k0Ab+wFAQ2/+OVsw80Fd21TjSfwUKHBhtoGRtAHn+dd0xHztzRlTofGNoW7QvLclxlDBwgbrqZDC2VjDf1R6EOu4EKRV8nBuFWaa8OxMhFmSF+cmBnH4oE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769306779; c=relaxed/simple; bh=hj+IKOpqzo1QdycpNEaqfjzgCaSws1M/yYWKl5vPOXw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=bnpIKTYS/Yrvj5nkj2Ff9P1IDFCYfF7XfsPm1PAAXZufTHuYDQOzba+ivQv7+M+1QeaY6QD9NorKk1SYf1tqLGF6z4NF6Ws3vs3aXbY+2tizUpvmR6oWKlDAlqRiaCXJ987YW07DFNzKNeaOn4UCekJ8E+zBY/esDoRnn8MMs6c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=dhvL44sX; arc=none smtp.client-ip=192.198.163.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="dhvL44sX" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1769306776; x=1800842776; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=hj+IKOpqzo1QdycpNEaqfjzgCaSws1M/yYWKl5vPOXw=; b=dhvL44sXYDuMnydtJgvSzdO3fQrAmn9vr+1qVmJypbi+TZaaUrcVmE/j hPoxIgr+LsLcBh26qPyVEy5zKC2SV9GjZsJL+35PCMy8fAAWyb4B3QjY+ TjgyrUzfI7cu+xX22vUcFgnoBkYZKo7RS74PGh7G4Xc66db3UcCrxaRcl rzikd5rbjPtq9+sDL4BJ345ht2FYpPqBpN7YFK91WHo8FwnOgkAmno9hn BVJdYobj19/muDd+2S+Bi4iMYqzw+CNE2X9+SlNDX7VKWPvPFSGeP0n91 dlaZ045CuONqDDhQIec+cdTxU5FhyN288Ur+Or3XSXfU10dunfCp5Nlm7 A==; X-CSE-ConnectionGUID: hod1lkAyT6+gZ+eXN9gssQ== X-CSE-MsgGUID: iJftxW0iQ0u//TVYvnoLvA== X-IronPort-AV: E=McAfee;i="6800,10657,11681"; a="73101860" X-IronPort-AV: E=Sophos;i="6.21,252,1763452800"; d="scan'208";a="73101860" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2026 18:06:15 -0800 X-CSE-ConnectionGUID: oiJiR+ERTW67zBCv6J0W1w== X-CSE-MsgGUID: +M7Dz5t7R72lwV3E+zkByw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,252,1763452800"; d="scan'208";a="207783089" Received: from chang-linux-3.sc.intel.com (HELO chang-linux-3) ([172.25.66.172]) by fmviesa009.fm.intel.com with ESMTP; 24 Jan 2026 18:06:15 -0800 From: "Chang S. Bae" To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, peterz@infradead.org, david.kaplan@amd.com, chang.seok.bae@intel.com Subject: [PATCH 0/7] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine Date: Sun, 25 Jan 2026 01:42:15 +0000 Message-ID: <20260125014224.249901-1-chang.seok.bae@intel.com> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi all, David Kaplan previously proposed introducing an NMI-based stop-machine mechanism as part of his dynamic mitigation series [1]. This "big hammer" approach was also discussed during the last LPC x86 uconf [2]. This patchset uses the facility for the late-loading of Intel microcode by refactoring existing NMI control mechanism. There is one bit to call out for the review here -- offline CPU handling. Before highlighting the case, let me first walk through the online case: == Online CPU Handling == Currently, the microcode loader uses a NMI-based control flow, similar to the proposed stop_machine_nmi(). When the NMI option is enabled, the loader invokes stop-machine, and the callback establishes an IPI back to the local CPU, which then performs the microcode update from NMI context. Per-CPU flags are used throughout to ensure correct handling. The new facility directly incorporates this existing control logic, with the following components in place (mostly in PATCH1 unless noted otherwise): 1. A static key indicating the global window of stop-machine execution during rendezvous 2. A control mechanism to fire NMIs and invoke a custom handler from the NMI path, implemented in architecture-specific code (PATCH2/3) 3. A per-CPU notion of an active NMI handling window Given this, it is natural to convert this to use the generic stop_machine_nmi(). == Offline CPU Handling == With NMI-based microcode loading, soft-offlined CPUs are also brought into the rendezvous to avoid unexpected behavior changes (e.g. related to MWAIT) introduced by new microcode [3]. Today, the boot CPU explicitly fires IPIs to those offline CPUs, which establishes yet another NMI control path. However, the new stop-machine facility does not currently account for this case, as it is primarily shaped for online CPUs. This patch set is intended to introduce stop_machine_nmi() along with an existing use case (Intel ucode late-loading), independent of the dynamic mitigation series. The commonality, nonetheless, between them lies on online CPU handling. So, it was considered to make sense that the static key is just reused to condition offline CPU handling as well (PATCH6). == Patch Structure == * PATCH 1–3: Establish the stop-machine NMI facility (pretty much those PATCH29–31 of the dynamic mitigation series [1]) * PATCH 4–7: Incremental refactoring, with offline handling update. The patch set is available in this repository: git://github.com/intel-staging/microcode.git nmi-stop-machine Testing was performed using late-loading on Intel CPUs, which default to the NMI-based update path. Thanks, Chang [1]: https://lore.kernel.org/lkml/20251013143444.3999-1-david.kaplan@amd.com/ [2]: https://youtu.be/2eEPYt5XrCE?si=NUGF2pkqk8MUh9GR&t=1739 [3]: 8f849ff63bcb ("x86/microcode: Handle "offline" CPUs correctly") Chang S. Bae (4): x86/microcode: Distinguish NMI control path on stop-machine callback x86/microcode: Use stop-machine NMI facility x86/nmi: Reference stop-machine static key for offline microcode handler x86/microcode: Remove microcode_nmi_handler_enable David Kaplan (3): stop_machine: Introduce stop_machine_nmi() x86/apic: Implement self-NMI support x86/nmi: Support stop_machine_nmi() handler arch/x86/include/asm/microcode.h | 11 +--- arch/x86/kernel/apic/ipi.c | 7 +++ arch/x86/kernel/cpu/microcode/core.c | 35 +++--------- arch/x86/kernel/nmi.c | 7 ++- include/linux/stop_machine.h | 50 +++++++++++++++++ kernel/stop_machine.c | 84 ++++++++++++++++++++++++++-- 6 files changed, 150 insertions(+), 44 deletions(-) base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7 -- 2.51.0