On 22.04.2008 22:37, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
As the resident "everything in LAR" guy I'm strongly in favour of having microcode updates as blobs in a LAR. Two points need to be made sure, though:
- If we compress the update, a decompression routine must not be able to
trigger data-corruption bugs.
You mean you want to make our lzma algorithm more solid? That's welcome.
This was meant as "I hope there are no errata which could be triggered by the lzma code".
- We have to know whether microcode updates can be deferred to a point
after RAMinit.
Why do you think it should be deferred? It currently happens in what is stage2. That's long time after ram is initialized. It's even after all the PCI init.
Sorry, I have to admit I'm rather ignorant about microcode updates. Thanks for educating me.
Agreed. Can we handle this like IP routing tables? Store familiy/model/stepping together with number of significant bits from the left, then pick the one which matches and has most significant digits.
That's basically how it has been working for the last 5 years, except that you can not omit family or model. Adding that complexity is questionable, given that we don't even use the flexibility we have since 5+ ys except on the VIA CPUs where I recently introduced it.
OK. I was just trying to address Marc's concerns.
That even allows for append-only tables with overrides.
This should work quite nicely. If someone would use it.
OK, let's defer that to a point in time when we need it.
We have to make sure that the table is stored in a separate LAR blob to avoid having to update stage2 for microcode updates and more supported processors.
The table has nothing to do with the microcode. Microcode has its own format stating for which CPU revision it can be used. What we're talking about is the cpu_driver's id_table. Go have a look at the code to see how it is implemented. We're really just cutting out cpu steppings artificially.
In the following code snippet
static struct device_operations cpu_dev_ops = { .init = model_10xxx_init, }; static struct cpu_device_id cpu_table[] = { { X86_VENDOR_AMD, 0x100f00 }, /* SH-F0 L1 */ { X86_VENDOR_AMD, 0x100f10 }, /* M2 */ { X86_VENDOR_AMD, 0x100f20 }, /* S1g1 */ { X86_VENDOR_AMD, 0x100f21 }, { X86_VENDOR_AMD, 0x100f2A }, { X86_VENDOR_AMD, 0x100f22 }, { 0, 0 }, }; static struct cpu_driver model_10xxx __cpu_driver = { .ops = &cpu_dev_ops, .id_table = cpu_table, };
it would be 100% the same to have a cpu_table struct looking like this:
static struct cpu_device_id cpu_table[] = { { X86_VENDOR_AMD, 0x100f00 }, /* SH-F0 L1 */ { X86_VENDOR_AMD, 0x100f10 }, /* M2 */ { X86_VENDOR_AMD, 0x100f20 }, /* S1g1 */ { 0, 0 } };
No cpu caught by the version with the 6 IDs would ever fall through the 3 ID version. It's just duplicate code. If we really wanted to have special code in place for the 0x100f2A, we'd have to have a seperate struct cpu_driver anyways.
Thanks for clarifying!
Regards, Carl-Daniel