linux: Use proper patches from git instead of manually modifying them.

0001-x86-microcode-Update-BSPs-microcode-on-resume.patch

@@ -0,0 +1,48 @@
+From fb86b97300d930b57471068720c52bfa8622eab7 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Tue, 18 Nov 2014 10:46:57 +0100
+Subject: [PATCH] x86, microcode: Update BSPs microcode on resume
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+In the situation when we apply early microcode but do *not* apply late
+microcode, we fail to update the BSP's microcode on resume because we
+haven't initialized the uci->mc microcode pointer. So, in order to
+alleviate that, we go and dig out the stashed microcode patch during
+early boot. It is basically the same thing that is done on the APs early
+during boot so do that too here.
+
+Tested-by: alex.schnaidt@gmail.com
+Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
+Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
+Cc: Fenghua Yu <fenghua.yu@intel.com>
+Cc: <stable@vger.kernel.org> # v3.9
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+---
+ arch/x86/kernel/cpu/microcode/core.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
+index dd9d619..2ce9051 100644
+--- a/arch/x86/kernel/cpu/microcode/core.c
++++ b/arch/x86/kernel/cpu/microcode/core.c
+@@ -465,6 +465,14 @@ static void mc_bp_resume(void)
+ 
+ 	if (uci->valid && uci->mc)
+ 		microcode_ops->apply_microcode(cpu);
++	else if (!uci->mc)
++		/*
++		 * We might resume and not have applied late microcode but still
++		 * have a newer patch stashed from the early loader. We don't
++		 * have it in uci->mc so we have to load it the same way we're
++		 * applying patches early on the APs.
++		 */
++		load_ucode_ap();
+ }
+ 
+ static struct syscore_ops mc_syscore_ops = {
+-- 
+2.1.3
+

0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch

@@ -0,0 +1,55 @@
+From 02ecc41abcea4ff9291d548f6f846b29b354ddd2 Mon Sep 17 00:00:00 2001
+From: Borislav Petkov <bp@suse.de>
+Date: Sun, 30 Nov 2014 14:26:39 +0100
+Subject: [PATCH] x86, microcode: Limit the microcode reloading to 64-bit for
+ now
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+First, there was this: https://bugzilla.kernel.org/show_bug.cgi?id=88001
+
+The problem there was that microcode patches are not being reapplied
+after suspend-to-ram. It was important to reapply them, though, because
+of for example Haswell's TSX erratum which disabled TSX instructions
+with a microcode patch.
+
+A simple fix was fb86b97300d9 ("x86, microcode: Update BSPs microcode
+on resume") but, as it is often the case, simple fixes are too
+simple. This one causes 32-bit resume to fail:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=88391
+
+Properly fixing this would require more involved changes for which it
+is too late now, right before the merge window. Thus, limit this to
+64-bit only temporarily.
+
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Link: http://lkml.kernel.org/r/1417353999-32236-1-git-send-email-bp@alien8.de
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+---
+ arch/x86/kernel/cpu/microcode/core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
+index 2ce9051..08fe6e8 100644
+--- a/arch/x86/kernel/cpu/microcode/core.c
++++ b/arch/x86/kernel/cpu/microcode/core.c
+@@ -465,6 +465,7 @@ static void mc_bp_resume(void)
+ 
+ 	if (uci->valid && uci->mc)
+ 		microcode_ops->apply_microcode(cpu);
++#ifdef CONFIG_X86_64
+ 	else if (!uci->mc)
+ 		/*
+ 		 * We might resume and not have applied late microcode but still
+@@ -473,6 +474,7 @@ static void mc_bp_resume(void)
+ 		 * applying patches early on the APs.
+ 		 */
+ 		load_ucode_ap();
++#endif
+ }
+ 
+ static struct syscore_ops mc_syscore_ops = {
+-- 
+2.1.3
+

PKGBUILD

@@ -18,7 +18,8 @@ source=("https://www.kernel.org/pub/linux/kernel/v3.x/${_srcname}.tar.xz"
         # standard config files for mkinitcpio ramdisk
         'linux.preset'
         'change-default-console-loglevel.patch'
-        'fix_CPU0_microcode_on_resume.patch'
+        '0001-x86-microcode-Update-BSPs-microcode-on-resume.patch'
+        '0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch'
         )
 sha256sums=('f5153ec93c5fcd41b247950e6a9bcbc63fa87beafd112c133a622439a0f76251'
             '435a8a3c4faad53b5f9f0349629358a7d273e6ca94ffeb226c1d360787cc7278'
@@ -26,7 +27,8 @@ sha256sums=('f5153ec93c5fcd41b247950e6a9bcbc63fa87beafd112c133a622439a0f76251'
             '66fc95823d3c99167532f37c07e9582d305961103997fcc61cfc7f6a86b34130'
             'f0d90e756f14533ee67afda280500511a62465b4f76adcc5effa95a40045179c'
             '1256b241cd477b265a3c2d64bdc19ffe3c9bbcee82ea3994c590c2c76e767d99'
-            'fa48f83498bbef85dbe4b39eb88f89aac4dd2591232a3f13ec029fc44b0f497a')
+            'fb120d3031886afd86a2054f551545898758b18f8bad1f6fee1c49e1ce23a760'
+            '529ffe2f52cba3ce8d7ab07bd85361d804d377464ee878ac085d6032336e4918')
 
 _kernelname=${pkgbase#linux}
 
@@ -46,7 +48,9 @@ prepare() {
 
   # Fix FS#42689
   # https://bugzilla.kernel.org/show_bug.cgi?id=88001
-  patch -p1 -i "${srcdir}/fix_CPU0_microcode_on_resume.patch"
+  #
+  patch -p1 -i "${srcdir}/0001-x86-microcode-Update-BSPs-microcode-on-resume.patch"
+  patch -p1 -i "${srcdir}/0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch"
 
   if [ "${CARCH}" = "x86_64" ]; then
     cat "${srcdir}/config.x86_64" > ./.config

fix_CPU0_microcode_on_resume.patch

@@ -1,92 +0,0 @@
-From fb86b97300d930b57471068720c52bfa8622eab7 Mon Sep 17 00:00:00 2001
-From: Borislav Petkov <bp@suse.de>
-Date: Tue, 18 Nov 2014 10:46:57 +0100
-Subject: x86, microcode: Update BSPs microcode on resume
-
-In the situation when we apply early microcode but do *not* apply late
-microcode, we fail to update the BSP's microcode on resume because we
-haven't initialized the uci->mc microcode pointer. So, in order to
-alleviate that, we go and dig out the stashed microcode patch during
-early boot. It is basically the same thing that is done on the APs early
-during boot so do that too here.
-
-Tested-by: alex.schnaidt@gmail.com
-Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
-Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
-Cc: Fenghua Yu <fenghua.yu@intel.com>
-Cc: <stable@vger.kernel.org> # v3.9
-Signed-off-by: Borislav Petkov <bp@suse.de>
-Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
-Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
-diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
-index dd9d619..2ce9051 100644
---- a/arch/x86/kernel/cpu/microcode/core.c
-+++ b/arch/x86/kernel/cpu/microcode/core.c
-@@ -465,6 +465,14 @@ static void mc_bp_resume(void)
- 
- 	if (uci->valid && uci->mc)
- 		microcode_ops->apply_microcode(cpu);
-+	else if (!uci->mc)
-+		/*
-+		 * We might resume and not have applied late microcode but still
-+		 * have a newer patch stashed from the early loader. We don't
-+		 * have it in uci->mc so we have to load it the same way we're
-+		 * applying patches early on the APs.
-+		 */
-+		load_ucode_ap();
- }
- 
- static struct syscore_ops mc_syscore_ops = {
--- 
-cgit v0.10.1
-
-From 02ecc41abcea4ff9291d548f6f846b29b354ddd2 Mon Sep 17 00:00:00 2001
-From: Borislav Petkov <bp@suse.de>
-Date: Sun, 30 Nov 2014 14:26:39 +0100
-Subject: x86, microcode: Limit the microcode reloading to 64-bit for now
-
-First, there was this: https://bugzilla.kernel.org/show_bug.cgi?id=88001
-
-The problem there was that microcode patches are not being reapplied
-after suspend-to-ram. It was important to reapply them, though, because
-of for example Haswell's TSX erratum which disabled TSX instructions
-with a microcode patch.
-
-A simple fix was fb86b97300d9 ("x86, microcode: Update BSPs microcode
-on resume") but, as it is often the case, simple fixes are too
-simple. This one causes 32-bit resume to fail:
-
-https://bugzilla.kernel.org/show_bug.cgi?id=88391
-
-Properly fixing this would require more involved changes for which it
-is too late now, right before the merge window. Thus, limit this to
-64-bit only temporarily.
-
-Signed-off-by: Borislav Petkov <bp@suse.de>
-Link: http://lkml.kernel.org/r/1417353999-32236-1-git-send-email-bp@alien8.de
-Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
-diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
-index 2ce9051..08fe6e8 100644
---- a/arch/x86/kernel/cpu/microcode/core.c
-+++ b/arch/x86/kernel/cpu/microcode/core.c
-@@ -465,6 +465,7 @@ static void mc_bp_resume(void)
- 
- 	if (uci->valid && uci->mc)
- 		microcode_ops->apply_microcode(cpu);
-+#ifdef CONFIG_X86_64
- 	else if (!uci->mc)
- 		/*
- 		 * We might resume and not have applied late microcode but still
-@@ -473,6 +474,7 @@ static void mc_bp_resume(void)
- 		 * applying patches early on the APs.
- 		 */
- 		load_ucode_ap();
-+#endif
- }
- 
- static struct syscore_ops mc_syscore_ops = {
--- 
-cgit v0.10.1
-