* Borislav Petkov <b...@alien8.de> wrote:
> On Mon, Jun 29, 2015 at 10:25:29AM +0200, Mike Galbraith wrote:
> > On Mon, 2015-06-29 at 08:40 +0200, Ingo Molnar wrote:
> > > *
> > > Ok, so could you please move the fpu__init_system() further up and see
> > > which
> > > position is that starts breaking with the BIOS option set?
> > >
> > > here's the current, broken layout of the code:
> > >
> > > get_cpu_cap(c);
> > > [0] fpu__init_system(c);
> > >
> > > if (this_cpu->c_early_init)
> > > this_cpu->c_early_init(c);
>
> > [0] is the only spot that breaks box.
>
> I bet it is that
>
> /* Unmask CPUID levels if masked: */
> if (c->x86 > 6 || (c->x86 == 6 && c->x86_model >= 0xd)) {
> if (msr_clear_bit(MSR_IA32_MISC_ENABLE,
> MSR_IA32_MISC_ENABLE_LIMIT_CPUID_BIT) > 0) {
> c->cpuid_level = cpuid_eax(0);
> get_cpu_cap(c);
> }
> }
>
> in early_init_intel(). If you feel like playing, you might comment it
> out to see what happens.
>
> :-)
Indeed, I bet that makes a difference!
I wish that 'unmasking' logic came with more comments:
- Why do BIOSen ever mask CPUIDs?
- Why do we unmask the masking?
- Why doesn't the kernel keep on working just fine even if certain CPUID
aspects
are turned off?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
