* [GIT PULL] x86/microcode for 6.7 @ 2023-11-03 11:06 Borislav Petkov 2023-11-04 19:01 ` pr-tracker-bot 2023-11-11 22:19 ` Linus Torvalds 0 siblings, 2 replies; 7+ messages in thread From: Borislav Petkov @ 2023-11-03 11:06 UTC (permalink / raw) To: Linus Torvalds; +Cc: x86-ml, lkml Hi Linus, I believe this is the last tip branch from the lineup this merge window. It has a lot of nice things, it has been tested on everything we have access to so it should be good. There's a trivial merge conflict with your current tree (8f6f76a6a29f) which I'm pasting at the end of this mail, just in case. Please pull, thx. --- The following changes since commit 58720809f52779dc0f08e53e54b014209d13eebb: Linux 6.6-rc6 (2023-10-15 13:34:39 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86_microcode_for_v6.7_rc1 for you to fetch changes up to cf5ab01c87030a085e211a0a327535932ec6f719: x86/microcode/intel: Add a minimum required revision for late loading (2023-10-24 15:05:55 +0200) ---------------------------------------------------------------- Major microcode loader restructuring, cleanup and improvements by Thomas Gleixner: - Restructure the code needed for it and add a temporary initrd mapping on 32-bit so that the loader can access the microcode blobs. This in itself is a preparation for the next major improvement: - Do not load microcode on 32-bit before paging has been enabled. Handling this has caused an endless stream of headaches, issues, ugly code and unnecessary hacks in the past. And there really wasn't any sensible reason to do that in the first place. So switch the 32-bit loading to happen after paging has been enabled and turn the loader code "real purrty" again - Drop mixed microcode steppings loading on Intel - there, a single patch loaded on the whole system is sufficient - Rework late loading to track which CPUs have updated microcode successfully and which haven't, act accordingly - Move late microcode loading on Intel in NMI context in order to guarantee concurrent loading on all threads - Make the late loading CPU-hotplug-safe and have the offlined threads be woken up for the purpose of the update - Add support for a minimum revision which determines whether late microcode loading is safe on a machine and the microcode does not change software visible features which the machine cannot use anyway since feature detection has happened already. Roughly, the minimum revision is the smallest revision number which must be loaded currently on the system so that late updates can be allowed - Other nice leanups, fixess, etc all over the place ---------------------------------------------------------------- Ashok Raj (2): x86/microcode/intel: Rip out mixed stepping support for Intel CPUs x86/microcode/intel: Add a minimum required revision for late loading Paolo Bonzini (1): x86/microcode/amd: Fix snprintf() format string warning in W=1 build Thomas Gleixner (37): x86/boot/32: Disable stackprotector and tracing for mk_early_pgtbl_32() x86/boot: Use __pa_nodebug() in mk_early_pgtbl_32() x86/boot/32: De-uglify the 2/3 level paging difference in mk_early_pgtbl_32() x86/boot/32: Restructure mk_early_pgtbl_32() x86/microcode: Provide CONFIG_MICROCODE_INITRD32 x86/boot/32: Temporarily map initrd for microcode loading x86/microcode/32: Move early loading after paging enable x86/microcode/intel: Simplify scan_microcode() x86/microcode/intel: Simplify and rename generic_load_microcode() x86/microcode/intel: Cleanup code further x86/microcode/intel: Simplify early loading x86/microcode/intel: Save the microcode only after a successful late-load x86/microcode/intel: Switch to kvmalloc() x86/microcode/intel: Unify microcode apply() functions x86/microcode/intel: Rework intel_cpu_collect_info() x86/microcode/intel: Reuse intel_cpu_collect_info() x86/microcode/intel: Rework intel_find_matching_signature() x86/microcode: Remove pointless apply() invocation x86/microcode/amd: Use correct per CPU ucode_cpu_info x86/microcode/amd: Cache builtin microcode too x86/microcode/amd: Cache builtin/initrd microcode early x86/microcode/amd: Use cached microcode for AP load x86/microcode: Mop up early loading leftovers x86/microcode: Get rid of the schedule work indirection x86/microcode: Clean up mc_cpu_down_prep() x86/microcode: Handle "nosmt" correctly x86/microcode: Clarify the late load logic x86/microcode: Sanitize __wait_for_cpus() x86/microcode: Add per CPU result state x86/microcode: Add per CPU control field x86/microcode: Provide new control functions x86/microcode: Replace the all-in-one rendevous handler x86/microcode: Rendezvous and load in NMI x86/microcode: Protect against instrumentation x86/apic: Provide apic_force_nmi_on_cpu() x86/microcode: Handle "offline" CPUs correctly x86/microcode: Prepare for minimal revision check Documentation/admin-guide/kernel-parameters.txt | 5 + arch/x86/Kconfig | 29 +- arch/x86/include/asm/apic.h | 5 +- arch/x86/include/asm/cpu.h | 20 +- arch/x86/include/asm/microcode.h | 21 +- arch/x86/include/asm/setup.h | 1 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/apic/apic_flat_64.c | 2 + arch/x86/kernel/apic/ipi.c | 8 + arch/x86/kernel/apic/x2apic_cluster.c | 1 + arch/x86/kernel/apic/x2apic_phys.c | 1 + arch/x86/kernel/cpu/common.c | 12 - arch/x86/kernel/cpu/microcode/amd.c | 157 +++--- arch/x86/kernel/cpu/microcode/core.c | 670 ++++++++++++++--------- arch/x86/kernel/cpu/microcode/intel.c | 688 ++++++++---------------- arch/x86/kernel/cpu/microcode/internal.h | 35 +- arch/x86/kernel/head32.c | 120 +++-- arch/x86/kernel/head_32.S | 10 - arch/x86/kernel/nmi.c | 9 +- arch/x86/kernel/smpboot.c | 12 +- drivers/platform/x86/intel/ifs/load.c | 8 +- 21 files changed, 905 insertions(+), 910 deletions(-) --- merge conflict resolve: diff --cc arch/x86/include/asm/apic.h index b0d192f613b7,17f2f28a495e..d21f48f1c242 --- a/arch/x86/include/asm/apic.h +++ b/arch/x86/include/asm/apic.h @@@ -528,12 -539,15 +529,14 @@@ extern int default_apic_id_valid(u32 ap extern u32 apic_default_calc_apicid(unsigned int cpu); extern u32 apic_flat_calc_apicid(unsigned int cpu); -extern bool default_check_apicid_used(physid_mask_t *map, int apicid); extern void default_ioapic_phys_id_map(physid_mask_t *phys_map, physid_mask_t *retmap); -extern int default_cpu_present_to_apicid(int mps_cpu); +extern u32 default_cpu_present_to_apicid(int mps_cpu); + void apic_send_nmi_to_offline_cpu(unsigned int cpu); + #else /* CONFIG_X86_LOCAL_APIC */ -static inline unsigned int read_apic_id(void) { return 0; } +static inline u32 read_apic_id(void) { return 0; } #endif /* !CONFIG_X86_LOCAL_APIC */ -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] x86/microcode for 6.7 2023-11-03 11:06 [GIT PULL] x86/microcode for 6.7 Borislav Petkov @ 2023-11-04 19:01 ` pr-tracker-bot 2023-11-11 22:19 ` Linus Torvalds 1 sibling, 0 replies; 7+ messages in thread From: pr-tracker-bot @ 2023-11-04 19:01 UTC (permalink / raw) To: Borislav Petkov; +Cc: Linus Torvalds, x86-ml, lkml The pull request you sent on Fri, 3 Nov 2023 12:06:00 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86_microcode_for_v6.7_rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0a23fb262d17f587c9bb1e6cc83ad4158b21f16e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] x86/microcode for 6.7 2023-11-03 11:06 [GIT PULL] x86/microcode for 6.7 Borislav Petkov 2023-11-04 19:01 ` pr-tracker-bot @ 2023-11-11 22:19 ` Linus Torvalds 2023-11-11 22:35 ` Borislav Petkov 1 sibling, 1 reply; 7+ messages in thread From: Linus Torvalds @ 2023-11-11 22:19 UTC (permalink / raw) To: Borislav Petkov, Thomas Gleixner; +Cc: x86-ml, lkml On Fri, 3 Nov 2023 at 04:06, Borislav Petkov <bp@alien8.de> wrote: > > I believe this is the last tip branch from the lineup this merge window. > It has a lot of nice things, it has been tested on everything we have > access to so it should be good. Well, I only now looked more closely at dmesg (because I was testing an entirely unrelated patch of mine), and I see this: smpboot: x86: Booting SMP configuration: .... node #0, CPUs: #1 #2 #3 #4 #5 microcode: CPU4: new patch_level=0x0830107a #6 microcode: CPU5: new patch_level=0x0830107a #7 microcode: CPU1: new patch_level=0x0830107a microcode: CPU2: new patch_level=0x0830107a microcode: CPU3: new patch_level=0x0830107a microcode: CPU6: new patch_level=0x0830107a #8 ... #63 microcode: CPU62: new patch_level=0x0830107a microcode: CPU63: new patch_level=0x0830107a smp: Brought up 1 node, 64 CPUs ... mip6: Mobile IPv6 NET: Registered PF_PACKET protocol family microcode: microcode updated early to new patch_level=0x0830107a microcode: CPU0: patch_level=0x0830107a microcode: CPU1: patch_level=0x0830107a microcode: CPU2: patch_level=0x0830107a .. microcode: CPU62: patch_level=0x0830107a microcode: CPU63: patch_level=0x0830107a microcode: Microcode Update Driver: v2.2. which is really quite ugly and entirely pointless. I *really* don't want to be told 129 times that my microcode has been updated to the same level. And yes, it's "only" 129 times, because while there are two of those microcode update lines: microcode: microcode updated early to new patch_level=0x0830107a microcode: Microcode Update Driver: v2.2. CPU#0 is only mentioned once, while CPU's 1..63 all get two mentions (once for the bringup, once fro the summary). Can we please stop doing this insanity? It's not helpful. Linus ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] x86/microcode for 6.7 2023-11-11 22:19 ` Linus Torvalds @ 2023-11-11 22:35 ` Borislav Petkov 2023-11-12 12:23 ` Borislav Petkov 0 siblings, 1 reply; 7+ messages in thread From: Borislav Petkov @ 2023-11-11 22:35 UTC (permalink / raw) To: Linus Torvalds; +Cc: Thomas Gleixner, x86-ml, lkml On Sat, Nov 11, 2023 at 02:19:00PM -0800, Linus Torvalds wrote: > Can we please stop doing this insanity? It's not helpful. Yeah, it is on the todo list. I'll take a look next week. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] x86/microcode for 6.7 2023-11-11 22:35 ` Borislav Petkov @ 2023-11-12 12:23 ` Borislav Petkov 2023-11-12 19:41 ` Linus Torvalds 0 siblings, 1 reply; 7+ messages in thread From: Borislav Petkov @ 2023-11-12 12:23 UTC (permalink / raw) To: Linus Torvalds; +Cc: Thomas Gleixner, x86-ml, lkml On Sat, Nov 11, 2023 at 11:35:49PM +0100, Borislav Petkov wrote: > Yeah, it is on the todo list. I'll take a look next week. Yeah, so I think something along the lines of the below. This has been bothering me for a while now too but I wanted to get tglx's stuff taken care of first. Basically, we can simply report the previous and the potentially new revision only once on driver load. Even if the AMD side theoretically still supports mixed silicon steppings, there's no need to do per-thread reporting as that info is already in /proc/cpuinfo for those who are really interested. So this below should be good enough. I'll test it some more next week and split it. diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c index 9373ec01c5ae..7213dea21a15 100644 --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -104,7 +104,7 @@ struct cont_desc { size_t size; }; -static u32 ucode_new_rev; +static u32 early_new_rev, old_rev; /* * Microcode patch container file is prepended to the initrd in cpio @@ -447,7 +447,6 @@ static bool early_apply_microcode(u32 cpuid_1_eax, void *ucode, size_t size) struct cont_desc desc = { 0 }; struct microcode_amd *mc; bool ret = false; - u32 rev, dummy; desc.cpuid_1_eax = cpuid_1_eax; @@ -457,22 +456,15 @@ static bool early_apply_microcode(u32 cpuid_1_eax, void *ucode, size_t size) if (!mc) return ret; - native_rdmsr(MSR_AMD64_PATCH_LEVEL, rev, dummy); - /* * Allow application of the same revision to pick up SMT-specific * changes even if the revision of the other SMT thread is already * up-to-date. */ - if (rev > mc->hdr.patch_id) + if (old_rev > mc->hdr.patch_id) return ret; - if (!__apply_microcode_amd(mc)) { - ucode_new_rev = mc->hdr.patch_id; - ret = true; - } - - return ret; + return !__apply_microcode_amd(mc); } static bool get_builtin_microcode(struct cpio_data *cp, unsigned int family) @@ -509,6 +501,9 @@ static void __init find_blobs_in_containers(unsigned int cpuid_1_eax, struct cpi void __init load_ucode_amd_bsp(unsigned int cpuid_1_eax) { struct cpio_data cp = { }; + u32 dummy; + + native_rdmsr(MSR_AMD64_PATCH_LEVEL, old_rev, dummy); /* Needed in load_microcode_amd() */ ucode_cpu_info[0].cpu_sig.sig = cpuid_1_eax; @@ -517,7 +512,8 @@ void __init load_ucode_amd_bsp(unsigned int cpuid_1_eax) if (!(cp.data && cp.size)) return; - early_apply_microcode(cpuid_1_eax, cp.data, cp.size); + if (early_apply_microcode(cpuid_1_eax, cp.data, cp.size)) + native_rdmsr(MSR_AMD64_PATCH_LEVEL, early_new_rev, dummy); } static enum ucode_state load_microcode_amd(u8 family, const u8 *data, size_t size); @@ -626,8 +622,8 @@ void reload_ucode_amd(unsigned int cpu) if (rev < mc->hdr.patch_id) { if (!__apply_microcode_amd(mc)) { - ucode_new_rev = mc->hdr.patch_id; - pr_info("reload patch_level=0x%08x\n", ucode_new_rev); + early_new_rev = mc->hdr.patch_id; + pr_info_once("reload revision: 0x%08x\n", early_new_rev); } } } @@ -649,8 +645,6 @@ static int collect_cpu_info_amd(int cpu, struct cpu_signature *csig) if (p && (p->patch_id == csig->rev)) uci->mc = p->data; - pr_info("CPU%d: patch_level=0x%08x\n", cpu, csig->rev); - return 0; } @@ -691,8 +685,6 @@ static enum ucode_state apply_microcode_amd(int cpu) rev = mc_amd->hdr.patch_id; ret = UCODE_UPDATED; - pr_info("CPU%d: new patch_level=0x%08x\n", cpu, rev); - out: uci->cpu_sig.rev = rev; c->microcode = rev; @@ -936,9 +928,11 @@ struct microcode_ops * __init init_amd_microcode(void) return NULL; } - if (ucode_new_rev) - pr_info_once("microcode updated early to new patch_level=0x%08x\n", - ucode_new_rev); + pr_info_once("Current revision: 0x%08x\n", (early_new_rev ?: old_rev)); + + if (early_new_rev) + pr_info_once("Updated early from: 0x%08x\n", + old_rev); return µcode_amd_ops; } diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c index 666d25bbc5ad..b4be3a2c79df 100644 --- a/arch/x86/kernel/cpu/microcode/core.c +++ b/arch/x86/kernel/cpu/microcode/core.c @@ -41,8 +41,6 @@ #include "internal.h" -#define DRIVER_VERSION "2.2" - static struct microcode_ops *microcode_ops; bool dis_ucode_ldr = true; @@ -846,8 +844,6 @@ static int __init microcode_init(void) cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/microcode:online", mc_cpu_online, mc_cpu_down_prep); - pr_info("Microcode Update Driver: v%s.", DRIVER_VERSION); - return 0; out_pdev: -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [GIT PULL] x86/microcode for 6.7 2023-11-12 12:23 ` Borislav Petkov @ 2023-11-12 19:41 ` Linus Torvalds 2023-11-12 19:56 ` Borislav Petkov 0 siblings, 1 reply; 7+ messages in thread From: Linus Torvalds @ 2023-11-12 19:41 UTC (permalink / raw) To: Borislav Petkov; +Cc: Thomas Gleixner, x86-ml, lkml On Sun, 12 Nov 2023 at 04:23, Borislav Petkov <bp@alien8.de> wrote: > > Yeah, so I think something along the lines of the below. I can verify that this makes my boot logs look sane again. I'm not applying this directly, and will let you do the final version in the tip tree (split into two?), but thought I'd at least ack that it works for me. Linus ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [GIT PULL] x86/microcode for 6.7 2023-11-12 19:41 ` Linus Torvalds @ 2023-11-12 19:56 ` Borislav Petkov 0 siblings, 0 replies; 7+ messages in thread From: Borislav Petkov @ 2023-11-12 19:56 UTC (permalink / raw) To: Linus Torvalds; +Cc: Thomas Gleixner, x86-ml, lkml On Sun, Nov 12, 2023 at 11:41:53AM -0800, Linus Torvalds wrote: > I can verify that this makes my boot logs look sane again. Cool. > I'm not applying this directly, and will let you do the final version > in the tip tree (split into two?), but thought I'd at least ack that > it works for me. Thanks! So I was looking at the Intel side earlier and it doesn't dump the revision it had *before* the early loading. And people have asked for that functionality - to be able to dump the revision which got overwritten. So I'll try to pull up that code and use for both drivers, test on all machines and send out a proper set. And yap, you'll get that eventually through tip, in time for 6.7. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-11-12 19:57 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-11-03 11:06 [GIT PULL] x86/microcode for 6.7 Borislav Petkov 2023-11-04 19:01 ` pr-tracker-bot 2023-11-11 22:19 ` Linus Torvalds 2023-11-11 22:35 ` Borislav Petkov 2023-11-12 12:23 ` Borislav Petkov 2023-11-12 19:41 ` Linus Torvalds 2023-11-12 19:56 ` Borislav Petkov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.