Received: by 2002:a05:7412:2a8c:b0:e2:908c:2ebd with SMTP id u12csp2256571rdh; Tue, 26 Sep 2023 18:38:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHqACklFuu252rAjzcrW0MHL3i1Jy1iHfOMuoInG64OCcIipJ8bzPMsOifJFoJXHRcV9qSr X-Received: by 2002:a05:6870:170d:b0:1b0:89e0:114f with SMTP id h13-20020a056870170d00b001b089e0114fmr807252oae.31.1695778689548; Tue, 26 Sep 2023 18:38:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695778689; cv=none; d=google.com; s=arc-20160816; b=F7tWWgxchAJQLJe4mqAetUdd3XZWZg1NBzw3WFdhroHy4QxTj4GjJIZYQHvH+DYxro dKbKmElzid3xDpkVSPk2abzj4WNUECAz5cMKjhnfYp18aQechzBzIXyFq6p/ktSYiKqD YNkP8r4Iw+xKRsksOsqpTSqZF5kMXTZfCXx5grrBX/+dJRXnwrbh684QZ+oVpTLE+78y UfLbbxDLC06e5vWPPuFRxZ8geWeY9l/h3tjwa67GZ10VESxWFdRqTaLEA48l6SlpKU1i rAG9yCxk79ytuUqNcG6rzPsDz9h0D4xE6Uu0I8w8Dory/9QTwQMjy5Uqq5Qf/SzJ518d 4Q2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=GZBZ0e5+Bkgdgf988Ah3z6IPgN+5AIZaHT83aY7rkg4=; fh=PzO2CxsOiBbTGhXkcERuVR7d1qaW+lNW0j3GLCtBkwc=; b=h8/3SQ7fz54q+AIVabY0eqxbczyItagN4lG74sepb9CFvx3QZkjUTSiqrifxvUI9RY xaPf7pO9I93glFpvUyriPAZACWX5a0TWTJGgt/NGP5cmAesAQ+vmkf2kLI8LNkKI6exg vDr2v3oE9Oy3t/KCL0hYGpZivRxRHblA3fFYWn926gQWsEpEq2jMihL1tlaV033i2u54 IaM3UprY2/pDwSI910OB2b0H6VOw9ZQ8vsbfq8Q0SqNxMiJcx/0ovwAUvoUfkuAi3rYR AIFcW1s2RUG0/Nh5QbLYRQoAS17PHIPQisa0h2yjRTKz9+epXlN8fRF/yekbshVJ27l2 rDbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=ngxI5hT9; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=PgNNE8PX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id f20-20020a637554000000b005776040b2a6si14395043pgn.187.2023.09.26.18.38.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 18:38:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=ngxI5hT9; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=PgNNE8PX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 19B9D80254E6; Tue, 26 Sep 2023 09:06:59 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235132AbjIZQGq (ORCPT + 99 others); Tue, 26 Sep 2023 12:06:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50712 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233451AbjIZQGp (ORCPT ); Tue, 26 Sep 2023 12:06:45 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA5C310A for ; Tue, 26 Sep 2023 09:06:37 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1695744390; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GZBZ0e5+Bkgdgf988Ah3z6IPgN+5AIZaHT83aY7rkg4=; b=ngxI5hT9cnVfL2fZfo1OLXiEaem7mpFJ40QWHCUz3q4miCE20RY5yyIuHA7wJAX2+R3w14 9xQ1+ZY6iuKZJ10sGey4fWxIuaoiGyd6rBTHxdYv8sMhUElTSOmYy68aF1YPtIAy/DhWGy h4NcZU/wsLOKeMxqR/EldV7zpFkyLVpGkSpYsNMS7O9KGuRqWVY6tMoTU67TcbpHhRwwuR IVsEGGQJg+5QHCPztTWhJZO/FLa/pNsH72/AIh2RPrXjiuFyC8az5Q5qmrNIpUwkZFgm/I s0ToeqMwelCGDHKlOqqPBo4IzQfUIT8ipF0QygZWYWRX4Rm9537MzLVjjlDPkw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1695744390; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GZBZ0e5+Bkgdgf988Ah3z6IPgN+5AIZaHT83aY7rkg4=; b=PgNNE8PXx/UT3eydhsqc9VUSLkhJ4yEG2supI0jNuHXCT0exy7IcxjUjADs3HMPe+miUrJ B6MenI7gTR8ou1Dw== To: Borislav Petkov Cc: LKML , x86@kernel.org, "Chang S. Bae" , Arjan van de Ven , Nikolay Borisov Subject: Re: [patch V3 21/30] x86/microcode: Add per CPU result state In-Reply-To: <20230924062934.GLZQ/XThoM7jsrjmrt@fat_crate.local> References: <20230912065249.695681286@linutronix.de> <20230912065502.082789879@linutronix.de> <20230924062934.GLZQ/XThoM7jsrjmrt@fat_crate.local> Date: Tue, 26 Sep 2023 11:09:01 +0200 Message-ID: <87sf71fgia.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=0.3 required=5.0 tests=DATE_IN_PAST_06_12,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 26 Sep 2023 09:06:59 -0700 (PDT) On Sun, Sep 24 2023 at 08:29, Borislav Petkov wrote: > On Tue, Sep 12, 2023 at 09:58:16AM +0200, Thomas Gleixner wrote: >> +struct ucode_ctrl { > > microcode_ctrl > > I know "ucode" is shorter but we already call everything new-er > "microcode_" and this'll cause confusion. That starts to get silly. The struct is used only in the microcode realm and nothing which is globally visible. ucode is a pretty obvious and established shortcut. But so what.... >> + enum ucode_state result; >> +}; >> + >> +static DEFINE_PER_CPU(struct ucode_ctrl, ucode_ctrl); > > You could do > > static DEFINE_PER_CPU(struct microcode_ctrl, ucode_ctrl); > > so that the naming is different too. And that solves what? >> static atomic_t late_cpus_in, late_cpus_out; >> >> static bool wait_for_cpus(atomic_t *cnt) >> @@ -344,23 +349,19 @@ static bool wait_for_cpus(atomic_t *cnt) >> return false; >> } >> >> -/* >> - * Returns: >> - * < 0 - on error >> - * 0 - success (no update done or microcode was updated) >> - */ >> -static int __reload_late(void *info) >> +static int ucode_load_cpus_stopped(void *unused) > > No need for "ucode_" prefixes to static functions. What's the problem with that prefix? The function name clearly says what this is doing. >> { >> int cpu = smp_processor_id(); >> - enum ucode_state err; >> - int ret = 0; >> + enum ucode_state ret; >> >> /* >> * Wait for all CPUs to arrive. A load will not be attempted unless all >> * CPUs show up. >> * */ >> - if (!wait_for_cpus(&late_cpus_in)) >> - return -1; >> + if (!wait_for_cpus(&late_cpus_in)) { >> + this_cpu_write(ucode_ctrl.result, UCODE_TIMEOUT); >> + return 0; > > So the only value this function returns is 0 now. > stop_machine_cpuslocked() still does pay attention at ret so I guess it > should return non-null/negative on error or so? Nope, because stop_machine_cpuslocked() does not usefully accumulate results from all involved CPUs. But it can return errors related to the invocation itself, which is a completely different story. That's why ucode_ctrl.result is per CPU and has to be evaluated separately. >> - ret = stop_machine_cpuslocked(__reload_late, NULL, cpu_online_mask); >> + stop_machine_cpuslocked(ucode_load_cpus_stopped, NULL, cpu_online_mask); >> + >> + /* Analyze the results */ >> + for_each_cpu_and(cpu, cpu_present_mask, &cpus_booted_once_mask) { >> + switch (per_cpu(ucode_ctrl.result, cpu)) { >> + case UCODE_UPDATED: updated++; break; >> + case UCODE_TIMEOUT: timedout++; break; >> + case UCODE_OK: siblings++; break; >> + default: failed++; break; >> + } > > Align vertically. Align what? >> + } >> >> if (microcode_ops->finalize_late_load) >> - microcode_ops->finalize_late_load(ret); >> + microcode_ops->finalize_late_load(!updated); >> >> - if (!ret) { >> - pr_info("Reload succeeded, microcode revision: 0x%x -> 0x%x\n", >> - old, boot_cpu_data.microcode); >> - microcode_check(&prev_info); >> - add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK); >> - } else { >> - pr_info("Reload failed, current microcode revision: 0x%x\n", >> - boot_cpu_data.microcode); >> + if (!updated) { >> + /* Nothing changed. */ >> + if (!failed && !timedout) >> + return 0; >> + pr_err("Microcode update failed: %u CPUs failed %u CPUs timed out\n", >> + failed, timedout); >> + return -EIO; >> } >> - return ret; >> + >> + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK); >> + pr_info("Microcode load: updated on %u primary CPUs with %u siblings\n", updated, siblings); >> + if (failed || timedout) { >> + pr_err("Microcode load incomplete. %u CPUs timed out or failed\n", >> + num_online_cpus() - (updated + siblings)); >> + } >> + pr_info("Microcode revision: 0x%x -> 0x%x\n", old_rev, boot_cpu_data.microcode); > > You don't need "Microcode" in those strings - the pr_info has already > "microcode:" as prefix. True. >> @@ -448,9 +463,12 @@ static int microcode_reload_late(void) >> * behaviour is undefined. The default play_dead() implementation on >> * modern CPUs is using MWAIT, which is also not guaranteed to be safe >> * against a microcode update which affects MWAIT. >> + * >> + * 2) Initialize the per CPU control structure >> */ >> -static bool ensure_cpus_are_online(void) >> +static bool ucode_setup_cpus(void) > > s/ucode_// and setup_cpus() then tells what?