[opensuse-kernel] Status of microcode autoload ?
Hi: Is there any news or improvements on the Intel microcode autoload feature so we can get rid of init/systemd scripts that currently do a task that is better done with either the kernel or udev ? Thanks. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wednesday 23 November 2011 18:20:14 Cristian Rodríguez wrote:
Hi:
Is there any news or improvements on the Intel microcode autoload feature so we can get rid of init/systemd scripts that currently do a task that is better done with either the kernel or udev ? There is a tool to split up the microcode as provided by Intel into individual family-model-stepping specific files. http://pkgs.fedoraproject.org/repo/pkgs/microcode_ctl/intel-microcode2ucode....
I expect this should live in udev or in the kernel-firmware repo (at least the Intel microcode should be there if possible). But the code has no license described and quick googling didn't tell me whether it's already part of some mainline project. If it's clear where this should end up, I'd like to give it a test and integrate it if it works as expected. Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sun, Nov 27, 2011 at 23:34, Thomas Renninger
On Wednesday 23 November 2011 18:20:14 Cristian Rodríguez wrote:
Is there any news or improvements on the Intel microcode autoload feature so we can get rid of init/systemd scripts that currently do a task that is better done with either the kernel or udev ?
There is a tool to split up the microcode as provided by Intel into individual family-model-stepping specific files. http://pkgs.fedoraproject.org/repo/pkgs/microcode_ctl/intel-microcode2ucode....
I expect this should live in udev or in the kernel-firmware repo (at least the Intel microcode should be there if possible).
But the code has no license described and quick googling didn't tell me whether it's already part of some mainline project.
If it's clear where this should end up, I'd like to give it a test and integrate it if it works as expected.
Oh, right, licences. I just wrote it one night to get rid of this problem. :) If you need a license, add 'GPLv2 or later'. The tool should live in the package that ships the microcode. Ideally, someone asks Intel to just ship the files that way in the future, and the tool can go away. Kay -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 27/11/11 19:34, Thomas Renninger wrote:
On Wednesday 23 November 2011 18:20:14 Cristian Rodríguez wrote:
Hi:
Is there any news or improvements on the Intel microcode autoload feature so we can get rid of init/systemd scripts that currently do a task that is better done with either the kernel or udev ? There is a tool to split up the microcode as provided by Intel into individual family-model-stepping specific files. http://pkgs.fedoraproject.org/repo/pkgs/microcode_ctl/intel-microcode2ucode....
I expect this should live in udev or in the kernel-firmware repo (at least the Intel microcode should be there if possible).
Problem is that it needs to be loaded either very early, just after /dev creation or better in the initrd otherwise you will be booting init on a buggy CPU, to make matters worst, no changelog is provided to know what kind of bugs it fixes :-| -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sun, Nov 27, 2011 at 08:25:37PM -0300, Cristian Rodríguez wrote:
On 27/11/11 19:34, Thomas Renninger wrote:
On Wednesday 23 November 2011 18:20:14 Cristian Rodríguez wrote:
Hi:
Is there any news or improvements on the Intel microcode autoload feature so we can get rid of init/systemd scripts that currently do a task that is better done with either the kernel or udev ? There is a tool to split up the microcode as provided by Intel into individual family-model-stepping specific files. http://pkgs.fedoraproject.org/repo/pkgs/microcode_ctl/intel-microcode2ucode....
I expect this should live in udev or in the kernel-firmware repo (at least the Intel microcode should be there if possible).
Problem is that it needs to be loaded either very early, just after /dev creation or better in the initrd otherwise you will be booting init on a buggy CPU, to make matters worst, no changelog is provided to know what kind of bugs it fixes :-|
Take the lack-of-changelog up with the vendor providing the microcode, nothing we can do about that, sorry. greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Monday, November 28, 2011 12:25:37 AM Cristian Rodríguez wrote:
On 27/11/11 19:34, Thomas Renninger wrote:
On Wednesday 23 November 2011 18:20:14 Cristian Rodríguez wrote:
Hi:
Is there any news or improvements on the Intel microcode autoload feature so we can get rid of init/systemd scripts that currently do a task that is better done with either the kernel or udev ? There is a tool to split up the microcode as provided by Intel into individual family-model-stepping specific files. http://pkgs.fedoraproject.org/repo/pkgs/microcode_ctl/intel- microcode2ucode.c/0efc5f6c74a4d7e61ca22683c93c98cf/intel-microcode2ucode.c
I expect this should live in udev or in the kernel-firmware repo (at least the Intel microcode should be there if possible).
Problem is that it needs to be loaded either very early, just after /dev creation or better in the initrd otherwise you will be booting init on a buggy CPU, to make matters worst, no changelog is provided to know what kind of bugs it fixes :-|
Not sure this is really needed. Most CPU things are initialized already anyway. Another (last) open issue is: What loads the microcode.ko driver? Afaik Andi worked on autoloading CPU specific drivers, any news here? Otherwise something static has to be added to udev, e.g. catching a CPU add event, check and load microcode driver on all Intel and all AMD fam10h or newer. Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Monday 28 November 2011 17:43:58 Thomas Renninger wrote:
On Monday, November 28, 2011 12:25:37 AM Cristian Rodríguez wrote:
On 27/11/11 19:34, Thomas Renninger wrote:
On Wednesday 23 November 2011 18:20:14 Cristian Rodríguez wrote:
Hi:
Is there any news or improvements on the Intel microcode autoload feature so we can get rid of init/systemd scripts that currently do a task that is better done with either the kernel or udev ? ...
Another (last) open issue is: What loads the microcode.ko driver?
Afaik Andi worked on autoloading CPU specific drivers, any news here? Otherwise something static has to be added to udev, e.g. catching a CPU add event, check and load microcode driver on all Intel and all AMD fam10h or newer. Google points to this patch (from the dir name it seem to come from Matthew): http://www.codon.org.uk/~mjg59/tmp/cpu_modaliases.diff
Did this get rejected, do you plan to get this mainline? From a quick look I'd say the ven, fam, mod and stp strings shoult not be needed and an arch "column" could be added to differ different cpu architecture specific cpu aliases: MODULE_ALIAS("cpu:x86:GenuineIntel:6:14:*:*"); instead of: MODULE_ALIAS("cpu:venGenuineIntel:fam6:mod14:*"); But in general this should be the way to go for cpu driver autoloading? If this is old or got stuck, I'd like to understand the missing bits and would give it another try to get it mainline if it makes sense. Thanks, Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, Dec 05, 2011 at 12:13:36AM +0100, Thomas Renninger wrote:
If this is old or got stuck, I'd like to understand the missing bits and would give it another try to get it mainline if it makes sense.
It's on my list again. I talked with Kay about it recently. The original problem that made it stall was that the cpus were not devices, but sysdevs, and I had the attributes attached to them. But udev only works with devices. Kay had an ugly patch to give use devices as sysdevs, but that never made it in. With that patch it worked on my test system at load. Doing it is still a good idea of course. So we decide to side step the whole problem and just attach the attribute to the cpuid device, which doesn't have any of those problems. I already have a branch started with the new approach, but not everything tested&together yet. Hopefully soon. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Monday, December 05, 2011 04:18:23 AM Andi Kleen wrote: ...
I already have a branch started with the new approach, but not everything tested&together yet. Hopefully soon. Cool. Give me a ping if you think it's worth it and I volunteer to test, add things to our factory kernel for broader testing, etc.
Thanks, Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, Dec 5, 2011 at 04:18, Andi Kleen
The original problem that made it stall was that the cpus were not devices, but sysdevs, and I had the attributes attached to them. But udev only works with devices.
Kay had an ugly patch to give use devices as sysdevs, but that never made it in. With that patch it worked on my test system at load.
Doing it is still a good idea of course.
So we decide to side step the whole problem and just attach the attribute to the cpuid device, which doesn't have any of those problems.
I already have a branch started with the new approach, but not everything tested&together yet. Hopefully soon.
I started today looking into converting the CPU sysdev stuff to real devices. I'll let you know later this week ... Kay -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 05/12/11 00:18, Andi Kleen wrote:
I already have a branch started with the new approach, but not everything tested&together yet. Hopefully soon.
Great, thanks for your efforts, I have a few suggestions if you don't mind to ease our usecases ;-) - The microcode driver (intel,amd variants) should do nothing when we are running in virtualized environment, just return. - the -amd variant should also just return if processor family < 16 (0x10, fam 10h) - If you have any kind of influence, will be great if you can persuade intel to provide a changelog with the microcode file, so we can push updates according to the severity of the issues. That's all for now. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wednesday, December 14, 2011 05:30:56 AM Cristian Rodríguez wrote:
On 05/12/11 00:18, Andi Kleen wrote:
I already have a branch started with the new approach, but not everything tested&together yet. Hopefully soon.
Great, thanks for your efforts, I have a few suggestions if you don't mind to ease our usecases ;-)
- The microcode driver (intel,amd variants) should do nothing when we are running in virtualized environment, just return. It's not that easy. Linux running as Dom0 can and should trigger a microcode update, when running in DomU it should not.
In kvm typically a non-existent CPU is emulated and the microcode driver will not be tried to get loaded. But you can pass kvm -cpu host and then kvm will pass the original CPU cpuid info to the virtualized client which will try to load the microcode driver then. I hope this condition is correctly detected and handled (return -ENODEV?) in the microcode update driver and we can get rid of all additional userspace quirks which try to detect when the microcode driver should get loaded. Above cases need testing as soon as we have CPU autoloading and udev rules in place. Thomas -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
In kvm typically a non-existent CPU is emulated and the microcode driver will not be tried to get loaded. But you can pass kvm -cpu host and then kvm will pass the original CPU cpuid info to the virtualized client which will try to load the microcode driver then. I hope this condition is correctly detected and handled (return -ENODEV?) in the microcode update driver and we can get rid of all additional userspace quirks which try to detect when the microcode driver should get loaded.
Yes it should just error out. Deciding it before loading is likely complicated and wouldn't save all that much. -Andi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (5)
-
Andi Kleen -
Cristian Rodríguez -
Greg KH -
Kay Sievers -
Thomas Renninger