From patchwork Tue Feb 25 22:29:04 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13991126 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C9169C021B2 for ; Tue, 25 Feb 2025 22:31:36 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.895997.1304680 (Exim 4.92) (envelope-from ) id 1tn3SM-00080N-HV; Tue, 25 Feb 2025 22:31:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 895997.1304680; Tue, 25 Feb 2025 22:31:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tn3SM-0007yz-By; Tue, 25 Feb 2025 22:31:14 +0000 Received: by outflank-mailman (input) for mailman id 895997; Tue, 25 Feb 2025 22:31:12 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tn3SK-0007wd-IL for xen-devel@lists.xenproject.org; Tue, 25 Feb 2025 22:31:12 +0000 Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [2a00:1450:4864:20::429]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 3675954e-f3c8-11ef-9897-31a8f345e629; Tue, 25 Feb 2025 23:31:10 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-38f406e9f80so5641697f8f.2 for ; Tue, 25 Feb 2025 14:31:10 -0800 (PST) Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43aba532d33sm1561315e9.15.2025.02.25.14.31.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2025 14:31:08 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 3675954e-f3c8-11ef-9897-31a8f345e629 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1740522670; x=1741127470; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=j6k0r0buy4PFVFnjhXbZhLrrEk2+FHrptJRXGWnFanI=; b=FSwakNvbZQa8oieaZR+UtxQmIC5/m2hMeWo5OUmHnGFWZCJwOX2oDJdwcOh32WoZfN 98I8sRqiKxCPgoLOehCRQu3lfWMH1yqoD8X3YGv0kMFv+PEPmAU/9uN5t+7rPDW4aRvV 9mNCMnTazV3zYb/QE+6qWG++IJd192wmfDi8g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740522670; x=1741127470; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j6k0r0buy4PFVFnjhXbZhLrrEk2+FHrptJRXGWnFanI=; b=j4JqctxU54cEOQxd3If0ayhQ2wBVtzl/3cGpEyjiMXDAaQLORFKEL5QSR7YlYTggBl quVt3NuViPZGgRXhaxDFZlolVK6yD4jWsbAuxbKfdmbnVPlTT30ecG0xy3sJUPCX738X atBlebgoamf7HWhiEqrSNz5HgBrYB54MolVzEr6ZbHYEBMe4sKb2Sh+p6hTho9ATITuw 0oPZB9K0O0c5K8qyo1NqVb/epgFrghbkjICKpNqMRz5JKnk5DFiLk3Te2u4dlz2I407s ahrm11Sk9RBY8vTMKOXulCrWLprw2Z/bzB656Q3oVUbTDhraVZkAXsA167PyfGiXndAM JQaA== X-Gm-Message-State: AOJu0YzJtiEQizVxQmfbKpl9H2qU0DPYmEF7CH1ubJEMpGh74ySFx489 4UhwExHaILvp1N+vhaAq1hx/zyK4zotMU+wlwA5IdWC0dsWeKsI6F7bN96mTSRUyzU14w3Ql5hP T X-Gm-Gg: ASbGncuio9XwfvCxbkXnNMEeNgJYsmAU7hrfJQyBH6wqhPx3tPzezXRZPIvSuWDxlNf hW5YUaSv68RSOWAjx0sHEgY9paDN87wms2Z4UzVwee6kD/WGnBLwouUiKbUqC2242MhyXoOTacr 9KVbcu342Iz58JQOtfmuvv94sW3Q7uZBf6vF4vjSsF+zyvD+ch56aE3gTCq0G84HRlv9VrVTsNb BP3gXzk95X2uXJqaYi6M4HZpcwrMZo3XH6SHF3C1f065UPnEisGKDImSc+VeoWBjUq9DUlyH0DG vr+gtsopBWM/M7osBxQ9/TP3khjFfJL2i2zcR3pQMRVlhW2je23qdpcWcey2xnMoxD/5V+25zzg 27mtipw== X-Google-Smtp-Source: AGHT+IGpJOI6/YFaPSiDY+PbZCjyF0007EHzLhP2bR379Ljx/pd/4K9fn/HDqg+N+q8PH4b3rSeHRQ== X-Received: by 2002:a5d:5f4e:0:b0:38f:4a0b:e764 with SMTP id ffacd0b85a97d-390d4f4306cmr857624f8f.28.1740522669724; Tue, 25 Feb 2025 14:31:09 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: [PATCH 1/2] x86/ucode: Adjust parse_ucode() to match other list handling Date: Tue, 25 Feb 2025 22:29:04 +0000 Message-Id: <20250225222905.1182374-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250225222905.1182374-1-andrew.cooper3@citrix.com> References: <20250225222905.1182374-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 parse_ucode() is abnormal compared to similar parsing elsewhere in Xen. Invert the ucode_mod_forced check with respect to the "scan" and integer handling, so we can warn the user when we've elected to ignore the parameters, and yield -EINVAL for any unrecognised list element. Rewrite the ucode= command line docs for clarity. No practical change. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Roger Pau Monné --- docs/misc/xen-command-line.pandoc | 56 ++++++++++++++++++------------- xen/arch/x86/cpu/microcode/core.c | 22 ++++++++---- 2 files changed, 47 insertions(+), 31 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 0c6225391d55..47674025249a 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2721,34 +2721,42 @@ performance. Alternatively, selecting `tsx=1` will re-enable TSX at the users own risk. ### ucode -> `= List of [ | scan=, nmi= ]` +> `= List of [ , scan=, nmi= ]` Applicability: x86 Default: `scan` is selectable via Kconfig, `nmi=true` -Controls for CPU microcode loading. For early loading, this parameter can -specify how and where to find the microcode update blob. For late loading, -this parameter specifies if the update happens within a NMI handler. - -'integer' specifies the CPU microcode update blob module index. When positive, -this specifies the n-th module (in the GrUB entry, zero based) to be used -for updating CPU micrcode. When negative, counting starts at the end of -the modules in the GrUB entry (so with the blob commonly being last, -one could specify `ucode=-1`). Note that the value of zero is not valid -here (entry zero, i.e. the first module, is always the Dom0 kernel -image). Note further that use of this option has an unspecified effect -when used with xen.efi (there the concept of modules doesn't exist, and -the blob gets specified via the `ucode=` config file/section -entry; see [EFI configuration file description](efi.html)). - -'scan' instructs the hypervisor to scan the multiboot images for an cpio -image that contains microcode. Depending on the platform the blob with the -microcode in the cpio name space must be: - - on Intel: kernel/x86/microcode/GenuineIntel.bin - - on AMD : kernel/x86/microcode/AuthenticAMD.bin -When using xen.efi, the `ucode=` config file setting takes -precedence over `scan`. The default value for `scan` is set with -`CONFIG_UCODE_SCAN_DEFAULT`. +Controls for CPU microcode loading. + +In order to load microcode at boot, Xen needs to find a suitable update +amongst the modules provided by the bootloader. Two kinds of microcode update +are supported: + + 1. Raw microcode containers. The format of the container is CPU vendor + specific. + + 2. CPIO archive. This is Linux's preferred mechanism, and involves having + the raw containers expressed as files + (e.g. `kernel/x86/microcode/{GenuineIntel,AuthenticAMD}.bin`) in a CPIO + archive, typically prepended to the initrd. + +The `` and `scan=` options are mutually exclusive and select between +these two options. They are also invalid in EFI boots (see below). + + * The `` option nominates a specific multiboot module as a raw + container (option 1 above). Valid options start from 1 (module 0 is + always the dom0 kernel). A negative number may be used, and will + back-reference from the end of the module list. i.e. `ucode=-1` will + nominate the final multiboot module. + + * The `scan=` option causes Xen to search all modules in order to find the + first CPIO archive containing the appropriate file (option 2 above). The + default for this option can be chosen at build time via + `CONFIG_UCODE_SCAN_DEFAULT`. + +When booting xen.efi natively, the concept of multiboot modules doesn't exist. +Instead, in the [EFI configuration file](efi.html), `ucode=` can be +used to identify a file as a raw container (option 1 above). 'nmi' determines late loading is performed in NMI handler or just in stop_machine context. In NMI handler, even NMIs are blocked, which is diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index de00c22b4bd6..c8e14ed9b10c 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -113,11 +113,6 @@ void __init microcode_set_module(unsigned int idx) ucode_mod_forced = 1; } -/* - * The format is '[|scan=, nmi=]'. Both options are - * optional. If the EFI has forced which of the multiboot payloads is to be - * used, only nmi= is parsed. - */ static int __init cf_check parse_ucode(const char *s) { const char *ss; @@ -130,13 +125,24 @@ static int __init cf_check parse_ucode(const char *s) if ( (val = parse_boolean("nmi", s, ss)) >= 0 ) ucode_in_nmi = val; - else if ( !ucode_mod_forced ) /* Not forced by EFI */ + else if ( (val = parse_boolean("scan", s, ss)) >= 0 ) { - if ( (val = parse_boolean("scan", s, ss)) >= 0 ) + if ( ucode_mod_forced ) + printk(XENLOG_WARNING + "Ignoring ucode=%.*s setting; overridden by EFI\n", + (int)(ss - s), s); + else { opt_scan = val; opt_mod_idx = 0; } + } + else if ( isdigit(s[0]) || s[0] == '-' ) + { + if ( ucode_mod_forced ) + printk(XENLOG_WARNING + "Ignoring ucode=%.*s setting; overridden by EFI\n", + (int)(ss - s), s); else { const char *q; @@ -151,6 +157,8 @@ static int __init cf_check parse_ucode(const char *s) opt_scan = false; } } + else + rc = -EINVAL; s = ss + 1; } while ( *ss ); From patchwork Tue Feb 25 22:29:05 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 13991124 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 36C32C021B2 for ; Tue, 25 Feb 2025 22:31:31 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.895996.1304675 (Exim 4.92) (envelope-from ) id 1tn3SM-0007xc-8N; Tue, 25 Feb 2025 22:31:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 895996.1304675; Tue, 25 Feb 2025 22:31:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tn3SM-0007xV-4u; Tue, 25 Feb 2025 22:31:14 +0000 Received: by outflank-mailman (input) for mailman id 895996; Tue, 25 Feb 2025 22:31:12 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tn3SK-0007iP-7h for xen-devel@lists.xenproject.org; Tue, 25 Feb 2025 22:31:12 +0000 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [2a00:1450:4864:20::334]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 37065794-f3c8-11ef-9aae-95dc52dad729; Tue, 25 Feb 2025 23:31:11 +0100 (CET) Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-439950a45daso38857915e9.2 for ; Tue, 25 Feb 2025 14:31:11 -0800 (PST) Received: from andrewcoop.eng.citrite.net (host-92-26-98-202.as13285.net. [92.26.98.202]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43aba532d33sm1561315e9.15.2025.02.25.14.31.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2025 14:31:10 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 37065794-f3c8-11ef-9aae-95dc52dad729 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1740522671; x=1741127471; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=2Fkj7PIxDfVF3eAOzL41OOsZ3g02DzrICaIejNCr/tw=; b=e15GyjBvsKRMuO1hzJsnbQlVc369IzJJEOp7Aal8lTB7u5lbFFIdbyuvjUo4dsvUbT CbnFKgobsUIO0JGjIZe6EWP/tQTFXfabPmb03T97Dgu0CbQEECVYG/BNdlIYTS2NvuvY J2al9DHCmNCv8Wh75XAl7DwYrBZ4vyBTtgOwc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740522671; x=1741127471; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2Fkj7PIxDfVF3eAOzL41OOsZ3g02DzrICaIejNCr/tw=; b=QZlqFbYw7bAY86EGMgKg5i1Hee279owY7STsdDP0txM6ICNPdGWTq2AAqngPfdG+4Z ePnUwj/KaSaCHFAriQbnJxvYdBsnzDHeL7kq/cwUeVkwPUes7qnCMPVHOxuOCJ5qXads geO6iUZzOLdUBlTHx9m4PCdxoEPei2oz1U/DiwavL85MRGLsyRzFB4r4lT3G09X9E2cy LjfWacqMPaxYx0zpF+/Y64SvTD3yS8cJC9Z7310JBp64xA2ZmxGXmXPcGr91BCs+MEpN fsmUgid6rm75cbzwPtSp9RCkT0cYtAURNO8+zsbxy76UFLg6oiC6XVYXkKYUYoZ3yZiv sLYw== X-Gm-Message-State: AOJu0Yz8uR5VuWAvjhghz1Bpk2IUpG0X4zwWOm5ONnmdobcsThSaXmTH M971vZM5xkr2C1cRqOdi/Lk2b6P6peJsNHj51HrJ37QCqlYXFaIzoeoIXVOq5mbBHaX9EkoBZlQ 4 X-Gm-Gg: ASbGncvE4W3Ab0EN/nadZbz1quDSVhwjDMW4fXDTcJWbs2ZuJV4qApDyg25LXsVttB1 nT2zRaz3pyI3HMCc61v3fgGlexDyfOdzxdekgM5sue27J4i7wAoMVHRYUcPCup+AOAis1fK6dEG 2+55aqMfMV98XKkiBrfKfcsnMyjS4X1VTackD6zmIlEgT7afhYCPvbhxupOXdUSHYthKbhSZV5f DyaJsH2p8aNt191x/UuRI2Kv66XbbkY5ud2e0uziRRRcNANpmXf5knNmhh9Ex6yinn3fCP3Rvxa NKe07G0G9wAzoAjFCbnJH5BB1DCZy0HPZU9/t28Haz90njqaM1bvwp9yL7neb4+S+rkUSxIMTV5 DU1tinA== X-Google-Smtp-Source: AGHT+IGgzgKhjyv8Qm2BP9+QaUI5xtZwUepEZX75ASg0Q9pPgwuh497t4wYNo2ahmQ8s/UzZOrm7XA== X-Received: by 2002:a5d:4acb:0:b0:38f:3a89:fdb1 with SMTP id ffacd0b85a97d-390cc60d30emr2548760f8f.30.1740522670644; Tue, 25 Feb 2025 14:31:10 -0800 (PST) From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , Jan Beulich , =?utf-8?q?Roger_Pau_Monn=C3=A9?= Subject: [PATCH 2/2] x86/ucode: Drop the ucode=nmi option Date: Tue, 25 Feb 2025 22:29:05 +0000 Message-Id: <20250225222905.1182374-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250225222905.1182374-1-andrew.cooper3@citrix.com> References: <20250225222905.1182374-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 This option is active by default, and despite what the documentation suggests about choosing ucode=no-nmi, it only controls whether the primary threads move into NMI context. Sibling threads unconditionally move into NMI context, which is confirmed by an in-code comment. Not discussed is the fact that the BSP never enters NMI context, which works only by luck (AMD CPUs, where we reload on sibling threads too, has working in-core rendezvous and doesn't require NMI cover on the primary thread for safety). This does want addressing, but requires more untangling first. Overall, `ucode=no-nmi` is a misleading and pretty useless option. Drop it, and simplify the two users. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monné Despite the reasonably large diff in primary_thread_fn(), it's mostly just unindenting the block, and dropping the final call to primary_thread_work() which is made dead by this change. --- docs/misc/xen-command-line.pandoc | 8 ++----- xen/arch/x86/cpu/microcode/core.c | 38 +++++++++++-------------------- 2 files changed, 15 insertions(+), 31 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 47674025249a..9702c36b8c39 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -2721,10 +2721,10 @@ performance. Alternatively, selecting `tsx=1` will re-enable TSX at the users own risk. ### ucode -> `= List of [ , scan=, nmi= ]` +> `= List of [ , scan=` can be used to identify a file as a raw container (option 1 above). -'nmi' determines late loading is performed in NMI handler or just in -stop_machine context. In NMI handler, even NMIs are blocked, which is -considered safer. The default value is `true`. - ### unrestricted_guest (Intel) > `= ` diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index c8e14ed9b10c..4898920b9c52 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -82,9 +82,6 @@ struct patch_with_flags { const struct microcode_patch *patch; }; -/* By default, ucode loading is done in NMI handler */ -static bool ucode_in_nmi = true; - /* Protected by microcode_mutex */ static struct microcode_patch *microcode_cache; @@ -123,9 +120,7 @@ static int __init cf_check parse_ucode(const char *s) if ( !ss ) ss = strchr(s, '\0'); - if ( (val = parse_boolean("nmi", s, ss)) >= 0 ) - ucode_in_nmi = val; - else if ( (val = parse_boolean("scan", s, ss)) >= 0 ) + if ( (val = parse_boolean("scan", s, ss)) >= 0 ) { if ( ucode_mod_forced ) printk(XENLOG_WARNING @@ -297,12 +292,10 @@ static int cf_check microcode_nmi_callback( return 0; /* - * Primary threads load ucode in NMI handler on if ucode_in_nmi is true. - * Secondary threads are expected to stay in NMI handler regardless of - * ucode_in_nmi. + * The BSP doesn't enter NMI context for microcode loading, as it's the + * entity organising the rendezvous. */ - if ( cpu == cpumask_first(&cpu_online_map) || - (!ucode_in_nmi && primary_cpu) ) + if ( cpu == cpumask_first(&cpu_online_map) ) return 0; if ( primary_cpu ) @@ -343,22 +336,17 @@ static int primary_thread_fn(const struct microcode_patch *patch, if ( !wait_for_state(LOADING_CALLIN) ) return -EBUSY; - if ( ucode_in_nmi ) - { - self_nmi(); - - /* - * Wait for ucode loading is done in case that the NMI does not arrive - * synchronously, which may lead to a not-yet-updated error is returned - * below. - */ - if ( unlikely(!wait_for_state(LOADING_EXIT)) ) - ASSERT_UNREACHABLE(); + self_nmi(); - return this_cpu(loading_err); - } + /* + * Wait for ucode loading is done in case that the NMI does not arrive + * synchronously, which may lead to a not-yet-updated error is returned + * below. + */ + if ( unlikely(!wait_for_state(LOADING_EXIT)) ) + ASSERT_UNREACHABLE(); - return primary_thread_work(patch, flags); + return this_cpu(loading_err); } static int control_thread_fn(const struct microcode_patch *patch,