Request to port to 6.6.y : c809b0d0e52d ("x86/microcode/AMD: Flush patch buffer mapping after application")
Hello,
Below commit was ported to 6.12, but I would like to request porting to the 6.6 longterm branch we are currently using:
commit c809b0d0e52d01c30066367b2952c4c4186b1047 Author: Borislav Petkov (AMD) bp@alien8.de Date: 2024-11-19 12:21:33 +0100
x86/microcode/AMD: Flush patch buffer mapping after application [...]
The patch itself is small, but the consequence of not patching is large on affected systems (tens of seconds to minutes, of boot delay). See original discussion [1] for details.
The patch in master relies on a variable 'bsp_cpuid_1_eax' introduced in commit 94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the patch ID"), but porting that entire commit seems excessive, especially because there are several 'Fixes' commits for that one (e.g. 5343558a868e, d1744a4c975b, 1d81d85d1a19).
I think the simplest prerequisite change is (for Borislav Petkov to confirm):
diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c index bbd1dc38ea03..555fa76bd1f3 100644 --- a/arch/x86/kernel/cpu/microcode/amd.c +++ b/arch/x86/kernel/cpu/microcode/amd.c @@ -96,6 +97,8 @@ struct cont_desc {
static u32 ucode_new_rev;
+static u32 bsp_cpuid_1_eax __ro_after_init; + /* * Microcode patch container file is prepended to the initrd in cpio * format. See Documentation/arch/x86/microcode.rst @@ -551,6 +566,7 @@ static void apply_ucode_from_containers(unsigned int cpuid_1_eax)
void load_ucode_amd_early(unsigned int cpuid_1_eax) { + bsp_cpuid_1_eax = cpuid_1_eax; return apply_ucode_from_containers(cpuid_1_eax); }
Thanks, Thomas
[1] https://lore.kernel.org/lkml/ZyulbYuvrkshfsd2@antipodes/T/
On Tue, Dec 17, 2024 at 04:32:55PM +0100, Thomas De Schampheleire wrote:
Hello,
Below commit was ported to 6.12, but I would like to request porting to the 6.6 longterm branch we are currently using:
commit c809b0d0e52d01c30066367b2952c4c4186b1047 Author: Borislav Petkov (AMD) <bp@alien8.de> Date: 2024-11-19 12:21:33 +0100 x86/microcode/AMD: Flush patch buffer mapping after application [...]The patch itself is small, but the consequence of not patching is large on affected systems (tens of seconds to minutes, of boot delay). See original discussion [1] for details.
The patch in master relies on a variable 'bsp_cpuid_1_eax' introduced in commit 94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the patch ID"), but porting that entire commit seems excessive, especially because there are several 'Fixes' commits for that one (e.g. 5343558a868e, d1744a4c975b, 1d81d85d1a19).
I think the simplest prerequisite change is (for Borislav Petkov to confirm):
Please send a set of working, and tested, commits that you wish for us to commit, we can't cherry-pick stuff out of an email like this for obvious reasons :)
And whenever possible, yes, we do want to take the fixes that are in Linus's tree, otherwise maintaining the branch over time gets harder and harder. So just backport them all please.
thanks,
greg k-h
On Tue, Dec 17, 2024 at 04:53:43PM +0100, Greg KH wrote:
Please send a set of working, and tested, commits that you wish for us to commit, we can't cherry-pick stuff out of an email like this for obvious reasons :)
And whenever possible, yes, we do want to take the fixes that are in Linus's tree, otherwise maintaining the branch over time gets harder and harder. So just backport them all please.
Thanks Greg for your input, understood.
Borislav, are you open to preparing the required commits? While I can test the behavior of the main patch, I don't know enough about the prerequisite patches to handle patch submission.
Thanks, Thomas
On Wed, Dec 18, 2024 at 01:28:55PM +0100, Thomas De Schampheleire wrote:
On Tue, Dec 17, 2024 at 04:53:43PM +0100, Greg KH wrote:
Please send a set of working, and tested, commits that you wish for us to commit, we can't cherry-pick stuff out of an email like this for obvious reasons :)
And whenever possible, yes, we do want to take the fixes that are in Linus's tree, otherwise maintaining the branch over time gets harder and harder. So just backport them all please.
Thanks Greg for your input, understood.
Borislav, are you open to preparing the required commits?
Wait, why do you want these for the 6.6.y tree if you haven't even tested to see if they are required or work there? Why not just move to 6.12.y instead as you know that works.
thanks,
greg k-h
On Mon, Dec 23, 2024 at 01:33:17PM +0100, Greg KH wrote:
Wait, why do you want these for the 6.6.y tree if you haven't even tested to see if they are required or work there? Why not just move to 6.12.y instead as you know that works.
The original problem was reported by me on 6.6.y. I tested the patch provided by Borislav on 6.6.y. As mentioned, a small change is required to make it compile, but this is a nonfunctional change in the tested code path and so didn't influence test results. I can therefore say with certainty that the fix is required on 6.6.y .
In these discussions, I requested Borislav if the patch could also be submitted for 6.6.y, and made him aware that variable 'bsp_cpuid_1_eax' used in the patch does not yet exist in that branch. He replied [1]:
"That's fine - stable folks usually know what to pick up. If not, I'll provide backports."
I cannot currently move to 6.12 for these systems, this has other consequences and testing efforts.
Thanks, Thomas
[1] https://lore.kernel.org/lkml/20241119111728.GAZzxzyHj8U99cEHQ8@fat_crate.loc...
On Mon, Dec 23, 2024 at 02:23:48PM +0100, Thomas De Schampheleire wrote:
I cannot currently move to 6.12 for these systems, this has other consequences and testing efforts.
Why? Your testing efforts should be identical for a stable kernel update or a movement to a new kernel version. What is not working properly for you in 6.12.y?
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Thomas De Schampheleire