Hi back in the December of 2016 there was commit "1c52d859cb2d417e7216d3e56bb7fea88444cec9"
witch was followed shortly by "c198b121b1a1d7a7171770c634cd49191bac4477"
Unfortunately only the first commit was later included in long-term kernel branches such as 4.4 and 4.9 witch left some of microcode functionality broken on 32 bit systems
I guess it should be easily fixed by including "c198b121b1a1d7a7171770c634cd49191bac4477" in those branches
On Sat, Mar 30, 2019 at 06:13:16PM +0200, Evalds Iodzevics wrote:
Hi back in the December of 2016 there was commit "1c52d859cb2d417e7216d3e56bb7fea88444cec9"
witch was followed shortly by "c198b121b1a1d7a7171770c634cd49191bac4477"
Unfortunately only the first commit was later included in long-term kernel branches such as 4.4 and 4.9 witch left some of microcode functionality broken on 32 bit systems
I guess it should be easily fixed by including "c198b121b1a1d7a7171770c634cd49191bac4477" in those branches
Now queued up, thanks!
greg k-h
On Mon, Apr 01, 2019 at 06:06:29PM +0200, Greg KH wrote:
On Sat, Mar 30, 2019 at 06:13:16PM +0200, Evalds Iodzevics wrote:
Hi back in the December of 2016 there was commit "1c52d859cb2d417e7216d3e56bb7fea88444cec9"
witch was followed shortly by "c198b121b1a1d7a7171770c634cd49191bac4477"
Unfortunately only the first commit was later included in long-term kernel branches such as 4.4 and 4.9 witch left some of microcode functionality broken on 32 bit systems
I guess it should be easily fixed by including "c198b121b1a1d7a7171770c634cd49191bac4477" in those branches
Now queued up, thanks!
Hm, no, it causes a bunch of build warnings that look like things are about to break: arch/x86/kernel/alternative.o: warning: objtool: do_sync_core()+0x1b: unsupported instruction in callable function arch/x86/kernel/alternative.o: warning: objtool: text_poke_early()+0x83: unsupported instruction in callable function arch/x86/kernel/alternative.o: warning: objtool: apply_alternatives()+0x366: unsupported instruction in callable function arch/x86/kernel/alternative.o: warning: objtool: text_poke()+0x196: unsupported instruction in callable function
So I'm going to drop this patch from both trees now. Can you provide a working backported version, or find what else needs to be applied as well for this patch?
thanks,
greg k-h
Hi, sorry for super long delay i was a little bit busy but i finally got time to work this out in full. This applies to 4.4 and 4.9.
Intel requires CPUID eax=1 for microcode operations, microcode routines use sync_core() for this. Back in December of 2016 Andy Lutomirski submitted few patches https://lore.kernel.org/lkml/cover.1481307769.git.luto@kernel.org/
Second patch does not apply to 4.4 and 4.9 as it is revert
Unfortunately only the first one got backported to 4.4 and 4.9 and broke microcode early loading on 32 bit platforms because it always jumps past cpuid in sync_core() as data structure boot_cpu_data are not populated so early in code.
Thanks to Your recent backport of 4167709bbf826512a52ebd6aafda2be104adaec9 the only place that uses sync_core() is arch/x86/include/microcode_intel.h it should use native_cpuid_eax(1) as in original Boris submitt. To make this work we should apply 5dedade6dfa243c130b85d1e4daba6f027805033 witch defines native_cpuid_eax and others.
As for c198b121b1a1d7a7171770c634cd49191bac4477 i think it is a good idea to include this as sync_core in present state behaves differently depending on call time, those compiler warnings can be ignored, on older compiler they are not generated and this compiles fine. I tested it on GCC 5.5
On Mon, Apr 1, 2019 at 7:59 PM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 01, 2019 at 06:06:29PM +0200, Greg KH wrote:
On Sat, Mar 30, 2019 at 06:13:16PM +0200, Evalds Iodzevics wrote:
Hi back in the December of 2016 there was commit "1c52d859cb2d417e7216d3e56bb7fea88444cec9"
witch was followed shortly by "c198b121b1a1d7a7171770c634cd49191bac4477"
Unfortunately only the first commit was later included in long-term kernel branches such as 4.4 and 4.9 witch left some of microcode functionality broken on 32 bit systems
I guess it should be easily fixed by including "c198b121b1a1d7a7171770c634cd49191bac4477" in those branches
Now queued up, thanks!
Hm, no, it causes a bunch of build warnings that look like things are about to break: arch/x86/kernel/alternative.o: warning: objtool: do_sync_core()+0x1b: unsupported instruction in callable function arch/x86/kernel/alternative.o: warning: objtool: text_poke_early()+0x83: unsupported instruction in callable function arch/x86/kernel/alternative.o: warning: objtool: apply_alternatives()+0x366: unsupported instruction in callable function arch/x86/kernel/alternative.o: warning: objtool: text_poke()+0x196: unsupported instruction in callable function
So I'm going to drop this patch from both trees now. Can you provide a working backported version, or find what else needs to be applied as well for this patch?
thanks,
greg k-h
On Sun, May 26, 2019 at 10:32:29AM +0300, Evalds Iodzevics wrote:
Hi, sorry for super long delay i was a little bit busy but i finally got time to work this out in full. This applies to 4.4 and 4.9.
Intel requires CPUID eax=1 for microcode operations, microcode routines use sync_core() for this. Back in December of 2016 Andy Lutomirski submitted few patches https://lore.kernel.org/lkml/cover.1481307769.git.luto@kernel.org/
Second patch does not apply to 4.4 and 4.9 as it is revert
Unfortunately only the first one got backported to 4.4 and 4.9 and broke microcode early loading on 32 bit platforms because it always jumps past cpuid in sync_core() as data structure boot_cpu_data are not populated so early in code.
Thanks to Your recent backport of 4167709bbf826512a52ebd6aafda2be104adaec9 the only place that uses sync_core() is arch/x86/include/microcode_intel.h it should use native_cpuid_eax(1) as in original Boris submitt. To make this work we should apply 5dedade6dfa243c130b85d1e4daba6f027805033 witch defines native_cpuid_eax and others.
As for c198b121b1a1d7a7171770c634cd49191bac4477 i think it is a good idea to include this as sync_core in present state behaves differently depending on call time, those compiler warnings can be ignored, on older compiler they are not generated and this compiles fine. I tested it on GCC 5.5
Can you submit the proper patches backported as a series so that I can queue them up correctly?
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org