From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (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 1F76E367F32 for ; Tue, 31 Mar 2026 02:14:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774923295; cv=none; b=W0KGA18bg6dIHx8j76pyQ7f9pb8ZePosq2OVMpJBQO9C5JfS1ZozB8I9FmAKmoD7FxOOD8jlVnVYYMrXCj6DA3ZtQROJN7gyyZDPNra0EQyw4d6GJgPhVnKS3dit2tJt6g43TJvPM0sGaKCmvBDTTmmFyJo7dYIB7F8WqspX7HM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774923295; c=relaxed/simple; bh=n4CdttHml2hta1YnC1Bz8vLvyKVsWo76dZTk4D9nq4g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=ubq/hvCD2PR/DniAOf2J6k9FDvDPg0Yp2VIGuitx2i60b8qx768aT43DSkZJDrbiefmH5WMoIpxdGpSThYu1X8Xopt3z1k0fy8xHldK7Os8wLlPWrJAl3atWNLG0t2JJkxBwC4pAdZEV70Xzsoktd8fuIOxQF5NQoKJKF6LJBss= 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=T33pYams; arc=none smtp.client-ip=192.198.163.8 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="T33pYams" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1774923294; x=1806459294; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=n4CdttHml2hta1YnC1Bz8vLvyKVsWo76dZTk4D9nq4g=; b=T33pYamsOsnXJJz9qBZUwmA8leWai5QHif2SYJHHD4YH04Y+OpXBjaWS KzMqryljqaeLyQ3eafDxvJB9yxNjJ/LQ28lTF+MVmhsA1deqJKYlmLPS1 YOSeQM5athyttt/Nwhex+GoxL94xjXnB2mwX7YRPZorgF+zH3uJFqmUCT s6Sv7f5YYGJQygM/YY29eSNUYPTJmc1tl68BhwG5Q5om5Xn14tnDXdtfP J/ExRpmdhERlIjhZM8ffGxJLscTX+uhWM05sws7rphAeC3bomJEBrfK2X oF6jAzwIWDW+Q+LVoxzgyp7Ek9oVsk+ZzaQkI3TsxRunzpMRSvozpOVX5 Q==; X-CSE-ConnectionGUID: KONPo1J6QbeU/XDX9voBlA== X-CSE-MsgGUID: i98+JP1kQ82D6tp+lFBDvw== X-IronPort-AV: E=McAfee;i="6800,10657,11744"; a="93508026" X-IronPort-AV: E=Sophos;i="6.23,151,1770624000"; d="scan'208";a="93508026" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Mar 2026 19:07:38 -0700 X-CSE-ConnectionGUID: tUAIIfesTACtROihf9zJxA== X-CSE-MsgGUID: aaTvuFpiQw2SHeOC2x5p8g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,151,1770624000"; d="scan'208";a="221358618" Received: from chang-linux-3.sc.intel.com (HELO chang-linux-3) ([172.25.66.172]) by fmviesa006.fm.intel.com with ESMTP; 30 Mar 2026 19:07:32 -0700 From: "Chang S. Bae" To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, tglx@kernel.org, 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 v2 00/11] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine Date: Tue, 31 Mar 2026 01:42:38 +0000 Message-ID: <20260331014251.86353-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 The last version [0] took off patches for the new NMI stop-machine facility from the dynamic mitigation series. The review comments prompted me reconsider it and I ended up reworking on that part for this series. Here are a few things to call out * Introduce a cpumask to ensure NMI delivery to target CPUs, which allows removal of the static key and per-CPU flag (Boris) * Add a Kconfig to hide the facility to other architectures. There is no known use case outside x86, so this is to avoid any misuse (Thomas) * Switch to accumulate error code for multi-CPU stop-machine instead of returning an arbitrary error (Boris) * Ensure the handler write the return value before it is read. In practice, it was observed that IPI/NMI was not immediate, but an immediate read without any guard isn't reliable. * Clarify the behavior when no CPU target is given (@cpus=NULL). Instead of executing the stop function on every online CPU, it picks only one CPU (CPU0, in fact) to run. * Refactor the existing flow to better accommodate the new facility. Other than that, the rest of x86 side changes are relatively minor (typo, renaming, rebasing). --- Below is an updated version of the original cover letter: 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. The new facility incorporates this logic: * Raise self-NMI, then execute the stop function from the handler With simplification: * Replace the static key and per-CPU flag with a cpumask that ensures NMI delivery. Given this, convert this to use the (new) stop-machine API. == 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 a new NMI stop-machine 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, no new facility is introduced for offline CPUs. Instead, the existing per-CPU flag in the x86 microcode loader continues to gate the handler without the (now removed) static key. == Patch Structure == * PATCH 1–6: Establish the stop-machine NMI facility * PATCH 7–10: Incremental refactoring, with offline handling update. The patch set is available in this repository: git://github.com/intel-staging/microcode.git nmi-stop-machine_v2 Testing was performed using late-loading on Intel CPUs, which default to the NMI-based update path. Thanks, Chang [0] V1: https://lore.kernel.org/lkml/20260125014224.249901-1-chang.seok.bae@intel.com/ [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 (9): stop_machine: Clarify @cpus == NULL semantics stop_machine: Accumulate error code rather than overwrite stop_machine: Refactor multi-CPU stop glue code stop_machine: Add NMI-based execution path stop_machine: Introduce stop_machine_nmi_cpuslocked() x86/microcode: Distinguish NMI control path on stop-machine callback x86/microcode: Use stop-machine NMI facility x86/nmi: Simplify offline microcode handler invocation x86/microcode: Remove microcode_nmi_handler_enable David Kaplan (2): x86/apic: Implement self-NMI support x86/nmi: Support NMI stop-machine handler arch/Kconfig | 3 + arch/x86/Kconfig | 1 + arch/x86/include/asm/microcode.h | 11 -- arch/x86/kernel/apic/ipi.c | 10 ++ arch/x86/kernel/cpu/microcode/core.c | 35 +---- arch/x86/kernel/nmi.c | 7 +- include/linux/stop_machine.h | 58 +++++++-- kernel/stop_machine.c | 188 +++++++++++++++++++++++---- 8 files changed, 241 insertions(+), 72 deletions(-) base-commit: 6e45429392a5cdd8168619d7558f7bd6cf706394 -- 2.51.0